Raining On Cloud Bursting's Parade

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. Equally important--you can do it right now. You look like a hero. But before you start popping champagne corks and taking a celebratory lap, you will likely have some significant hurdles to get over. So much so that cloud bursting isn't likely for most of you in the foreseeable future.

I am not saying that cloud bursting can't be done today or that there aren't useful cases. Neal Sample of eBay presented his company's rationale on cloud bursting and why eBay is seriously examining cloud bursting. The short, 11-minute video is worth the watching. As an aside, companies like eBay that are willing to share the details of their costs and business models should be applauded. It's good for everyone.

Of course, how many of you are running a top 50 website today? So while eBay's example is extremely interesting and enlightening, and Sample's explanation of eBay's thought processes are instructive, eBay's IT needs aren't generally applicable to the rest of the enterprises out there. Christofer Hoff makes that point quite well in Incomplete Thought: Cloudbursting Your Bubble – I call Bull. (By the way, there is nothing new written about cloud computing that Hoff hasn't already written. He is the Nostradamus of cloud computing.) As Hoff points out, eBay is investing heavily in cloud technologies and is architecting its systems, which are subject to huge variations in demand, for the cloud. That is the single biggest difference between a company that has the resources and talent to tackle a big initiative and the rest of us.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.To do this well, you need to automate the data push to and from the cloud provider. Since there are no cloud standards for interfaces, nor even for virtual disk file formats, you will have to either write to each cloud provider's interface or make use of the existing APIs or a service like Enstratus to do the dirty work for you. In any case, that whole workflow needs to be sussed out, written up, programmed, implemented and tested.

Oh, and then there is the little matter of the network. If you are using an infrastructure as a service, you have to have a way to translate your network at least at Layer 2 for both data and storage into whatever model your cloud provider uses, including VLAN tags, IP addresses and other critical network components like DNS, authentication, access control, logging and monitoring, and so on and so forth.

Then there is getting users to the newly provisioned service. Arguably, that is the easiest part to handle once you get your head around global server load balancing, which Lori MacVittie dives into in Cloud Balancing, Cloud Bursting, and Intercloud. But the point is that you need extra systems to dynamically move traffic to the new systems and then bleed off the traffic when it is no longer needed.

Today's enterprise applications just aren't up to the task, or it would cost so much to retrofit into a cloudburst model that it wouldn't be worth the undertaking. If I were in charge of enterprise software development at a vendor, I'd make sure every new project had cloud capabilities built in from day one. That way, if a customer wanted to host the application in its own data center, from a cloud provider or in a hybrid of both, or simply wanted to cloud burst, the application would support it. But that isn't going to help you now or in the future.

Cloud bursting is a cool concept, and for companies like eBay, it has huge potential savings, but the hurdles are virtually insurmountable for most of us.