Most enterprise infrastructure teams operate three independent control planes. The storage system has its own API and its own management console. The hypervisor has another API and another console. The Kubernetes orchestrator has a third. Each was designed by a different vendor at a different time to solve a different problem. The integration between them is the operations team’s full-time job.
The question worth asking is what changes when those three APIs collapse into one.
The Three-API Reality
The current architecture is well understood. A storage admin provisions a LUN or a share. A virtualization admin attaches it to a host. An application owner asks the Kubernetes team for a persistent volume. The Kubernetes team writes a StorageClass that points at a CSI driver. The CSI driver makes another round trip back to the storage array. The volume eventually materializes inside the cluster.
Every step is documented. Every step is automatable. None of the steps remove the fact that three separate systems coordinated to make one application work.
When something breaks, the failure domain is fuzzy. A snapshot fails because the storage array ran out of free space. The CSI driver returns a generic error. The Kubernetes pod restarts and fails to remount. The platform team opens a ticket with the storage team. The storage team opens a ticket with the array vendor. The array vendor asks for the CSI driver version. The CSI driver vendor asks for the cluster version. The application owner waits.
What Changes With One API
When the storage system, the hypervisor, and the Kubernetes orchestrator share an API and a control plane, the work flow looks different.
Provisioning collapses. The same API call that creates a virtual machine creates a persistent volume. The same policy that protects a VM protects a containerized database. There is no CSI driver translating between two systems. There are no longer two systems.
Snapshots become a primitive. Today, a Kubernetes VolumeSnapshot triggers a CSI snapshot, which triggers a storage system snapshot, with different semantics depending on the array. With one API, a snapshot is a snapshot. The same policy engine that runs hourly snapshots against a VM runs them against a Kubernetes namespace.
Replication and DR follow the same pattern. The platform handles the data motion, not three vendor products coordinating through fragile glue.
The Failure Domain Collapses
The most overlooked benefit of a shared API is what happens to the failure domain.
In the three-API world, a single workload depends on the availability of three independent systems. The Kubernetes control plane has to be healthy. The hypervisor has to be healthy. The storage system has to be healthy. Each one has its own update cycle, its own patch schedule, its own maintenance windows. A failure in any one of them is a failure for the workload.
With one API and one control plane, the failure domain is one system. The team responsible for it knows the failure mode. The runbook is one document, not three. The integration testing is the platform vendor’s problem, not the customer’s.
What This Means for Migration
The most interesting consequence of a shared API is what it does to a migration project.
The classic Kubernetes migration story splits an estate into two camps. The workloads that can be containerized move to a bare-metal Kubernetes cluster on day one. The workloads that cannot move stay on the legacy hypervisor and slowly age out. Two infrastructure stacks have to run in parallel for months or years.
A shared API makes that motion optional. A VM can migrate as a VM on day one. The application team can containerize it on its own timeline. Both forms run on the same platform, with the same storage, snapshot, and DR policies. The migration becomes a series of small choices, not a single multi-year program.
The Architectural Stake
The pitch for a shared API is not that it is more elegant. The pitch is that the three-API model has a cost the industry has spent twenty years absorbing as a normal operating expense. License costs scale with each layer. Team headcount scales with each interface. Failure recovery time scales with the number of vendors involved in a single outage.
VergeOS is the platform that took the question seriously. It runs storage, virtualization, and Kubernetes from a single code base with a single API. Persistent volumes for Kubernetes provision from the same pool that serves the VMs. Snapshots are native to the platform, not CSI-translated. Replication and DR are platform services. The three control planes are one control plane.
The Question Storage and Platform Architects Should Ask
The technology to collapse the three APIs has existed for several years. The question for the architect is whether the savings justify a platform change.
The math is concrete. A single license replaces the storage license, the hypervisor license, and the Kubernetes management license. A single team operates the platform that the storage team, the virtualization team, and the platform team operated separately. A single vendor is accountable when something goes wrong. VergeIO published the dollar-and-cents breakdown of this exit math in a recent piece called The Kubernetes VMware Exit Math, Explained, with the licensing and headcount numbers worked out against a typical 500-VM environment.
For an organization staring at a 3-4x VMware renewal, the question is not whether one API is more elegant than three. The question is whether the three-API tax is worth paying for another five years.
VergeIO is running a 30-minute live demo of this architecture on Wednesday, May 20 at 1 PM ET: Kubernetes Without the VMware Tax.
