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:
- Serverless deployments are more costly to implement. If you’re trying to convert an on-premise solution to a serverless one, then there’s no doubt that you’ll have to do a lot of refactoring. Serverless code is fundamentally different from traditional code because it has very limited access to the environment. You need to rely heavily on other cloud offerings like DynamoDB, S3, SNS and so on, instead of the file system.
- In the long run, serverless environments will be much easier to maintain. Once your deployment is done, the benefit is very real in the long run. Not having to care about auto-scaling, software updates, new versions of Linux or Windows, these are all things that will make your life a lot easier, and save you money in the long run. The less you’re responsible for, the less you have to worry about, and the whole idea behind serverless is to completely shift responsibility for the entire environment to the cloud provider, and leave you to worry only about your own code.
- Having less to maintain means higher reliability. The whole idea behind the cloud is that a large datacenter run by Amazon or Google is far better equipped to provide reliable, secure and scalable services than you could as a small or medium organization. This is doubly true for serverless, because you push more of this maintenance onto the cloud, namely the software stack.
- You end up locked in a specific environment. Perhaps the biggest drawback is vendor lock-in. On top of the fact that it takes longer to refactor your application for the serverless cloud, you then end up with an architecture that is highly tailored to a specific cloud vendor. Moving a workload from one cloud VM to another cloud VM is trivial, but if you embrace serverless on AWS, it’s going to be very hard to move to Google or Azure down the line.
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.