Glad you asked, and in my mind, there are different things that customers mean when they talk about ‘bursting to the cloud.’
The Wrong Way – SIMMULANTS
- Spontaneous / Simultaneous migration of multiple workloads to a provider due to massive influx of unanticipated requests / orders / compute requirement. (“SImultaneous Migration of MULtiple ApplicatioNs To a Service provider” – SIMMULANTS – I am coining a new acronym to save myself some typing)
- This, of course, is what most customers think about, and is also the #1 misconception, in my mind, of what ‘bursting to the cloud’ means.
I remember a few years ago, speaking with customers about VMware Site Recovery Manager and its ability to ‘automatically’ fail virtual machines over to a new location. It can do that, but it is only ‘automatic’ if someone with the authority to do so gives the order, and someone pushed the ‘big red button.’ THEN it’s ‘automatic’… The same is true here. The only way you could ‘burst’ to the cloud in the sense above is if you:
- Had a stretched VMware cluster, with one side in your own facility, and the other side off premises.
- This requires the ‘off-prem’ facility to have a RTT latency of less than 10 ms
- (Optionally) Had federated storage (VPLEX) for support of long-distance vmotion
You know as well as I few customers are there yet… Furthermore, I don’t think any customer is going to want to have such an unpredictable relationship with their provider…. How would that conversation go?
“What do you mean… We owe HOW much? When did that happen? Why wasn’t I notified? That wasn’t budgeted…”
and so on….
Similar to the Site Recovery Manager discussion, however, there is a rational answer to this…
The Right Way – PEGASUS
- Planned scale-up activity in a provider’s facility in anticipation of expected increase of required work… (“PlannEd Scale-Up in a Service provider” – PEgASUS)
This is what several customers do, and of course can map to a business plan that a customer can execute on. The methodology of how to get to the provider is open for discussion here:
- Use vCD and vCloud Connector to move one or more vApps out to the provider…
- Scale up using new workloads with templates from vCenter or vCD
- Use VMware SRM to move a bunch of workloads out to the provider
- Use vMotion (though of course the infrastructure requirements are more rigorous here)…
It seems to me really only #s 1, 2, and 3 are feasible for ‘bursting,’ and while #4 is technically feasible, it represents a high burden of labor to get it set up (which is sort of contradictory to the whole point of cloud elasticity). In addition to the burden of setting it up, #4 also suffers from the business issues I alluded to earlier – putting an infrastructure in place to allow spontaneous migration of multiple workloads to a provider kind of kills any attempts at thoughtful planning and budgeting.
The problem now becomes clear. If the only way to feasibly ‘burst’ to the cloud is to use some kind of ‘cold migration’ strategy (like nos. 1-3 above), that implies the workloads must be pre-provisioned and ready to go… ready for someone to give the ‘thumbs up’ and push the proverbial big red button. This actually would work pretty well, assuming we know our business trends, and can reasonably predict when the bursting is necessary. So should we even consider planning for ‘The Wrong Way’? As technology improves, certainly the capability to allow for SMMWP will improve as well, however I can’t actually see an IT shop embracing that model without some serious changes to their internal business model (see Five More Minutes on the Cloud).
What are your thoughts? I would love to know what others are doing…