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.

Hybrid Cloud's Burst Bubble

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?

    • 1