A few years ago, cloud was the buzzword heard on the street. Everyone was talking about moving on-premise IT resources to the cloud, whether that’s Amazon AWS, Microsoft Azure or Google Cloud, that didn’t seem to matter as much as just hurrying up to make the move. Entire companies moved millions worth of equipment and software from legacy hardware to brand new environments, hoping for a cost reduction and improvement in reliability. There’s a lot to be said about leveraging the cloud to save money, and it’s true that in many cases it does make sense. Chances are that a small or medium company is going to be much better served by hosting their computing workloads with a giant like AWS than they are trying to run their own equipment. It’s a simple matter of scale.
But like everything in technology, the landscape changes quickly. Now, the buzzword is serverless. This is the concept of foregoing servers altogether and instead focusing on just the software, the code itself, and not even worry about things like virtual machines, operating systems or even salability. Is this a pipe dream only worth it for small, specialized workloads, or is there some legs underneath the move to a serverless architecture.
To compare the two, let’s first look at what a traditional cloud environment looks like. This is a very simplified diagram of what a simple web app may look like on AWS:
In a typical environment, you have one or more load balancers accepting traffic from users all around the world. These can be located at geographically significant edge points, so that a user in Europe gets redirected to one of AWS’ European data center, while someone in California ends up on the west coast. Then, you have individual EC2 instances running your software stack. These are nothing more than virtual machines running Windows or Linux, along with everything that’s involved in having a full operating system to maintain: software upgrades, regular backups, handling software libraries, OS-level security, and so on. Moving to the cloud means that you no longer need to worry about the hardware, but the entire software stack is still in your hands.
Finally, our simplified model has storage for static assets, in this case S3, and databases which could be MySQL or Microsoft SQL Server running on RDS. Note that there’s often a lot more pieces involved, such as Route53 for DNS, CloudWatch for logging, SNS for notifications, and so on, but the point is that the main parts of the puzzle resemble what you would find on premise, namely a bunch of virtual machines with databases behind them, and you have to worry about a lot of the same things whether you run them in the cloud or in your own environment.
Now let’s see a similar diagram for a serverless architecture:
Here, the user comes in a similar way, but instead of connecting to a web app running on a virtual machine, the user is sent through an API gateway to a Lambda function. This could be anything from a simple Python script to a fully featured web app. Lambda supports a lot of different programming languages and libraries, allowing you to deploy a vast array of software solutions. From there, the function runs and connects to a DynamoDB table, while static assets are still loaded from S3.
The key difference between the 2 models is that the main piece of the puzzle that you’re maintaining is the code itself. Whether you upload your code to Lambda via a ZIP file, or use a complete CI/CD workflow, the result is just a piece of code living in the cloud. The cloud provider, in this case Amazon, then takes care of the rest. What actually happens behind the scenes is eerily similar to the first model, in that the code itself does run on virtual machines that get automatically provisioned and scaled on your behalf, but you never need to worry about that. You don’t care whether it runs on Windows or Linux, you also don’t worry about software updates, OS-level security or backing up your VMs. The only piece you care about is your code.
So there’s a lot to be said for serverless, but is it the natural solution for all your cloud deployments? Here’s a summary of the key differences you need to keep in mind:
So, what’s the bottom line? Should you take advantage of the serverless cloud? This all depends on your needs, and there is no right answer for everyone. Serverless makes a lot of sense for cloud native workloads, things that are meant to be highly available and highly connected. If it’s a new application, then it’s even better since you can build it from the ground up to be serverless. Those types of architecture can see huge cost savings in the long run. If you’re dealing with legacy applications however, especially monolithic software that rely on specific environments or have a heavy dependence on the file system, then it’s likely not going to do well as a serverless app.