This article is based on an interview originally published by DQ India with Joe Beda, co-founder of Kubernetes and then-principal engineer at VMware, conducted around the time of the Project Pacific announcement in 2019.
Background: Why VMware Bet on Kubernetes
VMware’s 2018 acquisition of Heptio — the company co-founded by Kubernetes creators Joe Beda and Craig McLuckie — signalled a clear strategic direction: embed Kubernetes natively into the vSphere platform rather than treat it as a bolt-on add-on. A year later, VMware announced Project Pacific, described internally as the most significant evolution of vSphere in a decade.
The driving logic is straightforward. Enterprises are not abandoning their existing VM-based workloads overnight, but they also need a path to modern, container-based application delivery. VMware’s answer was to make Kubernetes a first-class citizen inside vSphere itself, letting both VM and container workloads coexist on the same platform with shared management tooling.
What Project Pacific Actually Does
According to Joe Beda, Project Pacific operates on two levels simultaneously:
- Kubernetes as an infrastructure primitive: Kubernetes is embedded into vSphere not just to run container workloads, but as a foundational technology for building and managing vSphere itself. This means even customers who have no interest in containers benefit from the underlying Kubernetes-driven architecture through improved APIs and future feature enablement.
- Kubernetes as a workload platform: For customers who do want to run containerised applications, vSphere provides a first-class Kubernetes experience. Cluster management, scaling, and infrastructure operations are unified with existing VM management workflows.
A key output of this work is a unified API and toolset that lets operators manage both containers and VMs through the same interface, eliminating the operational split that has traditionally forced teams to maintain separate skill sets and toolchains.
vSphere Native Pods: Blurring the Container/VM Boundary
One of the more technically interesting elements of Project Pacific is the concept of vSphere Native Pods. Traditional approaches to running containers in enterprise environments involve spinning up a VM, installing a container runtime, and running containers inside that VM. This preserves VM-level security isolation but introduces OS overhead for every VM.
vSphere Native Pods, built directly into ESXi, aim to eliminate that overhead by hyper-optimising the virtualisation layer specifically for container workloads. The result is an architecture that offers the security and isolation guarantees of VMs with performance characteristics closer to running containers on bare metal.
“We are looking at how to hyper-optimise that VM to reduce that OS overhead and provide the best of both worlds in terms of security, all of VMware’s deep experience around getting the best performance out of VMs, and bring that into the container world.”
— Joe Beda, co-founder of Kubernetes, VMware
Beda cited early internal benchmarks claiming that vSphere Native Pods running on Project Pacific could outperform Kubernetes on traditional VMs by up to 30%, and even outperform bare-metal Kubernetes deployments by up to 8%. These figures were presented as early engineering results, not published benchmarks, and should be treated accordingly until independently verified.
Containers vs. VMs: Complementary, Not Competing
A common framing in the industry has been that containers and VMs are in competition — containers offering lower overhead and faster startup, VMs offering stronger isolation and broader OS compatibility. Beda pushes back on this framing directly.
At a technical level, containers and VMs are complementary. Containers benefit from the hardware optimisations, memory management, and security hardening that VMware has spent years building into ESXi. At the same time, Kubernetes provides the orchestration and workflow layer that helps application teams ship software faster without creating bottlenecks on the operations side.
The practical implication for enterprises is that they do not need to choose between modernising their applications and protecting their existing infrastructure investment. VMs and containers can share the same resource pool, and workloads can migrate between the two models as application requirements evolve.
Key Use Cases Identified
Enterprise Application Modernisation
Many enterprise applications are currently locked inside VMs. The path to modernisation — refactoring or rewriting them as containerised microservices — has historically required a parallel infrastructure build-out. Project Pacific removes that requirement by letting both models operate on the same underlying platform, giving teams the flexibility to modernise incrementally.
Telecommunications and 5G
Telcos building out 5G networks need platforms that can support both consumer-facing applications and network function virtualisation (NFV) workloads. Kubernetes provides the consistent orchestration layer that makes it practical to run these workloads across highly distributed infrastructure, a natural fit for the 5G architecture model.
Edge Computing
Latency requirements, data sovereignty regulations such as GDPR, and IoT data volumes are all pushing workloads away from centralised cloud infrastructure and toward the edge. Kubernetes offers a consistent operational model across cloud, on-premises data centres, and edge locations, making it well suited to the heterogeneous infrastructure that edge computing demands.
What This Means for Existing vSphere and VMware PKS Customers
At the time of the interview, VMware had not published specific upgrade or migration paths for existing vSphere or PKS (Pivotal Container Service, now Tanzu Kubernetes Grid) customers. Beda acknowledged this directly, noting that the engineering work was still in progress and that specific product timelines had not been announced.
What VMware did commit to was protecting the investments of existing customers. Organisations that had already adopted VMware PKS or standard vSphere were assured that VMware would provide the smoothest possible transition path as Project Pacific moved from technology preview to product.
Partner and ISV Ecosystem Implications
Embedding Kubernetes into vSphere changes the conversation VMware can have with customers. Historically, VMware’s primary audience inside enterprises was infrastructure and operations teams. Project Pacific expands that audience to include application developers, DevOps teams, and platform engineers — all of whom interact with Kubernetes as part of their daily workflow.
This broader reach also opens new opportunities for VMware’s partner network. ISVs building on top of vSphere can now target the same platform for both VM-based and container-based offerings, rather than maintaining separate integrations for each model.
On the question of competitive dynamics — specifically around Red Hat OpenShift, which is also a Kubernetes distribution targeting enterprise customers — Beda noted that co-opetition is standard in the infrastructure industry. VMware running on HPE hardware while competing with HPE in other areas, or Dell owning VMware while VMware supports multi-vendor environments, are examples of the same dynamic.
The Bigger Picture: Democratising Kubernetes for the Enterprise
Despite Kubernetes’ maturity as a project, adoption in traditional enterprises has lagged behind its profile in the cloud-native community. The operational complexity of standing up and maintaining Kubernetes clusters has been a genuine barrier, particularly for organisations without dedicated platform engineering teams.
VMware’s thesis with Project Pacific is that embedding Kubernetes into vSphere — a platform that enterprise infrastructure teams already know how to operate — removes the primary adoption barrier. Organisations do not need to build Kubernetes expertise from scratch; they can extend their existing vSphere knowledge and tooling to cover container workloads.
Combined with VMware’s 2019 acquisition of Pivotal (which brought Cloud Foundry and application development tooling into the VMware portfolio), the ambition is to cover the full application lifecycle: from infrastructure provisioning through to developer workflow and application delivery.
Project Pacific was subsequently released as part of vSphere 7.0 in 2020, branded under the VMware Tanzu portfolio. Readers researching current VMware Tanzu or vSphere with Tanzu capabilities should consult current VMware documentation, as the product has evolved significantly since this interview was conducted.