Sponsor: Do you build complex software systems? See how NServiceBus makes it easier to design, build, and manage software systems that use message queues to achieve loose coupling. Get started for free.
Serverless sucks… or does it? There is a neverending supply of people saying that serverless is trash and has no value. The issue often with these statements is they need to provide more context. As always, context is king, and understanding the use case to make decisions on when serverless might be appropriate.
YouTube
Check out my YouTube channel, where I post all kinds of content accompanying my posts, including this video showing everything in this post.
Hot Takes
Nothing kills me more than hot takes. Why? Because they generally contain little information other than something good or bad. They don’t include any context. Most often, they seem made by people trying to sell something.
That sounds like context, right? 600k visitors, 1 million API calls/month. Not really. I have no idea what type of workload those API calls are behind. Do you need High Availability? I’m assuming, in their context, no. But I’m assuming that because I have no context. If so, you did need HA; you’re adding at least one other instance behind a load balancer you will manage and pay for.
And this one is by far my favorite (in a bad way).
Of course, why elaborate? All his apps are using a normal node.js server, so that must mean it should work best in every context, right? Wrong.
Does serverless suck? No. Should serverless be used for everything? No.
Scaling Up (Out)
One part of the context often discussed for serverless is scaling and load. For example, the first post above discussed how a single $7 server could handle 1 million API calls. Generally, the topic around serverless is about scaling up (more function calls) to handle more traffic. Meaning, looking at the peaks of load/traffic.
However, another way to gauge whether serverless might be a good choice is to look at it from the inverse: when you want to scale down.
If your traffic is stable and predictable, you can use auto-scaling to adjust the resources for a typical virtual machine or container. For example, if your system is more driven by 9-5 business hours, your load might look like this.
While serverless will work fine, you can also use auto-scaling of your always-on resources (virtual machine or containers).
As I mentioned, serverless use cases involve scaling down to zero. If you have an unpredictable load, serverless can be beneficial. You aren’t paying for resources that you aren’t using at all.
Another example is if you have a recurring or periodic scheduled task that runs every few hours. Typically, you’d think of this as batch jobs.
In this case, you don’t have an instance (VM/container) running, doing nothing half the time; rather, with serverless, you’re just paying for the execution you need. So, it’s a predictable load, but again, look at the valleys as an indicator, not the peaks.
Valleys, not Peaks
The problem with looking at the peaks and trying to scale infinitely to handle a high number of requests is that you’ll have a bottleneck somewhere. Most systems are built around various other pieces of infrastructure. The most common example is a database. If you’re using serverless to scale to handle more requests infinitely, that means your database also needs to be able to scale infinitely. If it can’t, you will just overwhelm your database, bringing down the entire system.
However, if you’re looking at the valleys as a means to determine if serverless might be ag good use case, you don’t have that concern about moving the bottleneck.
There are many other factors that drive if serverless is a good choice. Looking at the valleys and when you can scale to zero is just one of them.
But this “[insert technology here] is awful” or “you should only use [insert technology here]” is absolute nonsense.
Join CodeOpinon!
Developer-level members of my Patreon or YouTube channel get access to a private Discord server to chat with other developers about Software Architecture and Design and access to source code for any working demo application I post on my blog or YouTube. Check out my Patreon or YouTube Membership for more info.