VMware wants to charge me how much???

The shakeup of ‘Private Clouds’ and the possibility of a Googley Future.

Source: imgflip.com

I suspect that at this point, most people are aware of Broadcom’s recent acquisition of VMware, the market leader in X86 Virtualisation, and have heard the horror stories of some companies being quoted 10x increases at renewal.

Many organisations’ status quo of running their ‘private clouds’ on VMware is being challenged overnight. Many are now looking at alternatives to find a long-term home for their business-critical workloads.

I appreciate there are many possible solutions from various vendors, all jumping on the opportunity Broadcom’s VMware licensing changes create.

Perhaps unsurprisingly, I want to present my ‘Googley’ view of the world.

A Googley Future

So why Google? Well, there are many reasons, especially for those looking to re-platform VMware:

• Google Cloud’s VMware Engine (GCVE) enables you to run hyper-converged VMware nodes with high availability, including stretched clusters in some geographies.
• Access to Google’s multitude of other groundbreaking services, such as BigQuery, Spanner, and AlloyDB, to name just three.
• Google’s global-spanning network is leveraging its investment into transoceanic fibre.
• The Greenest Hyperscaler in the industry is backed by 100% renewable energy and committed to running its data centres using carbon-free energy by 2030.
• Google’s AI services, such as Vertex and Gemini as well as dedicated hardware such as the Tensor Processing Units (TPUs).

So now you are sold on the Googley vision, what are the options for migrating VMware workloads?

Replatforming with Google Cloud VMware Engine (GCVE)

Source: https://blogs.vmware.com/cloud/2021/05/18/intro-google-cloud-vmware-engine-deploying-gcve-sddc-hcx/

I will start with the most obvious choice for VMware workloads in Google Cloud, namely GCVE. This runs the VMware we all know and love on nodes in a data centre closely peered with seamless, high-speed connectivity into 19 Google Cloud regions (at the time of writing).

The more specific technical details of this are (at the time of writing):

Two node types with the ve1-standard-72 being universally available. This is based on 2 x Intel Xeon Gold 6240 CPUs (Total 72 cores), 768GiB of RAM, and 19.2TB of Data Storage.

Source: https://cloud.google.com/vmware-engine/docs/concepts-private-cloud

The VMware software stack provided by GCVE includes ESXi, vCenter, vSAN, NSX (software-defined networking), and HCX (for workload migration). These are running the following versions at the time of writing:

Source: https://cloud.google.com/vmware-engine/docs/concepts-vmware-components

To use GCVE, an initial cluster needs to be deployed with a minimum of three nodes and a ‘Failure to Tolerate (FTT)’ of 1, giving a 99.9% availability SLA or ideally five nodes with an FTT of 2, giving 99.99% availability. This is to ensure storage durability for the vSAN configuration.

The minimum 3-node deployment has a ‘usable’ 144 cores, 1.5TiB of RAM, and 38TB of storage. Based on an upfront 3-year commitment, this comes at a cost of about ~$ $150,000/yr. This does tend to mean that Google Compute Engine is often cheaper for small environments of less than ~100 VMs, which I will go into more detail about shortly.

So, beyond familiarity, why should you consider GCVE?

• Faster migrations — Using HCX or NSX-T
• Simpler hybrid model with spanned NSX-T layer bridge.
• Potential VMware license portability.
• Support for more ‘legacy’ guest operating systems than GCE.
• Support for 3rd party VMware integrations such as Veeam, Zerto, and others.

Go ‘Native’ with Google Compute Engine

Source: http://www.quickmeme.com/img/22/22096014c151e2e3149d44c192d72b2c6ca121a47676807aef1ff5a72fc6ad4a.jpg

But what if you want to move completely away from VMware or have an environment where the smallest cluster would still be too big?

Well, Google’s ‘native’ Compute Engine (GCE) offering may be the better choice. In this service, you completely extract away any responsibility for the underlying hardware and virtualisation stack so all you have to do is focus on running your VMs. These VMs can come in different types, sizes, and hardware configurations. There is also the possibility of NVIDIA accelerators for workloads that benefit from such hardware.

With their Migrate to Virtual Machines tool, Google has made migrating from VMware to GCE as straightforward as possible, with the functionality built right into the GCP console. A migration connector needs to be installed in the VMware environment with the required port 443 open towards Google.

Source: https://cloud.google.com/migrate/virtual-machines/docs/5.0

You can migrate VMs or disks; the choice is yours. In either case, the process is much the same. The source VM/disk is replicated in the background, and data is synced continuously and incrementally before initiating a cutover. Optionally, before cutting over, you can even create a test clone of the replicated source VM/disk and test it in the cloud without interruption to the workload at the source. When cutover, the source machine is powered down, and the GCE VM is started.

So why should you consider GCE?

• Cloud ‘Native’ experience
• Abstraction away from underlying virtualisation stack, ‘just a VM.’
• More VM machine types, sizes, and hardware configurations.
• Native VM Manager tooling

So what next?

In this post, I have highlighted the two most common migration targets for VMware workloads in Google Cloud. We would love to help you determine what’s best for your workloads and organisation so please get in touch.

Until next time, keep it Googley, perhaps with a little VMware sprinkled on top :)