Why should you care about Serverless?

This is the most pressing question to answer, because Serverless is coming. The hype for it is mounting.

Gartner, a major analytics firm that surveys the IT market, has published their yearly Hype Cycle for Emerging Technologies report. You can take a look at the image to see what’s coming:

Gartner Hype Cycle

How does the Hype Cycle work? On the graph, Serverless is surrounded by a number of other technologies, each in a different stage of the cycle. In short:

  1. first, the hype grows;
  3. then, it peaks;
  5. then, people start seeing issues and criticizing;
  7. finally, they find ways to make it work—the tech matures.

Take a look at blockchain, for example, which is a little past the peak. Right now, the hype for blockchain is peaking. Pretty much every tech company we talk with wants to know about blockchain. The same goes for Deep Learning and IoT.

For Serverless computing, the hype is just starting, meaning you can get in on it early.

To be fair, the Serverless computing model is not an entirely new idea—it’s 3–4 years old at least. But up until recently, it was only discussed between technical experts, developers and DevOps professionals.

Now, Serverless is starting to enter the broader IT conversation. How should you react?

At the very least, you should understand what’s going to be on everyone’s minds very soon. But more importantly, you might want to implement Serverless architecture in your project.

So to stay up to date, you should know about Serverless.

And if you’re looking for a way to easily create apps without the need for DevOps skills, you should especially read on.

What is the Serverless model?

The road to Serverless

The name Serverless might be a little misleading. When we talk about Serverless, we’re not talking only about servers, but about the entire cloud ecosystem.

The easiest way to explain Serverless is to take a historical view.

Serverless model

A long time ago in the yonder days, you dealt mostly with dedicated servers. To host your app, you had to buy a whole server which would be physically situated in a server room. The whole server was yours and you were responsible for making it function properly.

As you can imagine, that was a bit of a bother to do, especially when all you really wanted was to build your app, not spend time updating and maintaining your server(s).

As a response to that, IaaS—or, Infrastructure as a Service—was born. In IaaS, the server is no longer yours; it’s the provider’s. All you have to worry about is setting up the OS, the app itself, its functions and the service. An example of an IaaS solution is AWS EC2 (or Amazon Web Services Elastic Compute Cloud). Newable Business Finance is one project where we had a chance to apply IaaS in practice.

But if you’re like me, that still sounds like too much ‘Ops’ in your DevOps.

So the next step is Platform as a Service: PaaS. Here, the OS falls on the side of the provider. All you have to do is create the app, while the provider worries about updating the OS and keeping it secure. An example is Google App Engine, which we have used working with clients such as KeyIngredient.

Serverless architecture: from app-level to function-level

Now we get to Serverless, the next logical step.

When you use Serverless architecture for your software, you don’t have to create the whole app. Instead, you only create single functions of the app, while the app layer, the part that manages the functions, is on the side of the provider.

That means the provider handles scaling and ensures proper exchange of information between different parts of the app—so you don’t have to worry about that. In Serverless, you and your devs only care about creating functionality. And isn’t that what development should be all about?

Serverless vs. Software as a Service (SaaS)

Finally, the last model on the image is SaaS, or Software as a Service. Here the whole software is on the provider’s side. As the buyer, you get the service, i.e. what the software actually does.

SaaS apps are very popular these days, and you’re probably using some of them. Think about Dropbox, Salesforce, Netflix, Google Apps, and so on; if you pay for them, you only get the service they offer.

However, we need to make a key distinction here between using an app and building an app.

From a user’s perspective, Netflix might fall under SaaS—after all, you just want to watch Stranger Things.

But when you’re building a service like Netflix, you need to use at least a Serverless model to add more functionalities to the app. If you want more control over how the app is built and hosted, you could use PaaS or IaaS instead.

