Why Serverless Architectures Matter

There are many predictions from market analyst firms on the size of the global serverless architecture market and how fast it will grow. The numbers range from $18B to $21.99B in the next few years with the compound annual growth rate (CAGR) in the double digits. But is serverless only a fancy name for products like AWS Lambda and Azure Functions?

What is serverless?

When you build an app, everything you do generally breaks down into two large buckets. The first bucket holds everything that every other app needs to do as well. These are things like running a set of servers to deploy your app to or running your CI/CD tools. The first bucket contains all activities that don’t give your app an edge over anyone else in the market. AWS calls the activities in this bucket “undifferentiated heavy lifting”. The second bucket is where the magic is. That bucket holds everything that gives your app an edge over others. These are things like your amazing user experience or snappy responses from the support team. This second bucket is what AWS calls “the secret sauce”. As a company, you want to make sure your developers spend as much time as possible on activities in the second bucket so they can focus on business value. The activities in the first bucket should go to a cloud provider as much as possible. So serverless, or a serverless operating model, is all about developers delivering business value. You want to spend as little time as possible on anything but your competitive advantage.

Key drivers of serverless

In general, serverless solutions have four key drivers. First of all, serverless means that there are no servers to manage or provision. This means you don’t need to install the runtime or patch servers. It doesn’t mean that there are no servers, though. The second driver is automatic scaling. The microservices in your app should scale to infinity when they get really busy. It also means those services should scale back again when it’s not as busy. The third key driver is that you want to pay for value. This means you’re paying for what you’re using like memory consumption, CPU usage or network throughput rather than server units. The fourth driver is that high availability should be a capability you use, rather than a capability you build yourself.

Let’s compare a few services and see how those drivers work out. I’ll use some of the AWS services, but the comparison works for the other cloud providers too. AWS Lambda allows me to upload code so I don’t have to manage any servers. It also allows me to scale from zero to infinity and back again, and I pay for the number of executions. When a server running my Lambda functions goes down, another takes over. So Lambda works for all four drivers. With AWS EC2, I do have to manage servers. I also have to pay for the server unit. EC2 doesn’t scale the app that runs on top of it, and I have to design high availability for my app. So EC2 works for none of the drivers. To show that serverless isn’t only a fancy name for Lambda, let’s look at AWS Fargate. With Fargate, I deploy a container and I don’t manage a server. I pay for the time my container runs, based on CPU and memory consumption. Fargate allows me to scale my apps based on resource usage. When a machine running my Fargate instance goes down it will failover to a new one. So Fargate is serverless too! In fact, AWS and most of the other cloud providers, have a wide range of serverless options for all sorts of use cases.

Serverless and Event-Driven Architectures

In event-driven architectures, your microservices react to the events coming in. When you have many events coming in at the same time, you want the microservices in your app to scale up (and back again when it’s a quieter period). The microservices should failover automatically when something happens, and you don’t want to pay for entire servers. The same key drivers that are important to serverless, are important to event-driven architectures.

Does serverless actually matter?

As I mentioned in the event-driven architecture blog, your services can run anywhere and your users won’t care about that. In the same way, it doesn’t matter which programming language you use. What matters to your users, is that your app works all the time and that it looks good. Your users care about the activities from the second bucket and that is what serverless allows you to do.

Over the coming period, we’ll share more on how we’ve event-driven and serverless works for our ACME Fitness App. In the meanwhile, let me know your thoughts and send me or the team a note on Twitter.

Cover photo by Bethany Drouin from Pixabay