Will customers really jump ship when VMware is acquired?

In recent months, we’ve been discussing many aspects of the VMware acquisition by Broadcom since it was first announced in May 2022. As the deal comes closer to completion, will customers really start leaving en masse, or are there many more factors to consider before making the jump?

Background

Broadcom announced its intention to acquire VMware for $61 billion back in May 2022. The current timeline is expected to see the deal close by the end of October 2023, although the initial completion date was much earlier and has moved back several times. The UK regulatory authorities approved the deal in August 2023, while China looks to be the final hurdle, but is not expected to be a problem.

Broadcom is looking to push annual earnings closer to $8.5 billion over three years, compared to the $4.7 billion at the time of the acquisition announcement. This increase needs to come from drastically slashing costs or increasing revenue (which could mean putting up prices).

Ultimately, those two options (saving money or making more money) represent a concern for existing customers. Either innovation will slow down, or the cost of infrastructure for end users will increase, with no additional benefit or justification.

Side Note: a third option is to increase the TAM for VMware products with new product lines and solutions, however the containerisation initiative with Tanzu and the SmartNICs initiative don’t appear to have generated much additional income.

Lock-in

For most VMware customers, the most significant issue driving increased risk for the future is one of lock-in. Since its inception in 1999, VMware truly produced a sea change in the way technology was implemented. From the early initial benefit of workload consolidation (optimising resource utilisation), the features of the VMware ecosystem have been radically expanded to include virtual storage, virtual networking, zero-trust, integrated security, and application lifecycle management.

Figure 1 – Typical Virtual Infrastructure Layers

All of the product solutions and features of the VMware ecosystem create lock-in, as we’ve attempted to show in Figure 1. At the core of any infrastructure is the chipset, typically x86, but it could be Arm in the future (although VMware has indicated this is not a current strategic direction). From ESXi outwards, if we attempt to replace any part of the infrastructure, the entire stack is at risk. VMware tools like vSphere don’t support native KVM or Nutanix AHV (and unlikely ever will). The degree of lock-in gets worse as we move further out, with mission-critical technologies like HA and fault tolerance being fully embedded into the ecosystem at the core layer.

As a side note, Nutanix does provide multi-hypervisor support and used this feature as a selling point to get customers to “avoid the vTax”. VMware and Nutanix also provide APIs which (theoretically) allows third-party platforms to implement basic operations and management tasks. However, the core capabilities of complex features like high availability (HA) are an intrinsic part of the VMware ESXi hypervisor. Change the hypervisor, and you lose that functionality if it doesn’t exist within the replacement.

Build or Buy

I recently spoke to an engineer at a large IT organisation whose job was to replace VMware application management functionality with custom scripting. A decade ago, most large enterprises would have run a mile from home-grown systems management code, but today, DevOps is a thing and definitely for building operational software. So, one route for lock-in avoidance is to build internal tools and processes that remove some of the VMware dependency. This strategy can be hard to achieve without decent tools, full documentation, and internal code lifecycle management. However, those ecosystem features are now ubiquitous in the form of GitHub, Jenkins, Ansible, Terraform, Python libraries and many other solutions.

Writing resilient code, especially for infrastructure management, takes time, so for IT organisations taking that route, in 12 months, nothing much will happen; in 5 years, a total transformation could have been completed.

Side Note: another alternative option is to use a 3rd party solution like Morpheus Data (itself derived from an in-house toolset), or Digital Rebar from RackN, both of which can automate multi-cloud solutions.

Mitigation

The other route to mitigating any post-acquisition blues is to look at alternatives to VMware. Unfortunately, because VMware software is so good (especially the core vSphere features), alternatives tend to be lacking in one way or another.

We’ve run Nutanix in the lab (although not recently), and it’s a capable platform, but the general robustness of the GUI wasn’t as good as VMware (this was running AHV). The Nutanix Compute Platform was designed to eliminate shared storage (the HCI concept), so it doesn’t recommend using external storage arrays. This can be a problem for IT organisations that have invested heavily in shared storage for VMware, initially because of the cost but secondly, the use of array-native features within the VMware platform.

Similar issues exist for verge.io, which doesn’t support or allow external storage at all. Scale Computing also only supports internal storage and is still very much a hardware play, albeit with many configuration options.

Thinking back to the early days of VMware adoption in the enterprise, ESX and vSphere were generally targeted at applications that weren’t mission-critical, such as test and development. Over time, as the platform became more trusted (and more enterprise features were added), VMware moved entirely into the mainstream and is the primary choice for new applications.

Many IT organisations may choose to invest in alternative development paths, trying out some of the alternatives mentioned above. Of course, when making a significant infrastructure change, moving to the public cloud or containerisation are equally valid, so IT organisations may choose to move applications away from on-premises server virtualisation altogether. This is a risk for both VMware and its competition.

Whatever choice is made, significant investment (both time and financial) will be needed to align processes and procedures across disparate sets of virtual infrastructure.

The Architect’s View®

With little visible evidence of what a future VMware might look like, we don’t believe that customers will jump ship on day one. In fact, we can’t see much changing in the first 12 months, including from the VMware side. VMware has introduced “plus” licensing to enable customers to move to a SaaS model, while all the major public clouds now support VMware running on public cloud infrastructure, so there’s choice for the customer on how and where to consume VMware products.

We believe that savvy customers will look at mitigation options and create strategies for testing the waters with non-VMware platforms. Based on the success or failure of those trials, including the direction Broadcom chooses to take, then we’ll see some change in the relative distribution of server virtualisation revenue. In our experience, 20% of customers will never move, 20% of customers will move if the conditions are no longer favourable, while 60% will be undecided in the first instance. Much of this decision making will not be technical, but focused on costs and the simplicity of operations.

Rest assured, we’ll be monitoring the market and the competition to see how things proceed.