I was genuinely interested in VMware’s announced plans to integrate Kubernetes into its stack, but I’m puzzled by the approach so far.
The theory is sound: add container orchestration as a thing VMware can do so enterprises can manage VMs and containers with the same tools they already use. Fine.
But the way it’s being done looks… well, fiendishly complex to actually use, which is the opposite of what the goal should be.
Kubernetes is good and useful, but easy to use it is not. It is famous for being complex to set up and to manage on an ongoing basis. But if you’re going to be running containers at any kind of scale, you need something and Kubernetes is the de facto standard for container orchestration. The promise of getting this container management goodness with all the tools you already know and tolerate (no one loves these tools, marketers) is pretty compelling.
One of VMware’s greatest strengths is that enterprises everywhere already know how to use it. The switching cost of moving away from the VMware ecosystem is substantial, and the more heavily you’ve invested in the toolset, the bigger the perceived cost.
This isn’t sunk-cost fallacy, by the way. It’s that you know how much it cost—in both time and money—to get your company to embrace and use VMs instead of bare metal servers. For those too young to remember, this was a long and arduous battle. Many software vendors refused to support their applications if they were run in virtual machines, afraid they might not work properly.
Yet the way VMware is including Kubernetes functionality seems to be replicating the complexity of Kubernetes itself, rather than making it simpler. VMware Tanzu Kubernetes Grid Plus is a real product name that someone allowed to exist.
Tanzu Kubernetes Grid (TKG) has Personas depending on what you want to use Kubernetes for: If you want to be close to the Kubernetes, you can deploy TKG on any infrastructure you like. If you want to have a vSphere experience, you need vSphere 7 with Kubernetes, which has TKG built in and is integrated with the VMware Cloud Foundation suite of software that you’re probably already used to using. Then there’s Tanzu Mission Control which is an as-a-Service implementation if you just want to use Kubernetes, but it runs in AWS and only deploys to AWS infrastructure.
You can apparently use Tanzu to manage multiple Kubernetes clusters in different locations, but it looks like this:
Personally I think that complexity is, at least partly, a result of what VMware is trying to do here: combining the mature, but still evolving, enterprise technology ecosystem that is VMware with the new and rapidly changing ecosystem of Kubernetes. That is inherently complex. It’s not helped by the fact that mature enterprise technologies have bits that cater to the whims of every enterprise corner case they could afford to bribe the vendor to support. It’s further hampered by the exploration of every kooky idea dreamt up by the fast-fast-fail-often brigade that makes up a lot of the Kubernetes ecosystem.
This is just the exploration phase of an early-stage product and the simplification will come as VMware and its customers figure out what they actually need and what are just nice-to-have features that can be hidden somewhere behind Advanced Masochist Mode.
For now, you’d have to be pretty bold to be playing with VMware’s Kubernetes bits, or have a compelling need you can’t meet with something else. The products still seem to have a lot of confusing terminology, complex architecture, and sharp edges for the unwary to catch themselves on. It’s worth keeping an eye on, because the promise is good, but the delivery on that promise remains elusive.