Let’s consider a different example: Foodpanda. From the user’s perspective, it’s a typical Software as a Service: the service helps you order food. But in building it, you could either:

  • create the whole service in a framework like Django, then host it on a dedicated server,
  • write it in Django and use a virtual IaaS server,
  • leave the OS to the provider and use something like Google App Engine, i.e. PaaS, or
  • write the functions the Serverless way and host it via e.g. Amazon Lambda.

But remember: as a user of Foodpanda—you don’t care. You only want the service.


Scaling in Serverless vs. other models

Now let’s consider how your costs will scale in each model.

Foodpanda has a range of functionalities: you list restaurants, filter to your taste, select your dish, choose additional ingredients, and finally process your payment.

With PaaS/IaaS, you would build one app that has it all: listing, menu, and ordering.

With Serverless, you would break that up into several functionalities (or Lambdas for Amazon Lambda). You don’t combine them into one app, but send them separately to the provider, and the provider builds the app.

The provider also handles scaling. If the menu function is used very often, but ordering doesn’t see that many requests, the provider can scale each function individually. So the popular menu function would get more processing power, but ordering would still have the same level.

Whereas in PaaS/IaaS, you are responsible for configuring the app to handle the load and be scalable. The difference is that to ensure proper scaling, you need DevOps personnel on your side while in Serverless, a provider such as Amazon handles all of that.

TL;DR: Serverless architecture allows you to focus on the application’s code, and not on how the code will perform on the server.

Should I care about Serverless if I outsource?

Of course, we’d be remiss not to mention the outsourcing scenario. As a client, you hire a software house to handle the software creation for you. In some cases, you may ask the software house to also handle DevOps, i.e. configuring servers, deployment of the app to the server, continuous integration, etc.

With Serverless, the DevOps are out of the equation—your software house doesn’t have to do that anymore. Why should you care, though?

Because at some point, you might want to move development back in-house, and your employees won’t have to do DevOps either.

But most importantly, you should care because in both the in-house and the outsourcing scenario, Serverless will very often be the cost-effective solution, especially for apps without huge amounts of users. Let’s talk about that next.

Pricing: How Serverless can save you money

Pricing Model

The final reason to consider Serverless is its flexible pricing model.

In IaaS/PaaS, you pay for the time when your app is working and available to users. If you own Foodpanda and want it to be available 24/7, then you pay for each hour when it’s online and waiting for connection from users. Crucially, you keep paying regardless if the server/app is in use or not. To scale, you have to add new virtual machines (IaaS) or create new app instances (PaaS).

For Foodpanda, that is fine; the site is probably used by someone every minute of every day.

But what if your app isn’t Chairman of the Popularity Club yet?

In Serverless, if it ever happens that Foodpanda is used by no one for half an hour—you don’t pay for that. More realistically, you could have an office app that employees mostly use during business hours. That would ‘sit around bored’ all night long, but it should still be available for that one employee that desperately needs to check something at 2 AM. For such cases, Serverless ideal because you only pay for how much your app is actually used.

What do I mean by ‘how much the app is used’? With Serverless, you pay for the amount requests the app gets and for milliseconds of CPU and RAM work.

AWS Lambda
AWS Lambda

Let’s use Amazon’s AWS Lambda as an example for pricing.

Lambda is currently the most popular Serverless solution. Importantly for us (and for your Python projects), Lambda is compatible with both Python 2.7 and 3.6.

So what’s the pricing for AWS Lambda? Here’s an overview straight from the official AWS Lambda page:

AWS Lambda Pricing
  • Approximation to 100ms.
  • The first 1,000,000 requests each month are free.                       
    • After that, you pay $0.0000006 per request.
  • The first 400,000 GB-seconds are free.                       
    • After that, you pay $0.00005001 per GB-second.

Pay special attention to the ‘free tier.’ Using Lambda, your first 1,000,000 (that’s one million) requests and the first 400,000 GB-seconds are completely free. After that, each request and every GB-second used by your app is counted—and you pay only for that.

