If you are currently in the IT business and rely on Internet infrastructure to serve data you probably know what a pain it is to manage those IT systems. Constantly having to manage servers to increase throughput, lower costs, ensure autoscaling and keep latency at bay is a tremendous effort. It has even spun a new role in the industry, the Dev Ops.
Amazon Web Services (I’ll be using them as the example since they are the leader, but other providers have similar resources) have made giant efforts to try to help developers with this aspect. One of the resources they offer is what they call Elastic Beanstalk. This effectively is a system that allows you to provision code to a number of instances that are behind a load balancer. The load balancer is the key, as it can deploy code into instances by taking them out of the group until they are ready and it handles auto scaling. Auto scaling is handled via triggers, for instance, if you use a CPU trigger, when the overall CPU usage goes over X% the load balancer will spun a new instance with your code and add it to your group, and when it goes below X% it will remove instances. Basically, it helps you manage instances while you maintain full control of everything. So, everything covered no? Amazon felt it was so great three years ago they made a strange video with a curious voice over (honestly, with the budget these guys handle you think they could do better) you can watch below.
However, the truth is this system has immense limitations, the first of which is what happens if you get a traffic spike. When you know you are expecting heavy traffic you can get ready for it by provisioning more instances, but what when that catches you by surprise? Imagine a blog post you don’t expect or some other type of uncontrolled media like an influencer. You are basically screwed, since the load balancer is not particularly agile at sensing something that doesn’t grow in a linear fashion (it typically uses health checks every 1 to 5 minutes), so your system would probably go down as your instances would get saturated.
So how do you solve this? How do you prepare for situations like this without having to spend vast amounts of money of infrastructure provision? One of the possibilties is going serverless, and we will analyse what it is and how it works in the next blog post 😉
Hope to see you there!