Serverless computing just turned seven. Let’s examine when, where, and what to use it for today.
Have you heard about serverless computing? Guess what, it’s not serverless at all. It just automates the allocation of back-end servers you’ll need to complete a particular task. Today we have dozens of types of serverless systems from databases to containers to more traditional development systems. They all hold the same promise: to provide vertical and horizontal scaling automatically without having to configure servers ahead of time.
This means developers don’t have to guess how many storage and compute servers to launch prior to applications running. The serverless systems make those decisions for you, allocating the resources that you need during runtime and deallocating them when the need is no longer there.
Automation is really the key value. We’re removed from attempting to figure out how many resources we will need. Picking too many resources (most of which we forget to shut down), makes for a huge cloud bill at the end of the month. Pick too few resources and we watch our applications fail shortly after launch.
I have personally left resources running and have always resented the fact that cloud providers forced me, a human, to pick the resources I needed. It’s not a matter of if you’ll be wrong, but of how wrong you will be.
Thus, I like serverless as a concept. Unless a client has a good handle on what resources will be needed, it’s a safer bet to go for net-new, cloud-native applications than attempting to guess the capacity needed. Plus you have the ability to grow and change capacity ongoing. Therein exists the value of serverless, in my opinion.
The counterargument is that serverless is more expensive than resources that are self-allocated prior to runtime. Indeed. However, this assumes that you’ll correctly pick an optimal configuration that starts and stops at the correct time and in the correct sequence. Some can pull this off, but most can’t.
Also, there are several downsides to serverless that most don’t understand until they have used it. It’s “cloud native,” or specific to a single public cloud provider, meaning that easy portability is not a feature of serverless on any public cloud provider. There are few if any management and monitoring tools for native serverless systems beyond those provided by the public cloud provider that is selling it.
Serverless is one of those technologies that clearly has trade-offs, but with its maturation of the past seven years, we’re seeing a clear value path for serverless for many net-new, cloud-native workloads. That said, it also very much depends on what you’re building and for what purpose since you’re trading portability for resource allocation automation and having fewer things to worry about.
In many of the uses I’m seeing, serverless makes sense. But it’s still case by case.
