Elasticity does not equal Scalability
Elastic Load Balancing (ELB), Elastic Compute Cloud (EC2), Elastic Beanstalk, Elastic File System (EFS) and so on. Many Amazon services feature ‘Elasticity’. They can definitely scale, but they are not branded as Scalable for a reason (e.g. Scalable Beanstalk). Let’s start by reviewing the basic definitions of terms.
What is scalability?
Scalability is the capability of a system, network, or process to handle a growing amount of work, or its potential to be enlarged in order to accommodate that growth.
To scale horizontally (or scale out/in) means to add more nodes to (or remove nodes from) a system, such as adding a new computer to a distributed software application.
To scale vertically (or scale up/down) means to add resources to (or remove resources from) a single node in a system, typically involving the addition of CPUs or memory to a single computer.
What is elasticity?
In cloud computing, elasticity is defined as “the degree to which a system is able to adapt to workload changes by provisioning and de-provisioning resources in an autonomic manner, such that at each point in time the available resources match the current demand as closely as possible”.
The key factor on Cloud economics
Just by redeploying your good-old-app into a cloud provider (also called lift and shift) will not leverage the benefits of the cloud. This has also been mentioned in the latest edition of Technology Radar from Thoughtworks in Nov 2016. You need to be able to scale it first to then be able to automate the provisioning and de-provisioning of resources.
Being able to automatically allocate resources to closely follow demand on your system will allow you to not be under provisioned if load is greater than expected or over provisioned in which case you would be spending more than what you should. Figure 1 describes under and over provisioning plus the ideal of elasticity.
With great power comes great responsibility
Even that elasticity is not the cause of memory leaks or performance issues, dynamic provisioning may hide them at an operational expense.
As described in Gregor Hohpe’s book 37 things one Architect knows, in the chapter Control is an illusion:
We need to be cautious about auto-scaling features since they are able to absorb sudden load spikes without human intervention, but can also mask serious problems. For example, if a new version of the software performs poorly, the infrastructure may attempt to auto-compensate this problem by deploying more servers.
Memory based costing
Memory leaks could be an expense killer since cloud providers charge mostly for memory allocation rather than cores. If you have a look to Figure 2 EC2 comparison table, doubling the memory allocation basically doubles the on-demand cost, having almost a lineal relationship between memory and cost. Having more memory allocated is more expensive than getting more cores. More on this topic on Chris Bailey’s Cloud Economics presentation.
