[Editor’s note: this is the first 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.]
Webster’s dictionary defines serverless as “The word you’ve entered isn’t in the dictionary. Click on a spelling suggestion below or try again using the search bar above”.
So, what is Serverless architecture exactly? It is a relatively new way of building software that has only become possible with the rise of cloud computing. Cloud Platforms like AWS and Azure (and many more!) have created a variety of serverless capabilities, services they operate so that you don’t have to. This includes patching, scaling, and fixing when things break; with all this being invisible to you and experiencing no downtime (as long as the cloud platform isn’t having issues of course). Using AWS DynamoDB as an example, it is a managed database that I can use without having to be concerned about scaling, downtime or general operational work. Sounds great to me!
So Serverless doesn’t mean there are no servers, there are many behind the scenes, just none that you need to be concerned with.
Evolution of Infrastructure
So how did we get here? When I think of running software, I see it in 5 different eras (so far!). Each step significantly reduces the amount of operational work to run the software you are creating..
Back in the good ol’ days, when you built software and were putting it into production, you were also buying servers to run it on. You were responsible for the health of the hardware components, the services being run on the system and the applications you built. If anything broke, hardware or software, it was your problem to solve.
One of the problems with the previous approach is that for the vast majority of the time, your physical servers were sitting around idle, not using all the capacity available. This became very expensive as you required more servers for different pieces of software that can’t be run in the same environment. Virtualization solves this problem by making a single physical server appear as many virtual machines, individual environments. The benefit being that you can run more software on fewer physical servers, saving a lot of money.
When cloud platforms became available to us, we now had virtual environments available to us without ever having to deal with the physical servers ourselves. Beyond the benefits of not having to worry about hardware, cloud pricing is based on usage. Before you had to pay for a server as an upfront cost and replace parts as needed, where now you can turn off a virtual machine over the weekend if it wasn’t being used as a way to save costs.
Virtualization was/is great, but still has you running a full Operating System, which includes a lot of unnecessary software you likely don’t need (GUI, printer drivers, minesweeper, etc). Containers are still run on Operating Systems, but with all unnecessary systems stripped out. Because these environments are running significantly less software, this means they are consuming less resources and you can run more of them on a physical machine (either one you’re running or in the cloud), making virtualization even cheaper than before.
With containerization and microservices being closely associated, coordinating multiple containers running a service is challenging, which is why an orchestration solution like Kubernetes is basically essential when running containers. Even though Kubernetes massively reduces the workload to run numerous containers, it is still a significant effort.
And now we finally make it to Serverless. We’ve already talked about using managed services for systems you’ll need like databases (or queues or storage, etc), but what about your code? In the Serverless world, you can focus on writing your logic without worrying about how it’s going to run. In AWS this is done using Lambda, for Azure this is Functions. Behind the scenes your code is running in containers and after many layers of virtualization + physical servers, but you never have to care!
In the second part of this discussion, we focus on the benefits of serverless architecture, including lower cost structure, decreased overhead, and greater ability to scale.