With the seemingly endless announcements coming out of VMware / Broadcom regarding license and product changes, it's no wonder VMware customers are worried about the future.
It's also pretty obvious that the VMware competitors are loving the opportunity to tell a story about how you can switch to their solution, with no complications at all... and some of them even have the tooling to assist with this.
So, what's the problem?
Well, a migration, like any IT project needs two things... 1) Planning and 2) Execution. You don't just tear into a replacement of something as critical as your hypervisor...
Here's the rub though, even if the replacement vendors claim to have all the tools, to complete a migration like this, you should expect to spend many hours on the planning and execution. As a rule of thumb, 8 hours per VM would be a good starting point to help you estimate the overall time you might need (excluding actual data copy time). The scope basis of the estimate includes completing a full VM inventory, VM dependency mapping, outage planning, DR planning, license implication planning (eg MAC address changes, Windows reactivation), and a raft of other considerations (does your app vendor even support the app on a hypervisor other than VMware??). Now if you have just a handful of VMs, this is likely a trivial process, but as you get into the hundreds or even thousands of VMs, well, the time/cost is very very real. More often than not, you will also need to engage the services of an external consultant to help you, so then the costs start to stack up fast.
Even worse, for a long time now, VMware has sold its software as bundles, and these bundles include a range of ancillary tools. If you are looking to eject VMware from your estate, it's not just the hypervisor you need to consider, it's the replacement of the operational management tooling that surrounds it too. Oh, and don't forget about your VMware-trained IT staff, who likely have a decade's worth of experience managing your platform, and who now need to be retrained in something new.
If I may, I would like to offer a differentiated position on this...
Don't migrate from VMware to another Hypervisor.
Why? Because it's a move sideways. Other than saving you VMware license fees (which I'm sure are significant), it doesn't move your business forward in any way.
Rather, take this for the opportunity it is and use the time and money you are about to invest anyway, and instead migrate your VMs into Containers!
Now, I'm going to be very careful here, as don't mistake my recommendation as one to undertake a complete refactor of your application to micro-services and onto Kubernetes, although, if you can, great (and many ISVs already support their apps in containers), I'm talking about starting with something as simple as spinning up a Ubuntu container, using rsync to copy files over from your VM, install any required application components, and then use a solution like supervisord as the "PID1" process that the container runs as (and running this on plain old Docker on bare metal with shared storage). Sure, this is a derivative of a "lift and shift", but at least it gets you onto a more flexible platform/way of working.
There are even tools (google, aws) from Cloud Providers to help you with this... but to be honest, for a Linux engineer who has had some exposure to containers, it's relatively straightforward to do it yourself.
Lots of the container solution vendors are trying to convince you to switch to KubeVirt (or their variant of it), which is a way of running VMs, managed by Kubernetes. Whilst that is a neat technology, it really is just a VM-to-VM migration. Don't get confused by the Kubernetes component of this. I'm talking about actually putting your VM into a container, not a VM masquerading as a container.
So, if you want to exit your VMware estate, you have a choice to make... spend $$ and move sideways, or spend (likely the same) $$ and move forward...
As a former CIO, I know which option I would prefer.
What will you do?
Neil
COMMENTS