(c)iStock.com/Artush
Modern IT infrastructure needs to be highly flexible as the strain on servers, sites and databases grows and shrinks throughout the day. Cloud infrastructure is meant to make scaling simple by effectively outsourcing and commoditising your computing capacity so that, in theory, you can turn it on and off like a tap. However, most approaches to provisioning cloud servers are still based around the idea that you have fixed-size server “instances”, offering you infrastructure in large blocks that must each be provisioned and then configured to work together. This means your infrastructure scaling is less like having a handy tap and more like working out how many bottles of water you’ll need.
There are traditional approaches to ensure all these individual instances work efficiently and in unison (so that those bottles of water don’t run dry or go stagnant); one of the more popular tools for cloud capacity management today is the load balancer. In fact, load balancers are quite often bought alongside your cloud infrastructure. The load balancer sits in front of your servers and directs traffic efficiently to your various cloud server instances. To continue the analogy, it makes sure everyone drinks their fill from the bottles you’ve bought, using each bottle equally, and no one is turned away thirsty. If your infrastructure undergoes more load than you have instances to handle, then the load balancer makes an API call to your cloud hosting provider and more servers are bought and added to the available instances in the cluster. Each instance is a fixed size and you start more of them, or shut some down, according to need. This is known as horizontal scaling.
Existing virtualisation technology also allows individual server instances to be scaled vertically after a reboot. A single instance can be resized, on reboot, to accommodate increased load. This would be like going from a small bottle of water to a 5 gallon demijohn when you know that load will increase. However, frequently rebooting a server is simply not an option in today’s world of constant availability, so most capacity management is currently done by adding servers, rather than resizing them.
However, there are many challenges with this traditional horizontal scaling approach of running multiple server instances behind a load balancer. The current situation wherein extra servers must be spun up to handle spikes in load means greater complexity for those that have to manage the infrastructure, greater costs in having to scale up by an entire server at a time, and poor performance when load changes suddenly and extra servers can’t be started quickly enough. Since computing power is provisioned in these large steps, but load varies dynamically and continuously, it means enterprises are frequently paying to keep extra resources on standby just in case a load spike occurs. For example, if you have an 8GB traditional cloud server which is only running 2GB of software at present, then you still will be paying for 8GB of provisioned capacity. Industry figures show that typical cloud servers may have 50% or more of expensive, but idle, capacity on average over a full 24/7 period.
The latest developments in the Linux kernel have presented an interesting alternative to this approach. New capabilities of the Linux kernel, specifically namespaces and control groups, enabled the recent rise of containerisation for Linux cloud servers in competition to traditional virtualisation. Container-based isolation, such as Linux Containers (LXC), Docker and Elastic Containers, mean that server resources can be fluidly apportioned to match the load on the instance as it happens, ensuring cost-efficiency by never over- or under-provisioning. Unlike traditional virtualisation, containerised Linux cloud servers are not booted at a fixed size, but instead individual servers grow and shrink dynamically and automatically according to load while they are running.
Naturally, there are certain provisos to this new technology. Firstly, as it currently stands, a Linux host can only run Linux-based cloud servers. Also, the benefit of not needing a load balancer at all is most relevant to servers which scale with the resources of a single large physical host server. Very large systems that need to scale beyond this will still require load-balanced clustering, but can also still benefit from vertical scaling of all of the servers in that cluster.
Vertical scaling of containerised servers can therefore handle varying load with no need to pre-estimate requirements, write API calls or, in most cases, to configure a cluster and provision a load-balancer. Instead, enterprises simply pay for the resources they use, as and when they use them. Going back to our analogy, this means you simply turn the tap on at the Linux host’s reservoir of resources. This is a giant leap forward in commoditising cloud computing and takes it closer to true utilities such as gas, electricity and water.