This limit is reset every month. Quite generous, isn’t it?

Comparing costs between Lambda and EC2 (IaaS)

Of course, Serverless isn’t a solution for every situation. In some cases, a IaaS solution like EC2 could serve you better. That depends on the amount of attention your app is getting.

What’s the breakpoint for Serverless vs IaaS? Take a look at this table, based on Andy Warzon’s Medium post AWS Lambda Pricing in Context: A Comparison to EC2:

Function Execution
Memory & Time

Requests per Hour Required for Lambda Cost to Equal
EC2 (m4.large) Cost

Requests per Second

100 ms @ 128 MB



200 ms @ 512 MB



200 ms @ 1 GB



1 sec @ 1 GB




The most important part is the far right: if your app gets over 81.9 requests per second (24/7) then IaaS becomes the preferred solution. If it’s anything less than that, Lambda is more cost-effective.

Let’s do the math on that. Take the top row, in which each request takes 100 ms and 128 MB RAM to process. Every day, you need an average of 81.9 requests per second, times 60 seconds in a minute, times 60 minutes in an hour, times 24 hours…

81.9 * 60 * 60 * 24 = 7,076,160 daily requests

For those assumptions, your app needs over 7 million daily requests for Serverless to be more expensive than IaaS.

In other words, your app needs to be really, really popular for Lambda to be a bad choice. Even if the average user usually issues multiple requests each visit, you’d still need hundreds of thousand of users to hit that number.

Let’s use Foodpanda as an example one last time. As a typical user:

  • you visit the site,
  • list the restaurants near you,
  • view 5-10 restaurants,
  • maybe filter them,
  • maybe check their pricing,
  • put a few menu items in the cart,
  • enter the address,
  • order and pay.

Give or take, you must perform 100 requests to order lunch. Assuming such an average, you’ll still need over 71,000 daily users to hit the Serverless/IaaS breakpoint. That might not be that big of a number for Foodpanda, but for startups and more niche apps, you’d do well to give Serverless a thought.


How Serverless architecture affects vendor lock-in

Serverless computing is a way of running applications in the cloud in which the cloud provider manages all the required servers. But for the application to run on Serverless, you have to build it in a specific way - it has to be constructed in a Serverless architecture.

Applications built in a Serverless architecture strongly depend on third-party services. As such, you might be afraid of vendor lock-in; once you decide on one, you can never go back.

To quote Wojtek directly: “It’s not that bad.”

The business logic of the app is located in its functions, which can be easily moved to another Serverless provider.

However, the application doesn’t consist only of functions. It also includes other components such as the database, file storage or search engine. In Serverless, you can't run a database on your virtual machine—you have to use the services provided by the cloud vendor.

But even here, you can decrease the risk of vendor lock-in by choosing non-proprietary components that use a common standard. For example, you can use Amazon RDS, i.e. an SQL database. In that case, switching vendors or moving hosting to your own servers will be much easier.

Final thoughts on Serverless

So what are the takeaways? Here’s why Serverless is worth paying attention to:

  • The hype is growing. Serverless will most likely gain popularity in the coming years. It’s worth considering this option sooner than the competition.
  • Focus only on functionalities. With Serverless, you can build individual functions of the app and let the provider do the work of combining and hosting them.
  • Smoother scaling. Instead of creating additional virtual machines or app instances, Serverless allows you to scale on a function-by-function basis.
  • “Pay as you go.” Instead of paying for idle servers, with Serverless you only spend as much as your users actually use the app.

Hope this helps you get an understanding of the opportunities that Serverless grants you. If you have any questions, we’ll be happy to answer them in the comments.

As always, many thanks to Wojciech Lichota for sharing his knowledge once again on the STX Next blog. Here are a few more of his articles which you might like:

If you enjoyed this and want to learn more from our new posts, why not subscribe to our newsletter? Use the box on the right (on desktop) or scroll down (on mobile) to join our inner circle.