When you’re thinking about hosting your app, you want it to be as hassle-free as possible.
After all, you’re on your way to create software that will transform your organization, your community – possibly the world. (No need for modesty here!)
On that path to greatness, there’s no room for hosting frustrations.
Everyone wishes for a hosting solution that makes it easy to deploy features rapidly. It should also be cost-effective, keeping your bottom line happy and freeing up resources to put towards development.
First, let’s answer the most pressing question…
Why should you care about Serverless?
Because it’s coming. The hype is mounting.
first the hype grows…
then it peaks…
then people start seeing issues and criticizing…
until finally they find ways to make it work. The tech matures.
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.
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 Architecture Comparision
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.
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.
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.
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.
Pricing: How Serverless can save you money
Comparision of Serverless Architecture Pricing
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.
Let’s use Amazon’s AWS Lambda as an example for pricing.
Lambda is currently the most popular Serverless solution. 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 cost – https://www.trek10.com/blog/lambda-cost/
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.
Final thoughts on Serverless
So what’s the takeaway? 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.