Why Serverless?

This is the most pressing question to answer, because serverless computing 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.

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

1. First, the hype grows;
2. Then, it peaks;
3. Then, people start seeing issues and criticizing;
4. 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 computing. And if you’re looking for a way to easily create serverless applications without the need for DevOps skills, you should especially read on. Cloud providers manage the backend resources, allowing developers to focus on code deployment without worrying about infrastructure.

What is the Serverless Model?

The Road to Serverless

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

The easiest way to explain serverless architectures is to take a historical view.

A long time ago in the yonder days, you dealt mostly with physical 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 to spend time updating and maintaining your server(s).

As a response to that, Infrastructure as a Service (IaaS) 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 (Amazon Web Services Elastic Compute Cloud).

In serverless computing, the cloud service provider manages the underlying infrastructure, allowing developers to focus on writing application code without handling server management.

Serverless Architecture: From App-Level to Function-Level in Serverless Applications

Now we get to serverless architecture, 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 serverless functions of the app, while the app layer, the part that manages the serverless functions, is on the side of the cloud provider.

That means the cloud 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 Software as a Service (SaaS). 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, creating a serverless application.

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

Scaling in Serverless vs. Other Models in Cloud Infrastructure

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 computing, 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 cloud provider, and the provider builds the app.

The cloud 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 computing, 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. A fully managed serverless platform enhances serverless computing solutions by handling all scaling and infrastructure needs.

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 computing 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

The final reason to consider serverless computing 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 is 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 computing, you pay for the amount of requests the app gets and for milliseconds of CPU and RAM work.

AWS Lambda: Serverless Functions

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

Lambda is currently the most popular serverless platform. 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, an 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:

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 thousands 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 applications 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. Serverless technologies offer significant advantages for agility and cost optimization, but you might be afraid of vendor lock-in; once you decide on one, you can never go back.

To quote Wojtek Lichota, our Head of Service Delivery in Gdańsk, directly: “It’s not that bad.”

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

However, the application doesn’t consist only of serverless functions. It also includes other components such as the serverless databases, file storage, or search engine. In serverless computing, you can’t run a serverless 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 Computing

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

• The hype is growing. Serverless computing 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 architecture, you can build individual serverless functions of the app and let the cloud provider do the work of combining and hosting them in a serverless environment. Serverless apps can process real-time data efficiently and handle large volumes of information with minimal latency. Another key solution for businesses to leverage cloud computing resources is Google Cloud, which offers financial incentives for new customers and unique offerings like serverless computing, allowing developers to focus on application code without managing server infrastructure.
• Smoother scaling. Instead of creating additional virtual machines or app instances, serverless computing allows you to scale on a function-by-function basis.
• “Pay as you go.” Instead of paying for idle servers, with serverless computing you only spend as much as your users actually use the app.

We hope this helps you get an understanding of the opportunities that serverless computing 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:

• Go Go Python Rangers! Comparing Python and Golang
• A Beginner’s Introduction to Python Frameworks
• The Ultimate Guide to Hiring High-Impact Software Developers, Part One

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.