The guiding principle of a serverless ecosystem is that an organization using it never has to think about the infrastructure underlying the set of services that make up that ecosystem.
When I say this to business/tech leaders they will often follow up with something along the lines of “Okay, but what does that actually mean in practical terms?” or “I already use kubernetes, is serverless really any different?”
I will answer these questions in this blog entry. We will be expanding on the topic and exploring some specific techniques for designing and building serverless applications in subsequent articles.
Let’s start with the first question. What does serverless really mean? In the early days of the Cloud, Cloud Architects used to tell people that the cloud is just your apps running on other people’s servers with the app owner given just enough control to get everything up and running in their own isolated environment. We wanted people to understand that under the hood the cloud was no different from what they’d already seen in their own datacenters, just writ large. The Cloud also included a lot of new pre-made tools designed to accelerate product delivery and increase overall uptime, without having to worry about bare metal hardware anymore.
Serverless is simply the next major step in this same direction. Now, instead of not having to worry about hardware, product owners don’t even have to worry about operating systems, orchestration, and (in many cases) the networking layer at all. No more patching or updating. No more paying for OS licenses. No more worrying about scaling up and down. Your teams only need to worry about their code and data while the cloud vendor worries about running that code and making sure it scales properly. In addition, serverless offerings are modeled almost exclusively on a “pay-for-use” billing model that ensures that you aren’t ever paying for unused capacity.
It’s still the same idea as before – your code running on other people’s servers – but now there’s an added layer of abstraction that eliminates even more of the risks and costs associated with the traditional datacenter model. Cloud vendors have an ever-growing set of managed services and serverless compute options that, when combined, can host entire enterprise applications from the front end all the way down to the data store (with layers of tailored security throughout). These complex applications can be hosted without a single virtual server or operating system that the app owner needs to manage.
In practical terms this means that you can redirect a lot of your resources currently devoted to infrastructure maintenance to application development instead, and speed up your SLDC dramatically while also improving your application’s overall uptime.
What Serverless Is Not
A lot of people seem to have an overly broad concept of what serverless is, and it leads to confusion around the topic. Let’s take a moment to revisit what the serverless concept is at its core. Serverless is first and foremost the abstraction away of the operating systems, web/container applications and virtual machines that traditionally made up a Cloud based application architecture. Any platform that still requires management of the OS, installation of web servers, or VM or scaling configuration or is, by definition, not serverless. This eliminates most if not all non-managed services in the cloud, including most kubernetes clusters that organizations run today.
The vast majority of kubernetes clusters are running on top of traditional virtual machines and the operating systems that come with them. A kubernetes cluster deployed this way still requires OS maintenance and scaling management. Even using advanced management tools like Helm and other Infrastructure as Code tools only get you to something I would call “serverless – lite”. Your team is still responsible for all the configurations, virtual infrastructure, and maintenance it takes to keep the cluster running and available to your developers. If anything goes wrong below the container level, your infrastructure team is still on the hook for resolving it, whereas with a true serverless solution, the cloud vendor takes care of availability and performance issues. With any custom built kubernetes cluster you are also paying for excess capacity and can’t take advantage of a pay-as-you-go billing model. The cluster itself can scale, but only within the available VM set. Even just automatically adding and removing VMs to the cluster pool adds another layer of configuration and maintenance complexity.
The closest an organization can get to serverless using kubernetes is a managed cluster from a cloud vendor such as AWS EKS, or AWS Beanstalk, or Google GKE. Even these solutions are still more labor-intensive than a standard serverless solution since the customer is still responsible for the management of the clusters and the scaling. GKE does the best job of giving you a mostly hands off experience that allows for code deployment and scaling without a lot of traditional overhead. If you are interested in serverless tech, but your use case falls outside of what can currently be done with true serverless offerings, GKE can be a good alternative for your organization. In subsequent posts we’ll discuss when it makes sense to use serverless and when you may need something more customizable.