Network Computing is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

  1. Home
  2. Cloud-infrastructure
  3. Raining-cloud-burstings-parade
  4. Page
  5. Raining On Cloud Bursting's Parade: Page 2 of 3
Cloud Infrastructure

Raining On Cloud Bursting's Parade: Page 2 of 3

Cloud bursting--the ability to dynamically move processing temporarily to a cloud provider in response to some excess demand--sounds like such a great idea. If successful, you can continue to handle the excess burst without having to acquire new hardware, software and licenses, and, equally important, you can do it right now. But before you start popping champagne corks and taking a celebratory lap, you will likely have some significant hurdles to get over.
Mike Fratto
August 09, 2011

There are number of things that are going to make cloud busting an impossibility for most enterprises. Joe Onisick, technical solutions architect at a large systems integrator who writes his own blog at definethecloud.net and is a Network Computing contributor, describes some of the hurdles in The Reality of Cloud Bursting. I think the hurdles are much larger, however.

First and foremost, most enterprise applications, including web applications, are not written in a way that allows them to scale properly. They are monolithic in nature and so tightly coupled that trying scale in any component would take a complete redesign of the application. To retrofit an existing application, it would have to be decomposed into logical functional units, have new interfaces created to interact with the rest of the system, have a way to maintain status with the peer processes, accept new transactions on start-up and bleed off transactions at shut-down, and maintain a cohesive state. Think service-oriented architecture. That's no easy feat to build for a new system, much less to retrofit into an existing one. Oh, and make this work anywhere. Bonus points for making it work whether peers are local or remote.

Next, there is the little matter of getting the application and data out to the cloud provider that you want to burst to in a timely manner. You may not need to push your entire database to the cloud. You might be able to replicate only the currently relevant data to the cloud, but now you have the added requirement of making sure your data is coherent. I suppose you could backhaul your transactions from the cloud to your databases, but that seems like it would be a significant drag on responsiveness, unless you had really fast pipes (low latency). Onisick points out that you could pre-position the bits, but then you offset some of the cost savings of "on demand" and you have to keep both data sets replicated. Once the burst is done, you have to pull the data back and integrate it with your existing data sets. This isn't insurmountable, but it is a difficult task.

Tags:

News
Cloud Infrastructure