The new Amazon Web Services vCenter plug-in sounds like a boon for VMware admins looking to use additional capacity from AWS. One can provision new VMs, manage additional capacity and even convert existing VMs using a single management console ie the familiar beloved vCenter. Its a step in the right direction for the industry as it rapidly moves from virtual to cloud environments. Not surprisingly, VMware responded by saying don’t be fooled. The truth is, for those familiar with vCenter its tempting to stay in the comfort zone but the AWS vCenter plug-in could lead the uninitiated down a rabbit hole.
Obviously both VMware and AWS have unique infrastructure benefits. If your production applications are running on VMware, often the pragmatic decision is to leave your production running on premises (because the migration costs will likely outweigh the benefits) but start running your dev/test environments for those applications on AWS (because the public cloud is ideal for temporary workloads with bursty capacity needs).
So why is the AWS vCenter plug-in something to use with caution? Because:
1. Importing a VM from ESX to EC2 is only the first step in cloning your VMware application in AWS
After importing a VM you still need to configure all your VM tools, drivers, networking, storage. And because even after you go through the whole rigamarole you end up with a cloud setup that looks very different from your original application environment running in your data center on VMware. Basically you will go through various migration steps only to find that eventually the destination may not be quite what you envisioned.
- Import/convert your VM from vmdk to AMI
- Make sure your OS is configured with the same packages, users, daemons, parameters etc.
- Deal with differences in the networking between your on-premises VMware environment and AWS (even when using VPC), such as dependencies on specific device types, support for vLANs, broadcast/multicast, SPAN ports, etc.
- Figure out how to handle your physical/virtual appliances particularly those not supported in AWS
- Determine if you can possibly find a compromise or workaround for any of your operating systems that not supported in AWS (such as Windows desktop versions, FreeBSD etc.)
- Deal with software licenses that are often tied to specific parameters that will be different in AWS such as BIOS UUIDs, CPU IDs, MAC addresses etc
- Compute, network and storage performance on-premise and in AWS is completely different. Moreover, run-time performance on EC2 can change over-time (see: consistency of performance between different clouds).
Essentially, more often than not you end up making invasive changes to your application and at the end of the day is your application instance in the cloud is no longer identical to the production instance running in your data center.
2. Managing heterogeneous clouds is not about VM conversion
VMware and AWS are very different environments and unless a hybrid cloud infrastructure is built to truly normalize them, you are better off understanding their nuances and managing them separately. While being able to use the same set of permissions is nice, the cost of making incorrect assumptions across environments is rather high. Also, truly operationalizing your environment with a high degree of automation requires uniformity in key concepts.
3. Multi-tier application environments consist of multiple VMs
Even if you were able to provision and/or import and then configure a few individual VMs using the AWS vCenter plug-in, you will quickly find yourself in a VM management nightmare if you are dealing with multi-VM applications that have complex networking and storage. The level of automation required to snapshot and clone entire multi-VM app environments for dev/test and pre-production environments is non-trivial – and likely to be different on VMware and AWS.
It makes sense to step slightly outside your comfort zone and look for a solution that is purpose-built for your intended usage rather than adopting a band-aid of a solution that only complicates matters in the long run. No doubt, there is a growing need for enterprises that have existing VMware environments and want to start using AWS for dev/test. However, the AWS vCenter plug-in which provides a familiar user interface, doesn’t quite address that need. While there are multiple ways to approach the challenge, nested virtualization takes a unique approach by allowing you to encapsulate and run entire multi-VM VMware based workloads unmodified in AWS or any leading public cloud, for development environments, QA/test environments, continuous integration, UAT environments, upgrade testing and training.New AWS vCenter Plug-in – The Good, Bad and Ugly