Hybrid Cloud's Burst Bubble

Upcoming Events

Take a fresh look at video conferencing ROI. It's not just about sunk costs, but the ability to measure existing capacity and future savings potential for your organization. How are employees adopting video conferencing today? What's working and what's not? And what's the roadmap for the future? Hear from one leading company who is bringing a new approach to delivering on the promise of cost savings via virtual collaboration.

See what others are doing to make it work - increasing video utilization and decreasing travel expenses without additional investment.

Register Now!

See more from this blogger

Posted by Joe Onisick
December 07, 2011

One of the more hyped use-case examples for hybrid cloud is cloud bursting. And why not? It's truly the have-your-cake-and-eat-it-too scenario. During normal business operations, your systems run in-house on private cloud infrastructure, and during unforeseen or unpredictable peaks, your services burst to excess capacity at your public cloud provider(s) of choice. It's IT utopia, right? It’s the comfort of maintaining your own systems with the insurance of endless available capacity for the unknown.

At this point, geeks, managers and execs alike jump straight into the "how" of getting it done. Whiteboards are drawn, erased and drawn again, vendor phone calls are made, and, repeatedly, ‘Yes, we can help with that’ or ‘Our product does that’ is heard. I’ve participated in these same discussions, merrily frolicking into the "how" thought experiment without stopping to think about the ever-more-important "why." Why would I want to burst? What business advantage would I gain? Is bursting the right solution to the problem of capacity? Will bursting help me accomplish my organization's mission?

The answer to those questions will most typically be no, but don’t take my word for it, instead join me on a thought experiment:

First, let’s set a very generic and loose list of design requirements for your bursting services and applications:

Must be designed for compatibility with the public cloud provider(s) of choice

Must be designed so that all or some portion can be run in that chosen cloud provider

Must be within acceptable performance tolerance when servicing over the WAN via said cloud provide.

Must meet security and compliance regulations while hosted in public cloud

OK, base requirements are defined, and easy enough to meet. In fact, plenty of people are meeting those requirements for their services. Those people are now happily running their applications in, wait for it, public clouds. My question for you for part one of our experiment: If your app is designed for, and compliant with, public cloud deployment, why are you rolling out infrastructure for it internally?

Of course, you could answer with things like legacy investment protection, which does have a play. In those cases, you’ll need to assess whether the hardware/software investments you’re using to make that legacy hardware into a public-cloud-compatible private cloud are worth it for a service that can go straight to the cloud. Could you push that application to the cloud and migrate a non-cloud-friendly legacy app or latency-sensitive app to the existing hardware?

Page: 1 | 2 | Next Page »