Recently while researching the concept of â€˜Cloud Burstingâ€˜ I received a history lesson in Cloud Computing after a misguided tweet at Chris Hoff (@Beaker.) My snarky comment suggested Chris needed a lesson in Cloud history, but as it turns out I received the lesson. My reference turned out to be a long debunked myth of Amazon cloud origins (S3 storage followed by EC2 Compute) the details of which can be found here: http://www.quora.com/How-and-why-did-Amazon-get-into-the-cloud-computing-business. The silver lining of my self induced public twitter thrashing was two things: I learned yet again that the best preventative measure for Foot-In-Mouth-Disease is proper research, and I got some great background and info from Chris, Brian Gracely (@bgracely), Matt Davis (@da5is), Roman Tarnavski (@romant), Denis Guyadeen (@dguyadeen) and others. This all began when I read Chrisâ€™s â€˜Incomplete Thought: Cloudbursting Your Bubble â€“ I call Bullshitâ€™ (http://www.rationalsurvivability.com/blog/?p=3016.) Chris takes the stance â€˜TODAY cloud bursting is BS…â€™ to quote the man himself. The â€˜todayâ€™ is the part I didnâ€™t infer from his blog post (lack of cloud history knowledge aside.)
Before we kick off letâ€™s look at the concept of Cloud Bursting:
In a broad strokes fashion cloud bursting is the idea that an application normally runs in one type of cloud and is capable of utilizing additional resources of another cloud type during peak periods, or â€˜bursting.â€™ The most common example of this type of utilization would be a retail company utilizing a private cloud for day-to-day operations bursting to the public cloud for peak periods such as a holiday season.
At first glance cloud bursting looks like a great way to have your cake and eat it too. You get the comfort and security blanket of hosting your own applications with the knowledge that if your capacity spikes youâ€™ve got excess available in the public cloud on-demand with a pay for use model.
The issue is in the reality of this system, as several problems come to play:
- If youâ€™ve designed the application to be public cloud compatible why wouldnâ€™t you just run it there in the first place?
- Building a new private cloud infrastructure that doesnâ€™t support your capacity demands is short-sighted.
- Designing an application for cloud bursting capability is no easy task and would probably require some portion (data?) to exist in the public cloud constantly skewing the benefits of the â€˜on-demandâ€™ concept of cloud bursting.
- Complicated cost model for any given application in which infrastructure is purchased up front and depreciated over time alongside pay-for-use costs as the application bursts
After carefully looking at these and other issues cloud bursting will most likely not be a reality for most enterprises and applications, and is currently a very rare cloud use case.
Note: Chris Hoff draws a distinction which I wholeheartedly echo: Cloud bursting is separate from Hybrid cloud approaches where specific apps are run in public or private clouds based on application/business requirements. The issue above is specifically directed at individual applications bursting between clouds.
For the average enterprise cloud bursting is not an option today and will probably not be in the future. While hybrid models can thrive, i.e. some applications run privately and some publicly, or a private cloud designed to failover to public cloud etc. individual applications bursting back forth between clouds will not be a reality. Exceptions exist and there will still be use cases for cloud bursting, but they will be corner cases. Things like high Performance Computing (HPC) can lend themselves well to cloud bursting due to the dynamic and distributed nature.
Another possible use case for cloud bursting is environments that heavily utilize development and test systems but must utilize on-premise resources for production due to requirements such as security. In these cases the dev/test may be capable of running in the cloud but can more cost effectively reside locally in the private cloud during off peak production hours. The dev/test systems could be designed so that they burst to the cloud when production peaks and spare cycles are sparse.
6 Replies to “The Reality of Cloud Bursting”
A situation where cloud bursting is likely to become a short-term reality is when organizations utilize a public cloud provider to host their private clouds. In these cases, the organizations need only purchase the infrastructure components required for typical business. The cloud provider can efficiently supply the extra capacity when required.
Steve, great use case! Thanks for the comment.
Re “For the average enterprise cloud bursting is not an option today and will probably not be in the future.”, I should mention that regarding the “future” part, if you see the Future of Cloud survey at:
You’ll notice that there are indications that people are or will be looking for cloudbursting support. I am going by the numbers for functionality like interoperability and mobility in the cloud that the survey pointed to. Of course, I assume that interop and mobility in the cloud together point to something similar to cloudbursting. Would love to know your thoughts. Thanks.
Thanks for the comment and additional information!
A fascinating discussion is definitely worth
comment. There’s no doubt that that you should publish more on this topic,
it may not be a taboo matter but generally people do not talk about these issues.
To the next! Kind regards!!
Comments are closed.