A question about elasticity in the cloud was recently brought up in the Cloud Computing LinkedIn Group that got us thinking about tips and tricks about implementing your own cloud solution and we want to share them with you!

The following question was asked:

“I want to know how elasticity works in Cloud if implementing a private cloud. How does one implement the features of resource allocation and streamline it the same way Amazon AWS does? I mean automating the way resource allocation works in a private cloud setup.”

This is a great question and it highlights the fact that there is a lot of confusion in this area and it almost always stems around definitions – there just isn’t enough clear, consistent information out there to help people understand what can be complicated concepts.

I’d like to answer this question by expanding a bit on some of the key words floating around.

A private cloud solution means using your own equipment, either on your premises or hosted with a provider, which means your total computing capacity is limited to that of the equipment. If you are going to take this direction, it is also important to note that you’re paying for all of this equipment –often in full or on a monthly lease. 

From a compute capacity perspective a private cloud does not provide elasticity. Quite the opposite: with a private cloud, you are working with fixed capacity that you’re paying for, regardless of whether it is being fully utilized or not.

But this doesn’t mean your hands are tied.

From an application perspective, you can still create elasticity by installing software to allow either a) multiple instances of virtual machines to run or b) sub-dividing the operating system so that applications are assigned small, independent slices (typically called processes), and an orchestration software to increase or decrease the compute capacity allocated to the application.

Here’s an example to bring this to life for you.

Let’s say you are running a classic scale-out three-tier application – web servers to handle the session, application tier where the functional logic really resides, and a database tier. In a situation like this, you can start with just three virtual machines (VMs) – one for web, one for application, one for database – all running on your own private cloud.

But if the web application becomes popular, and you have more users than a single web server VM can handle, then through the orchestration software, you will need to fire up a second instance of the web server and balance the traffic.

To the application, this looks like elasticity, even though you have no total capacity elasticity. It is the orchestration software that plays the role of allocating the resources by creating new instances of VMs.

While orchestration software is necessary; writing it on your own is not easy. What typically happens is that you will need to call the hypervisor APIs directly to orchestrate the instantiation of the VM and inject the OS into the VM shell. The easier way is to template the process so you start with the OS and then instantiate the VM. You then have to ensure networking connections before you can actually use it. This also implies you also need to build some sort of total capacity monitoring tool so you don't wildly allocate the resources as well.

This is a just very simple high level overview of orchestration. If you have more complicated equipment such as non-local disks (SAN or NAS) or actual switches, you may have to extend the orchestration software to work with those as well.

If you have any further questions or ideas about implementing this kind of cloud solution, please share them with us and comment below!