The Three Barriers to the Cloud, Part 3

· Cloud Aware Applications
Authors

This is the final of three articles on factors impeding the adoption of Cloud Computing. The first is here.

How do I get my gerbil to roar? How do I scale this thing?

Most applications are designed to run on a single computer. This makes them ideal to run in the Cloud as they fit nicely into a Virtual Machine. Initially this will work well, but as you increase the amount of work that the application must perform (i.e. deal with more users, crunch more data) there comes a point where the CPU is too busy or there is not enough Internet bandwidth to do the job.

Traditionally, it has been the responsibility of your staff to monitor all the computers and recommend new equipment or perform some re-engineering to improve performance. In the case of the Cloud, your staff may simply move the application’s VM around to take advantage of better hardware and hopefully realize the greatest efficiency out of the entire system. But as the application gets busier, it will ultimately begin to strain the best hardware available. From that point forward, the application will respond too slowly and performance will suffer.

Up to now, the next step to scale up an application has been to cluster a number of high performance computers together and specialize them within particular functions of the application such as responding to Internet requests or storing on high-throughput devices. This was a costly process as it involved the best engineers and most expensive equipment.

That’s all about to change. What’s hot now are applications that know they’ve been deployed with a virtual machine and that can ask for new resources to optimize their performance. “VM Aware” applications scale themselves subject to the resources available to them.

Let’s consider an example. Your firm wants to offer hosted email for a large number of users. In the past, that would be done by buying expensive high-end equipment and routing all of the email domains of your customers to one specific server address. You would then pay top dollar for a very high speed Internet connection and put a team of technicians together to monitor it constantly and make sure everything is working well. You re-engineer the system as needed by introducing more hardware when your customer traffic increases.

Now think about a VM Aware email server. Initially it is launched inexpensively within a single VM with limited CPU and low-end bandwidth resources. As it accumulates more email domains, the application itself realizes that the average time it takes to process an email has increased past a threshold of minimum acceptable service. No problem, it knows it is in a VM of limited capability so it sends a message requesting a VM upgrade.  This is well with preset costs, so the VM environment automatically moves the VM on to a faster machine, and reroutes the email traffic. Email is interrupted for only a few seconds and resumes on faster hardware.

Sometime later, as more customers accumulate, email delivery time deteriorates once again. This time however, the VM Aware email hosting application realizes that there are no faster resources out there, so it requests a second, parallel VM to be provisioned. This is within cost limits, so the VM environment complies and informs the original application instance of the new VM that is running. The original app contacts this new instance, specifies a sub-set of its email domains for it to take over and reroutes the domains to this new instance. Now the application in running within two VMs which are sharing the load. In the future, further VMs are acquired to cope with new email domains and the aggregate hosted email application continues to grow until the running cost of the total VM resources reaches the preset cost limit. Now, for the first time, operator intervention is required to decide whether the solution should be scaled further or new customers should not be sought.

This is typical behavior of a new class of applications adapted to run in the Cloud. It is important to note that VM Aware applications require much less supervision than their conventional counterparts. It is a matter of monitoring the performance of the application itself rather than of the virtual machines that house it.

With a little help from the VM provisioning service that responds to requests from VM Aware applications, it is possible to build resiliency in the overall application. If the VM’s are distributed geographically over many data centers, then partial failure can be absorbed invisibly to the end user.

The enterprise will move to the Cloud just as industry ultimately joined the electrical power grid. The economics demand this. The only question is how long this will take and which organizations will gain the advantage by being first movers. Keep your eyes and ears open for the technology companies that will make this possible.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: