The fundamental idea of serverless is eliminating the need to think about servers. If you are not thinking about (or working towards) managing the infrastructure, you get more time to focus on building your applications and serving the customers better. Let's understand this better by answering the question - What types of serverless offerings are available in the market?

Whenever I discuss the word serverless with developers and engineering leads, they automatically start talking about tools such as AWS Lambda, Google Cloud Run, etc. For some reason, compute serverless services have better brand awareness. This is where the problem starts. Compute is just one of the use cases of serverless. Let me give you a quick overview of the serverless categories in the market.

1. Compute

In serverless computing, you will find various cloud providers' offerings. Those offerings are -

1. Serverless functions - AWS Lambda, Google Cloud Functions, Azure functions, etc.

2. Serverless container runtime - Google Cloud Run, AWS Fargate, etc

3. Managed Kubernetes engines - Amazon EKS, Google Cloud GKE, Azure Kubernetes service, etc.

2. Databases

Serverless databases are all the rage nowadays. Most serverless databases offer the usual features - scalability, cost-saving, etc. Still, the real fight between them is on the factor that is the ultimate nirvana for every developer. It's single-digit millisecond latency at any scale. That means, irrespective of what command(CRUD) you perform on your database, you will get the result in less than ten milliseconds (unless you are using anti-patterns). To summarize, you don't have to manage the servers, you don't have to worry about high availability, throughput, etc, and you still get the single-digit millisecond latency. Who wouldn't go for that, right?

We will discuss what's the catch in this situation in the last section of this post, but for now, the following is the list of the most popular Serverless databases available in the market -

1. Amazon DynamoDB (NoSQL)

2. Amazon Aurora serverless (SQL)

3. Azure CosmosDB (Both NoSQL and SQL options available)

4. Azure SQL database serverless

3. Data warehouse

Data warehouse databases and engines are optimized for running analytics queries. If you don't know the difference between OLTP and OLAP databases, google it.

Google BigQuery is a serverless data warehouse - https://cloud.google.com/bigquery

Amazon has also launched Amazon Redshift serverless. Several other cloud providers are racing towards their serverless data warehouse offering.

4. REST APIs and GraphQL

Many services in the market offer serverless management and deployment of REST APIs/GraphQL endpoints. Some examples are - AWS Appsync, Amazon API Gateway, Azure API Management, Firebase cloud functions, etc.

Most of them work with one or more of the above services (computing, databases, etc) to get the results. The idea is to simplify managing and deploying these everyday use cases, such as REST APIs and GraphQL.

5. Message queues and pub-sub

I come from the era where you had to scale up your own RabbitMQ and Kafka setup; trust me, it was a nightmare. So, serverless message queues are one of my favourite cloud products. Such services include Amazon SQS, Google pub/sub, etc.

If you don't know what message queue and publisher-subscriber pattern are, go through this link

6. Media storage

Media storage services like Amazon S3 have been around for a long time. But people often forget these services are the "OG" serverless offering". These services are the ones that inspired the idea behind serverless computing and serverless databases.

Examples of such services are - Amazon S3, Cloud storage (by Google), Azure blob storage, etc.

7. Edge CDNs and networks

Although classifying Edge CDNs as serverless is a bit thin, as they are primarily known for only one thing - "Content delivery" but again, they are not used for just content delivery, and they offer all the core functionalities that serverless promises like scalability, no operational overhead, ease of use, etc. So, technically, they also fall under the paradigm of serverless computing.

If you don't know what CDNs and Edge networks are, you can learn using the following links -

1. https://www.cloudflare.com/en-in/learning/cdn/glossary/edge-server/

2. https://vercel.com/docs/concepts/edge-network/overview

Edge CDNs started with the use-case of content delivery, but now you can run serverless functions, APIs, etc, on edge as well.

Why does serverless exist? - The problem statement

If I have to summarize and oversimplify things, the following high-level reasons should be enough to answer the question -

1. To save cost - serverless is usually cheaper when your application traffic is inconsistent and less. A "pay only for resources used" pricing model usually charges you for memory, CPU, and other resources that are consumed by your app. Cost is generally marketed as the biggest reason for choosing serverless.

2. Auto-Scaling: Serverless platforms automatically scale resources up or down based on demand. It allows applications to handle varying workloads without manual intervention.

3. Less operational complexity - Anyone who has ever tried to scale up compute, database servers, or something as simple as a reverse proxy (such as Nginx) for highly concurrent workloads knows how complex (and ugly) operational overhead can be. Serverless aims to eliminate this operational overhead and make things simpler for developers.

