Hybrid Cloud's Burst Bubble

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?

Next, we have to figure out what to do about the data. Most applications and services require persistent or semi-persistent data of some sort. They access this data to provide the services that drive your business. As your applications run internally in your very own data center, they access that data locally at LAN or Fibre Channel speeds. When they burst into the cloud they…wait, what do they do now? That’s my second question for you: Where do your applications access their data when they burst?

Can you accept the latency of the burst compute capacity in the public cloud reaching back across the WAN to data in your data center? Can your WAN bandwidth support that additional load? Can your storage controller handle the additional requests? Alternatively, you may be able to keep enough of the data in the cloud for use during burst. On the surface, this makes some sense, but the issue is you’re now paying some kind of constant to maintain storage that’s used only when you burst. This really puts a damper on the available pay-for-use model of bursting.

Next is a conversation with your friendly neighborhood CFO. He or she is probably plenty happy with anything that reduces operating costs, and more so if it makes it a predictable cost or moves it from an up-front cost that must be eaten at once then depreciated to a monthly service fee. This means cloud-bursting is right up the CFO's alley. Or is it?

With cloud bursting, you’re asking the CFO's office to continue to bite off the traditional buy-up-front for predicted capacity method, but also accept that there will be fluke months where an additional unknown cost for IT will be incurred. Even worse, these fluke months will be totally unpredictable and automatically charged. Right now, your CFO can say no to a new spend for extra capacity; with cloud bursting, it’s all automatic and charged back. My question to you is, can you sell that to a savvy CFO?

The last question I leave you with is another hypothetical: You’re the CIO of your company--are you really willing to go to the CEO and say, "I am 100% positive that building aprivate cloud will save us on operational costs and provide great business agility/competitive advantage. What I don’t know is size and scale of our services and apps, so we’re going to take swag at it and let cloud bursting handle any under-sizing."

If you begin you’re cloud-bursting analysis with the business-decision-making process, you’ll typically find that it doesn’t make sense. There are circumstances where it works and use cases for it, but they will be the exception rather than the norm. Many business advantages will come from both private and hybrid clouds, but the cloud-bursting use case will not be a reality for most businesses.

For more of my thoughts on cloud bursting, see my post: The Reality of Cloud Bursting.