The squeezing commences
When Broadcom closed their acquisition of VMWare it was clear what would be coming next: Bad times for customers and partners as the acquirer has to return the colossal sum of USD 69B, promising its stakeholders hefty returns on their investment; VMware products have always been designed for lock-in first, boxing in a whopping 300,000 unique customer organizations globally. Especially bad if you are one of the 299,400 customers that Broadcom has officially announced it doesn’t care about because it wants to focus on the top 600.
Few know that for most cases there is a quite straightforward approach to break this dependency. The key here is to build an exit ramp that standardizes the compute layer on Kubernetes and introduce an abstraction layer on top. You then let a Platform Orchestrator enforce highly standardized, portable configurations. The result is a modular Internal Developer Platform that combines superior user experience, high productivity and low lock-in.
As Broadcom is maneuvering itself into the corner we (Humanitec) are partnering with Thoughtworks and Bechtle Competence Center AVS for a joint, scalable and cost-effective response offering a path out of the dilemma.
As the leaders in platform engineering and the company behind the most advanced platform orchestrator on the market we are uniquely positioned to free you from the Goliath. Thoughtworks and Bechtle Competence Center AVS are - in our opinion - the best in the world when it comes to platform engineering.
In this blog post, we’ll shed light on the situation and explain how we’re approaching the rescue missions. If you want to talk with us about your situation, book a demo with a platform architect.
A fairy-tale that’s never been one is crashing hard
In the last 5 days alone, customers with a combined VMware contract value north of 300M USD have reached out to Humanitec and our implementation partners. All major Broadcom customers we are aware of, are formulating strategy papers on how to respond to their CIOs.
We’ve also observed a considerable uptake in mentions on this topic across the globe. Some commenters on Reddit reported price increases in the range of 600%-1,000% of their former contract value.
Any CIO that’s not taking stock of what they have and mentally considering alternatives and monitoring what else is out there is probably not doing their job.
Those requests were driven primarily by three key concerns customers have with the current situation VMWare is in:
- Broadcom's post-merger strategy seems to be based on pressing as much license revenue as possible out of existing contracts exploiting the lock-in effect customers are facing. This makes it appealing to separate the virtualization from the software and orchestration layer above.
- While their virtualization offering is state of the art we’ve received significant complaints about the maturity of the Tanzu Application Platform (TAP). It’s neither fit for production nor does it yield consistent productivity gains for both operations and development teams.
- No clear migration strategy from Tanzu Application Service (TAS) to TAP (which on top is practically not production ready) and in general to the public cloud.
How you’re affected depends on your tech stack
How severely you are affected by this depends on what VMware technologies you are using as well as how deep your integration strategy is or historically was. We’re roughly differentiating three cases:
- Case 1: You are using Tanzu as the K8s dial tone. Tanzu Kubernetes Grid (TKG) might run on VMware or any cloud provider.
- Case 2: You are using TAS, the former Pivotal Cloud Foundry (PCF ). You are running on VMware or any cloud provider.
- Case 3: You are using TAP and you are deeply integrated with all special capabilities that VMware has built into it like Mission Control or Wavefront.
Your exposure and vulnerability to license cost change is increasing with your degree of lock-in. Which is highest in the third and lowest in the first case. Depending on your negotiation strength you will likely see drastic price increases, a drop in product development and support across all product lines.
Case 1 has a fast and low effort migration path and can be transformed into a modular Internal Developer Platform in a short period of time. This even includes the transition to a different virtual environment.
For Case 2 the situation is slightly more complex but still doable. You would replace the build packs of TAS with cloud native build packs and orchestrate them with a Platform Orchestrator.
For Case 3 it’s possible to do but needs a more profound strategy. The additional complexity stems from the integration of your processes with fleet management, operations tooling and observability.
Replacing Tanzu Mission Control and Wavefront is largely dependent on your choice of Kubernetes distribution. More complete distributions e.g. RedHat Openshift might introduce their own tooling for those capabilities, providing clarity on the migration path. Our service partners can help you evaluate different distributions and achieve a complete migration to your distribution of choice.
We discuss those cases, your risk and your migration and mitigation options in this whitepaper.
Our technical approach
Our technical approach differs depending on what VMware products you use. For Case 1 and 2 there is a relatively easy technical fix for replacing the Tanzu layer. Case 3 requires more work in refactoring, standardizing on K8s and disentangling. There’s no easy technical fix but a lift and shift endeavour.
In general the technical approach we are recommending is comparably simple and well tested: we’re introducing an abstraction layer that contains the general relationship between workloads and dependencies. We are then isolating the virtualization layer from this abstraction. A Platform Orchestrator is now dynamically generating the app- and infrastructure configurations per deployment.
This approach called Dynamic Configuration Management (DCM) allows you to swap the underlying virtualization layer any time. Developers are moved a layer up and do not care about the underlying system. This way you can run on Red Hat or AWS in development and staging environments and keep your VM estate only for production until you are ready to completely move off.
Note that this requires the workloads to be compatible to run on Kubernetes. Which means in Case 3 lift and shift effort is required. It leads to significant productivity gains for both developers and operations and is a step function more secure.
Platform Orchestrators help you combine state of the art tools into modular Internal Developer Platforms such as the example below:
You can find more case-studies on this here.
How we’re helping you
Our technologies are well-rounded answers to both concerns. Developer platforms built with our orchestration are both technologically more advanced, modular and low in vendor lock-in. Our reference architectures are pre-packaged versions of integrated toolchains and can act as a fast starting point to get your strategy off the ground in days.
We are collaborating closely with Thoughtworks. We consider them the perfect partner to build modular Internal Developer Platforms across any cloud platform. Their experience with both the VMware stack and Humanitec’s products makes them your perfect implementation partner on this journey.
For European government entities as well as selected high-security cases we are partnering with Bechtle Competence Center AVS. They are utilising our technologies already in their internal platforms and have extensive experience implementing them on the ground.
If you’re interested in a free 60-minute exploratory session with one of our Platform Architects, schedule a call and learn how to escape the VMware grip. Depending on your case we’ll involve Thoughtworks and Bechtle Competence Center AVS, as needed.
Humanitec, Thoughtworks, and Bechtle Competence Center AVS are committed to serving you on this journey.