4. Improved developer experience - Boosting developer experience is the new motto of enterprises and startups. Have people in management fully understood and experienced the wrath of pissed-off developers? (kidding, of course). But yes, people have understood the fundamental principle that "Time is money". And when paying hundreds of thousands of dollars yearly to a single developer, time is literally money. Serverless promises increase development velocity and improve the developer experience by freeing them from infrastructure provisioning, management, Ops, etc.

There are many other advantages marketed by cloud providers while selling these solutions, but almost all are subsets of the four points mentioned above.

How can you decide if the serverless solution is good for you?

We are now addressing the elephant in the room. Now, this is where people generalize an entire spectrum of products and offerings by throwing statements like "serverless is suitable for small workloads" or "it's not fit for production environments". And that is a lazy way to think about things.

The most critical metric in choosing between serverless and provisioned solutions is cost. Everything else - Auto scaling, less operational overhead, and improved developer experience- are promises made by provisioned solutions as well. And cost in the cloud is generally a function of -

1. Compute - the amount of processing power required and usually measured in terms of number of cores and types of processors.

2. Memory - Amount of memory (RAM - if you want to call it that) required and usually measured in MiB/GiB. (or, in some cases, memory units).

3. Storage - The storage required for the solution is measured in MB/GB/TB, etc.

4. Data transfer cost - The most dangerous if not accounted for and usually measured in GB/TB etc.

There can also be other factors when computing the cost for a specific offering. It requires you to go through the pricing page of that solution and understand the pricing logic well. But in general, the cost predominantly depends on the above four factors.

But if you think about it - The choice between provisioned and serverless (unless there is some difference in certain functionalities) can be as simple as estimating things and doing a few simple mathematical calculations. All you have to do is -

1. Capture the engineering requirements of the system well - Use this battle-tested ERD template to structure your engineering requirements well and do the capacity planning efficiently.

2. Do Back-Of-The-Envelope Estimation / Capacity Planning to determine the system's load requirements - Choose a metric that best fits your problem. It can be anything such as the "number of concurrent requests/read/writes", "total data transferred", "Daily active users", "Monthly active users", etc. It depends highly on the problem statement you are solving and the solution you are designing for that. (Google this topic and learn it in depth if you don't know what it is).

3. Figure out your expectations from the solution - Cost effectiveness, speed, performance, scalability, low operational overhead, high availability, security, automated backups, observability, maintainability, etc. - Although it's very rare, there may be some functionality differences between provisioned and serverless solutions offered. If your expectations are apparent from the beginning, you can avoid surprises down the line.

4. Compare the serverless and provisioned solutions based on the results of the above three steps and see which one fits your needs best in the short term and relatively long term (Relative to the nature of your business and the growth curve it can have).

But what about the usual problems with serverless solutions - The usual suspects

Whenever I discuss serverless vs provisioned with people, I get a list of "usual problems with serverless," which are used as an excuse not to think about the solution. So, to save time in the future, I will take a few extra minutes to address those issues in this blog post and be done with this topic. Following is the list and my reply -

1. Cold start problem - The first and foremost reason people tout for not considering serverless is a cold start. But in 2024, there are only a few serverless solutions (for example, serverless functions) that suffer from cold start problems, and there are several ways to circumvent that problem and still be pocket-friendly. In fact, serverless solutions like DynamoDB offer a single-digit millisecond latency for all operations. So, stop generalizing and solve the problem based on the above-mentioned steps.

2. Resource Limitations - Again, it's 2024 and most serverless offerings, including the serverless compute offerings, have a very high resource limit. 95% of the use cases don't need processing/memory/storage beyond what is already available.

3. Uncertain Pricing - This is what this entire blog post is all about, so read it and understand that the pricing is only uncertain if you don't do the math.

4. Debugging and Testing - This problem was specific to serverless functions, but there are now frameworks such as serverless framework(link) to solve this problem for serverless functions. You will not face this problem with other serverless offerings.

5. Vendor lock-in - Another famous reason for not using serverless. But I can't refute this in a single statement because it's a big discussion on its own. I will write a separate blog post about it and update the link here once it's live. But, at a high level, the vendor lock-in problem is not as severe of a problem as people think.

Ending note

I hope this post pushes you to explore serverless as an option for your cost optimization and developer experience needs. If you do the math correctly, you can reduce costs by 90% for the same amount of scale in most solutions (Especially databases, storage and queues).
If you have any questions, doubts or suggestions, please feel free to contact me on Twitter, Linkedin or Instagram. Do share this article with your friends and colleagues.