Eureka!

Perhaps I’m way behind the rest of you, but I recently had a “Eureka, I get it!” moment regarding hybrid clouds, thanks to a VMware presentation I attended. Let me see if I can relive that eureka moment by playing back to you what I learned. You be the judge of whether I did in fact get it. Perhaps you’ll even have a mini-moment yourself, vicariously through my experience. First, to be clear, I’m talking about understanding the difference between a true “hybrid cloud” and the “hybrid cloud deployment model.” “What, they aren’t the same?” you ask. Apparently not, as I’ve come to learn. While cloud solutions offer an array of benefits, concerns amongst IT decision makers about security, compliance, data privacy and data sovereignty have fuelled the cautious approach being taken to enterprise cloud adoption. Many cloud-adopting organizations have chosen to restrict core business-critical applications to dedicated private clouds, either on-premise or hosted by a third party, while deploying only non-core office and support functions to public clouds. This is the Hybrid Cloud Deployment Model – using a mix of private and public cloud(s). A potential drawback with hybrid deployment that stems from the fact that the private and public clouds are separate and not connected in any way is the difficulty in moving workloads back and forth between them. The architecture and technology stack underpinning a private cloud infrastructure may be totally different than that used by a public cloud service provider. As a result, moving a workload from the private cloud may require re-architecting it for that different public cloud infrastructure. A true Hybrid Cloud, on the other hand, consists of private and public clouds that are ‘architecturally connected’ – the private cloud and the public cloud are based on the same architecture and technology stack. Workloads can be moved back and forth easily, without the complexities of having to re-architect or re-build the application environment or re-assign IP addresses with every move. During peak business periods, for example, workloads can be ‘bursted’ from the private to the public cloud, where resources can be scaled up more quickly and typically at less cost than scaling-up in-house infrastructure. After the peak period, the public cloud resources can be scaled back and workloads and data can be moved back in-house, with no infrastructure compatibility issues. That’s the difference. Hybrid cloud deployment model = using a mix of public and private cloud services, and using them for separate performance requirements. True hybrid cloud = public and private clouds that have the same architecture and set-up, allowing for easier load sharing during peak periods. Since the source of my newfound knowledge was VMware, I suppose a plug for them is only fair – VMware’s new vCloud Hybrid Service provides this true hybrid cloud capability. With a private cloud based on a VMware stack and a similarly architected public cloud, workloads can be moved back and forth easily as the demand for additional resources increases and decreases. And with the infrastructure built on vSphere, the same level of security is available in the public cloud as on-site. OK, how did I do? Am I at least on the right track? Learn anything yourself?