We have both spent our careers in virtualisation. Between us, that is more than thirty-five years of designing, deploying, and operating vSphere platforms for organisations large and small across Australia, APAC, the UK, and the US.
We loved the platform. We built our careers on it. And we watched, with growing concern, as it was hollowed out, first by aggressive licensing, then by an acquisition that priced its long-term customers out of the product.
So we built Netframe.
This piece walks through the technical decisions behind the platform.
Why KVM. KVM is the hypervisor underneath much of the public cloud. It is mature, performant, well-understood, and, critically, not subject to vendor whim. Choosing KVM gave us a strong foundation and let us put our engineering effort into management, operations, and the parts of the stack our customers actually interact with.
Why Debian. A hypervisor is at heart a Linux distribution with a particular workload profile. Debian gives us stability, a long support window, predictable upgrade paths, and a large ecosystem of operational tools. It is the same choice that powers a substantial proportion of production Linux estates worldwide.
Why a custom management plane. This is where we put most of our work. The Netframe management plane is purpose-built for clustered virtualisation at scale. It handles HA, live migration, RBAC, audit, network and storage abstraction, and the operational primitives that VMware vSphere users expect. We rejected several off-the-shelf options because none gave us the operational ergonomics we wanted.
Why no per-VM fees. Per-VM fees are a tax on growth. They punish customers for using the platform. Per-core licensing matches what our customers actually buy, physical hardware, and gives them honest, predictable cost.
What we learned from VMware. A lot, honestly. We took the operational concepts that work, clusters, distributed switches, vMotion-style live migration, role-based access, and reimplemented them with cleaner primitives. We left behind the parts that did not age well: the licensing model, the agent sprawl, and the long-tail of legacy assumptions.
There is much more to say on each of these, and we will. This is the first in a series of engineering-focused posts.