This week Amazon Web Services (AWS) has been in the news for offering a tool that imports VMware VMs to the Amazon cloud. You can read the announcement on the AWS blog here.
While this is a good and important step for Amazon, the announcement reminded me of a conversation I frequently have with clients – when it comes to mobility, converting the VM is the least of your worries.
In some use cases such as training, the underlying hypervisor may not matter. However, for most production roles hypervisor parity remains important today. For starters, consider test and development. For early stages of test, the hypervisor choice may be irrelevant, but for later QA and integration testing, most enterprises prefer to test on an environment identical to what they run in production. This is why most organizations consider the hypervisor (and a specific hypervisor version) part of the application certification process.
When you look at production workloads, the challenges are more complex. Switching hypervisors, replacing in-guest paravirtualized device drivers, and converting virtual disk storage formats is oftentimes pretty straightforward. However, significant challenges may occur with operational management. For example, if my backup software assumes a VMware backend and uses the vStorage APIs for Data Protection (VADP), switching out the hypervisor would require changes to how the organization backs up the VM. Of course, that could be offloaded to the provider, but you’d also need to check on long term archiving support and that data privacy requirements are satisfied. You’d also have to determine the implications on backup and archive if you decided to move the VM from the cloud back to your internal data center or to another provider.
The organization’s security software and associated policy enforcement may require a specific hypervisor, and the same can be said for additional aspects of operational management (e.g., capacity, configuration, and lifecycle management). So after moving a VM, I may need to rebuild integrations to my operational software as well, assuming the software supports the new hypervisor format and cloud IaaS platform.
In a pure public cloud context, many providers offer a wide array of management services, but in the hybrid cloud context integration with the organization’s enterprise management software is often necessary. Application owners shouldn’t have to care about the underlying hypervisor, but the infrastructure and operations teams have no choice but to care (due to the operational management software dependencies I just mentioned).
Many clients I speak with are working to be more cloud-like internally and are dabbling in public cloud IaaS, and most are planning for hybrid clouds but are not ready to embrace them at a large scale. A lot of work is necessary to build out internal IT infrastructure capable of leverage hybrid cloud resources, and that’s something I described in the document “Stuck Between Stations: From Traditional Data Center to Internal Cloud.” To Amazon, that means that they have time.
We have many clients that run workloads that have little to no operational management requirements and several are already using AWS for those workloads. The announcement by Amazon is a start in making workload mobility easier. I’m hopeful that Amazon will follow this announcement with a broader story around hybrid cloud interoperability. Supporting OVF would be a good start. OVF support isn’t about the present (I doubt that many AWS customers are asking for it), but it’s more about future hybrid cloud mobility. Having a standard metadata set that not only advertises VM requirements, but service requirements as well (e.g., availability, RTO, RPO, security, etc.) eases hybrid cloud mobility. I’ve said in the past that OVF would be even more useful if we had similar standards for runtime metadata (it’s only for import today), and I’m hopeful that it will get there.
Amazon can show how serious it is about hybrid clouds by outlining ways to support management interoperability. Interoperability is a benefit most often cited by Amazon’s competitors that offer VMware vCloud. It’s also what the OpenStack project is trying to drive.
Are Amazon’s VM Import tools the keys to a room in what VMware CEO Paul Maritz has called the ultimate “Hotel California,” meaning “…you can check out anytime you like, but you can never leave.” Or are these tools the starting point for a far broader hybrid cloud strategy? What do you think?