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:
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?