Elasticity

The Cloud has this characteristic because it can grow and shrink as demand changes.

We can expand horizontally (horizontal scaling) or vertically (vertical scaling)

• Horizontal scaling

  • Replicating resources

  • Open

    

    to

  • Open

    

    or

  • The number of instances is limitless

• Vertical scaling

  • Adding more resources to a unit

  • to e.g. increasing the number of CPUs or RAM

  • But there is a limit to how much can be added

  • The OS may not be able to physically access the amount of RAM on the new configuration

The fixed capacity problem

The traditional approach to provisioning infrastructure is to use historical data to estimate the number of required components. The problem is that you would either over-estimate or under-estimate the number of components. Leading to panic buying and provisioning of additional units or having wasted capacity.

An example of the above could be the launch of a web application requiring a number of physical web servers, let’s say 5.

As with most launches the number of required physical servers will be less then expected.

But as time progresses and the if the product is successful the initial capacity can be reached very quickly.

You now have to redo the maths and determine what the new capacity should, so you estimate it to be 10 and provision 10 more servers. But there is a downturn in the market and you now have more capacity than you needed

And this cycle of wakamo continues

The Cloud Solution

With the cloud model, you still need to do capacity planning, because there is a cost there. But unlike the model above as demand changes, AWS auto-scaling would bring servers in and out as demand changes. So the Capacity and Demand paths are in sync.