VMware Tanzu and Project Pacific: 3 Considerations for Enterprises Adopting Kubernetes
At VMworld 2019, VMware shared two major announcements: VMware Tanzu Mission Control, which provides multi-cluster management across distributed Kubernetes clusters and Project Pacific, which ties Kubernetes more closely within vSphere. These are significant announcements in the first VMworld following VMware’s acquisition of Heptio a year ago and the recent news of its intent to purchase Pivotal. Read on for insights on these announcements to consider in your cloud-native strategy.
Cloud control plane: Ideal architecture for managing Kubernetes, but where’s the SLA and compatibility matrix?
Every enterprise adopting containers and cloud technologies knows there is truth in Craig McLuckie’s assertion that the cloud is increasing fragmentation in environments; not simply consolidating the environments, as was presumed earlier. To address this, VMware Tanzu will feature a cloud (SaaS) control plane that will securely integrate with distributed Kubernetes clusters through an agent and support common management operations.
This is validation that the SaaS control plane architecture that we pioneered at Platform9 and have been offering commercially for our Managed Kubernetes solution since 2017 – is the right architecture for enterprise adoption of Kubernetes. The majority of our enterprise customers today need to manage at least 2 major environments – that can run on-prem or in the cloud – and nearly 50% of our customers operate 3 or more environments, across different datacenters/clouds. This environment sprawl and its resulting operational costs and management complexity can only be solved by a central cloud control plane that can abstract away the differences amongst these environments and make it easy to standardize and scale operations across infrastructure.
That said, important specifics around VMware’s cloud control plane were hard to find. What is the SLA for the Kubernetes clusters managed by Tanzu? What are the compatible environments across on-premises and public-clouds that Tanzu can manage? Will Tanzu support multiple versions of Kubernetes to co-exist in an environment while new versions of Kubernetes are being rolled out? How many older upstream Kubernetes versions will Tanzu support?
To an Operations team running Kubernetes, these are critical questions for which information is still not available at this time.
Unified management across VMs and containers: Project Pacific
Talent scarcity in enterprise IT/Ops teams, combined with the realization that VMs and containers are going to co-exist for a long time to come, has created a new battleground: an enterprise cloud platform that can manage across VMs and containers effectively.
VMware attempts to provide this single pane in Project Pacific, which embeds a Kubernetes “supervisor cluster” within vSphere. Pacific enables kubectl operations to pods running in VMs or natively on ESXi, alongside VMs management. This means that every vSphere user can now more easily get access to the Kubernetes command line, and use the Kubernetes API to manage both VM and container workloads.
Project Pacific is an attempt to ensure vSphere – VMware’s core virtualization platform – remains relevant as the world increasingly adopts containers and virtualization gradually becomes undifferentiated. While embedding Kubernetes certainly brings something new and fresh to vSphere, it also feels like a project that only helps vSphere catch up with other existing solutions, and doesn’t actually break any new ground. Consider that today, with the open-source KubeVirt project, it is already possible to achieve all the benefits that Pacific claims to enable, including:
- Orchestrate VM workloads using the Kubernetes API, just as you would with VMs
- Managing hybrid applications across VMs and containers, rather than infrastructure-centric management
- Use of Kubernetes toolchain atop existing virtualized environments
So, what does Project Pacific enable that isn’t already possible with any standard Linux / Kubernetes environment? The answer isn’t clear.
Modern application platform: but where are the application platform services?
In the keynote and related blogs, there was a big emphasis on how VMware wants to help enterprises with a modern application platform. And this is indeed a massive unmet need in the enterprise: as enterprises look to adopt the cloud, they love the broad range of cloud services available from each of the large public cloud vendors but struggle with the lack of these same services when they want to run these services on-prem or adopt a hybrid cloud or multi-cloud architecture.
For example, consider an enterprise that loves Google’s excellent Spanner service. This works beautifully when you are in Google Cloud exclusively. But the moment you need to use a hybrid or multi-cloud architecture, this service isn’t available anymore. Same for AWS’s Lambda and many other application services.
Without these platform services, the cloud would be a boring pool of commodity servers that only works out of the box for simple, stateless applications. What enterprises need in order to modernize their applications in today’s hybrid cloud era, is a hybrid cloud platform that:
- Abstracts the differences between on-premises and multiple public cloud environments, and
- Provides the use of critical platform services such as monitoring, SQL databases, no-SQL solutions, and more
VMware is presenting a bold vision for enabling enterprises with a modern application platform, but unlike Red Hat, Platform9 and others in the Kubernetes community, it is missing integrated, end to end support (with an SLA) for critical platform services such Prometheus, Istio, EFK, databases and more. Kubernetes is the kernel of the cloud-native operating system that enables multi-cloud, but without these supporting platform services, that kernel alone isn’t very useful.
A Buyer's Guide to Enterprise Kubernetes Solutions
A Comparison of VMware Tanzu, Google Anthos, Red Hat OpenShift, Rancher, and Platform9 Managed Kubernetes capabilities including:- Provisioning of Kubernetes Clusters
- Monitoring and Operations Management
- Deployment Models Supported
- And more
Closing thoughts: Was all of this truly necessary?
When looking at Project Pacific from a higher ground, one has to ask: did this have to be so complicated? Why bake Kubernetes technology so deep into the vSphere stack? The vSphere and ESXi products are known as a solid solution for running virtual machines. Why not keep that layer as lightweight and secure as possible? Off-the-shelf, open source Kubernetes runs very well on top of IaaS and hypervisors. It was designed that way. It also offers a wide range of integration points to add infrastructure-layer optimizations: CRI for container runtimes, CSI for storage, CNI for networking, … the list goes on. The announced Native Pods feature can be supported via the CRI interface. Projects like Kata Containers and gVisor already do this today. Exposing VMs as first-class Kubernetes objects can easily be done via Custom Resources or by enhancing the KubeVirt project. Taking that approach would be more consistent with the spirit and best practices of the Kubernetes community and ecosystem.
The reason VMware chose the path that they did is anyone’s guess.
VMware seems to be using Kubernetes to further the relevancy of what is still essentially their “walled garden”, rather than actually embracing open-source technologies. While this seems like it would be welcome news for users already wedded to the VMware ecosystem, therein lies the rub. For users looking to modernize and adopt cloud-native technologies like Kubernetes, and its associated ecosystem offerings, this doesn’t really further that goal at all. In fact, it does the opposite – it incorporates the vTax lock-in, and all of its baggage, to what should fundamentally be reducing infrastructure lock-in: cloud native patterns.
It is great to see the continued momentum in the Kubernetes community. It is telling that in just a few short years, open-source Kubernetes has grown so much in importance that VMware, the leader in enterprise IT infrastructure, is devoting the primary keynote of its annual conference to announcements embracing Kubernetes. And by doing so, it is undoubtedly going to bring more traditional enterprise IT organizations to pay attention to Kubernetes, which is a very good thing for the community.
However, looking beyond the marketing hype, it is clear that there is a lot of work ahead for VMware to take these “technical preview” announcements and make them relevant for both existing vSphere customers in the long-term, and for new enterprises looking to modernize with Kubernetes. Meanwhile, enterprises adopting cloud-native technologies would do well to closely inspect the fine print on the capabilities of these announcements, and compare across alternatives such as Platform9 both for feature parity as well as the track record of production operations.
As Chief Growth Officer, Sirish focuses his efforts on growth engineering initiatives that help accelerate time-to-value for our customers.Previously, Sirish was Founding CEO at Platform9 and led the company from its inception through several team, product, revenue and fundraising milestones.
Prior to founding Platform9, Sirish was an early engineer at VMware who went on to technical and management roles. His work at VMware led to several products, features and patents.
Outside Platform9, Sirish follows cricket, makes his kids laugh, and builds his collection of fast lenses and unprocessed photos. His favorite books include the Harry Potter series, Crossing the Chasm, Blue Ocean Strategy and Innovator’s Dilemma
- Edge Computing and 5G Power: Telco and Cloud Convergence - February 26, 2021
- VMware Tanzu and Project Pacific: 3 Considerations for Enterprises Adopting Kubernetes - August 27, 2019
- Modernize: Five Pathways To Level Up Your Apps And Infrastructure - June 20, 2019