I wrote this a while ago, and since then, I have learned a great deal more about what makes AHV special. And although I talk about the database here, it’s not just about the database; it’s also about the kind of OS and the availability models of that system.
Photo by Jonny Gios on Unsplash
One of the more enduring mysteries about x86 virtualization is how profoundly misunderstood it is by those who are distant from it, considering its widespread use.
For folks with a passing understanding, they assume that something intercepts every instruction between the actual processor and the workload and translates it on the fly.
Except that’s not been the case from more or less the beginning.
What VMware and most other vendors did was virtualize a processor’s control instructions, not the workload instructions.
A processor has a set of instructions and capabilities for running workloads and a set of capabilities and instructions for managing the hardware.
The OS-processor interface is peculiar and continuously evolving. By its very nature, it was initially engineered to assume that only one OS ever interacted with it.
VMware virtualized that OS-Processor interface, enabling multiple different OSs to run on the same x86 hardware.
Once the processor’s control plane was virtualized, it became possible to build an OS (ESXi) that treated VMs as first-class abstractions.
ESXi enabled far more sophisticated control and sharing of the physical resources. It could do that because the control plane was virtualized, and when it needed to interfere with the running guest, it was able to.
Nowadays, every OS does the same thing—it virtualizes the OS-processor interface and, using that abstraction, can run multiple VMs on a single processor.
Unfortunately, we take this for granted because it is an astonishing technical result, and we are too impressed with it.
And given that every OS on the planet, including many free ones, and that customers wanted to run mixed workloads and they chose to use an inferior form of virtualization, the cognitive dissonance between I like bare metal and virtualization isn’t good enough, hurt my head.
So I dug into it.
They are saying that a modern application’s control plane is a distributed system. They want a distributed infrastructure control plane on which multiple applications can rely. Virtualization does provide a mechanism for sharing a server, but that’s not useful without a distributed infrastructure control plane that applications can share.
The industry-leading virtualization does not have a clustered control plane. So, customers naturally look towards bare metal Kubernetes (K8s) because it has a distributed database.
And then the same customers use kube-virt to create VMs. The shift to bare metal is thus not about virtualization, but about what control plane virtualization you need. Today’s applications require the infrastructure control plane to be virtualized.
The next generation of infrastructure management will depend on vendors who figure out how to virtualize the interface from the K8s API server to the underlying infrastructure itself.
To achieve this, you need a distributed database that is more reliable than etcd. Why? Because etcd is what you don’t have to pay for.
Fortunately, Nutanix has one of those.
Leave a Reply