Debunking Cloud IaaS Mobility Myths

Many things in life appear great on the surface, but wisdom has taught us to never trust a book by its cover or believe in silver bullets. The latest story I frequently hear being pitched in IT circles is that of cloud IaaS Utopia. In this universe, workloads can simply move anywhere (between disparate providers and private data centers, for example) without consequence. Typically you’ll hear a few data points to justify the story, including:

• We use OpenStack, therefore your workloads can be run anywhere
• We use an open source hypervisor, so you can run your workloads anywhere
• We support Open Virtualization Format (OVF) import and export, so you won’t have any portability concerns
• We have a VM import and export tool, so you can easily add and remove VMs

The last three points are mainly VM-centric, so let’s begin there. When it comes to workload mobility, the VM has always been the easy part. Don’t get me wrong, VM import tools do a great job of dynamically removing the right device drivers and associated software, and properly preparing a VM disk for a new hypervisor; however, that is rarely a challenge today. OVF takes VM import and export beyond a simple vendor or provider tool and OVF’s extensibility allows a VM or an aggregate of multiple VMs to specify its management, security, compliance, and licensing requirements to the provider or management platform.

Moving Beyond the Checkboxes

So far, the openness story sounds legit, but holes often quickly emerge when you try to operationalize any new workload in a new environment. Operational issues such as orchestration, backup, disaster recovery (DR), security, identity and several requisite management tasks (such as performance, capacity and configuration management) ultimately impede true workload mobility.

Here is a list of considerations:

• Third party integration: It’s critical to understand how a third party solution is supported rather than just the fact that it is supported. Integration can occur at various parts of the stack (such as at the hypervisor management layer APIs instead of at a higher orchestration layer), meaning that moving to a new hypervisor could require product replacement or additional integration work and QA. It’s also important to understand how features are exposed through a platform’s API set (such as open source vs. proprietary APIs). Multiple API integrations may be required to operate the workload in a hybrid cloud.
• Third party software licensing: Can software that manages or runs in the VM have its licenses follow the VM to new infrastructure, or is a new procurement cycle required?
• Vendor ecosystem: Are all of your preferred vendors supported and provide rich integrations for the hybrid cloud environment? How easy is it to find details on third party integrations? Does the provider or vendor offer a solutions exchange that documents all third party integrations and supported applications?
• Application/service APIs: How are the APIs associated with applications and services in VM guests accessed? Natively? Via a proprietary wrapper governed by the service provider? Also, if the provider is exposing services through a proprietary or customized open source API, how easy or difficult will it be to recreate a similar API structure in your own data center or on another provider’s infrastructure?
• Management: Can the same management tools be used in traditional data center and cloud environments? Is a consistent API provided to simplify vendor support across multiple environments? Does switching providers require you to purchase new management tools (capacity, configuration, performance management etc.) or are new professional service and integration costs required?
• Security: Is security policy enforcement and management consistent across the hybrid cloud? Must new virtual security appliances and/or management software be purchased if a VM is moved to a new environment? Will different processes have to be developed?
• Networking: Do all network settings, functions and associated management capabilities persist across the hybrid cloud? Does the network have any hardware dependencies that might limit workload mobility? Are different APIs required in different environments?
• Storage: How is storage allocated and managed across the hybrid cloud? Are specific hardware resources required in the architecture? Are different APIs required in different environments?
• Identity: Is identity management consistent across the hybrid cloud?
• Logging and auditing: How are activities logged and monitored? How do those activities integrate with management tools across the cloud?
• Disaster recovery: How quickly can a VM fail over and recover in a new environment? If configuration drift exists across clouds involving any of the previously mentioned dependencies, DR may be measured in days instead of minutes.

I’m sure that with more thought I could easily expand the list, but hopefully you get the point. Mobility requires virtualization and management consistency across the entire operational stack. A few popular checkboxes doesn’t provide mobility, it provides a product marketing sound byte that plays well in a PowerPoint marketecture, but not in a true hybrid IaaS architecture.

Happy Ending?

Open source management frameworks like OpenStack are important and offer management integrations and features beyond what a single vendor might offer. When those integrations are needed, those solutions should be employed as part of the architecture.

When vendors or providers promise to support open standards like OVF and OpenStack, applaud their efforts. They have your interests at heart. At the same time, look across the entire management stack to see how much choice you really have. If the vendor or provider’s orchestration platform is driving the OpenStack integration, for example, review the costs and integration requirements associated with moving the orchestration platform as well. Also, look at the ubiquity of the provider ecosystem. Can you move workloads and maintain hardware independence and consistent management between public, private, and hybrid clouds, and does that extend to both the native provider and and ecosystem of third party providers? History has taught us that a combination of both open and de facto standards drive innovation, flexibility and choice.

We need to place big bets as we move forward into the cloud era. You know your technical requirements better than anyone. Align them to proposed solutions and look for the complete fit across all of your requirements. Don’t settle for a “silver bullet” that offers mobile utopia but is lite on the totality of facts that matter. Just like the beer, that silver bullet will let you down.