# 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?

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