[Editor’s note: this is the second part of a two-part discussion of serverless architecture. Why two parts, you ask? Because going “serverless” requires understanding of both the technologies available and the benefits. Each topic is compelling on its own. Read Part 1 to gain a better understanding of serverless.]
Benefits of Serverless
There are many benefits of serverless. These are some favorites.
Low Cost
Serverless costs are based on usage at a very granular level, so you are never paying for more than you use. If you built a solution using AWS Lambda and had no calls to your system in 24 hours. Your bill for that day would be $0. I built a solution using a variety of serverless components that received over 23 million queries for one month and my cloud bill for that period was $120.00. I can’t even imagine how much a solution like this would cost if I was running this on my own servers.
Keep in mind that serverless costs may not scale linearly and you should always keep in mind what level of growth you’re targeting and that your architecture is cost effective at that level.
Low Operational Overhead
How much time do you spend setting up monitoring and alerting to track the health of your servers, how much effort is spent tuning and configuring systems, how often are you restarting nodes that have gone wonky? The commerce solution I mentioned above operated for 1.5 years without a single incident. I can reallocate the part of my brain that had to be worried about outages and use it for solving more interesting problems than “do I need to scale up for the sale tomorrow”. This also reduces the cost of running software by not needing large teams to oversee this work. This work never entirely goes away, but is reduced significantly.
Scaling
Once you’ve built your solution serverlessly, autoscaling is built right in. Serverless is not the only way to autoscale, but it was designed with it in mind. Once again referencing the commerce solution I built, I tested it up to 1000 queries per second with no issue. I could have tested more than that, but this was about 500x more than what we’d actually need in production.
Focus
For me, this is the biggest benefit. When building software serverlessly, I can focus almost entirely on the logic of the application instead of all the plumbing required to make it happen. I want to be spending my time on the interesting problems.
Things to Watch Out For
Serverless is great, but it’s not a magic bullet that solves every problem. These are the primary caveats to consider when deciding if Serverless makes sense for you.
Serverless Limitations
I think Serverless is a great solution for a lot of applications, but it won’t fit every use case. Some cloud platforms won’t have a serverless service matching what you need to do. Or when they do, they still have technical limitations. AWS Lambda functions can’t exceed 3 GB of memory or run longer than 15 minutes, making it unsuitable for certain workloads like ETL.
Denial of Wallet
You are likely familiar with DDOS attacks, in the serverless world there are Denial of Wallet attacks. When your serverless solution can scale to massive levels, you will pay for that scale if you’re not careful. Non-serverless solutions will run out of resources and stop working, serverless will scale (and cost you) if you don’t put controls in place. Most cloud platforms have limits you can configure to mitigate this and you should definitely take advantage of them.
Fine Tuned Configuration
Some use cases require fine tuning of different systems. Serverless takes this out of your hands, which in a lot of cases is a huge benefit, but can be frustrating when you really need it. Again, each case needs to be evaluated with the limitations of each serverless component in mind.
Vendor Lockin
A common concern I hear about Serverless is that it locks you into your cloud platform, making it challenging to ever be able to switch to another vendor. My response is that it is always going to be hard to switch cloud platforms, even when you try to design to make it easy. It never is. I have worked at places that have built compromised solutions with the intention of being able to switch to another cloud provider (which never happened) and ended up with a solution that did not take full advantage of all the benefits that being in the cloud provides.
Control
At the end of the day, when you build Serverless, you are putting your fate in the hands of your cloud provider (though you can run serverless solutions yourself, it kind of defeats the purpose…). If they go down, you go down. However, in my experience this is way, way less frequent than when I’ve been the ones owning the infrastructure. Also, when AWS goes down, most of the internet is affected, so people tend to be more understanding than when it’s only you going down.
Benefits of Serverless Final Thoughts
Serverless may not be a fit for everything, but I now default to building that way when I have the option. And even if there are components in your application that aren’t a good fit for their managed equivalent, you can always build hybrid solutions with parts being serverless and others being ones that you operate.
Building Serverless has been a revelation for me and has made building software a lot more fun (and way less stressful). There’s lots of options out there for trying this approach out, it’s worth giving it a try!
