When we wrote about Docker 1.0 the distinction that mattered was between packaging and isolation: the industry had adopted a boundary weaker than the virtual machine it replaced, because the ergonomics were better, and the isolation question was left for later. For years the trade was treated as a law of nature. You could have fast, dense and weak, or slow, heavy and strong.
2018 produced three projects that refused the trade, and each one is a different bet about where the boundary should live.
Three bets¶
Kata Containers, which grew out of Intel's Clear Containers work, puts a conventional virtual machine underneath the standard container runtime interface. The orchestrator sees a container; the host sees a VM with its own guest kernel. Compatibility is what it buys, and the cost is carrying a full machine per pod.
gVisor, open-sourced by Google in May 2018, makes the opposite bet: no second kernel. A user-space process re-implements the Linux system call interface and the workload talks to that re-implementation instead of the host. The boundary is strong in the sense that workload system calls never reach the host kernel directly. The re-implementation itself still talks to the host, though, through a narrowed, filtered interface, and the whole arrangement is as trustworthy as that re-implementation is correct. Syscall-heavy workloads pay the interception cost on every call.
Firecracker, which AWS open-sourced in November 2018, keeps the hypervisor boundary and deletes the machine. KVM stays. What goes is everything a cloud guest never uses: no BIOS, no PCI enumeration, no video, no USB. The device model is virtio network, virtio block, a serial console and a one-button keyboard controller whose only job is to signal reset.
The numbers are the argument¶
The paper AWS published at NSDI last month puts figures on it, and the launch announcement carries the same claims: a microVM boots to init in around 125 milliseconds, costs under 5 MiB of overhead beyond the workload itself, and a single host can start them at a rate of 150 per second. The virtual machine monitor is roughly fifty thousand lines of Rust. QEMU, the device model most production VMs sit on, is well over a million lines of C, and it emulates decades of hardware that no cloud workload will ever touch.
That last comparison is the security argument, and it is older than Firecracker. VENOM, in 2015, was an escape through QEMU's virtual floppy disc controller, a device present and reachable in guests that had never mounted a floppy in their lives. A device model with four devices has no floppy controller to be wrong in. Shrinking the device model removes whole classes of escape path before anyone audits a line.
The language choice carries a related claim: the component that parses guest-controlled data sits on the host side of the trust boundary, and Firecracker's authors chose to write it in a memory-safe language. Whether that choice becomes the norm for new hypervisor work is one of the things the shared rust-vmm crates, which Firecracker and others now build from, will settle in practice.
Why this matters now¶
Two years ago the floor moved. Meltdown showed the user/kernel boundary failing outright, and the Spectre family made every boundary that shares a core suspect, virtual machines included. What changed was the arithmetic of defence in depth: fewer tenants per kernel and a smaller interface between tenant and host, at the exact moment multi-tenant density made the shared kernel most valuable. A hardware-backed boundary per tenant stopped looking like caution and started looking like the conservative default. Firecracker is what that default looks like when someone re-derives it from requirements instead of inheriting it from 2007. The paper is explicit that Firecracker exists to run other people's code, at density, on shared hosts, and that the Lambda and Fargate fleets run on it in production.
Our view, stated as a view: the interesting consequence is for the orchestration layer. Schedulers still think in containers because virtual machines were too slow and too heavy to be the per-workload unit. A microVM still carries a guest kernel, so it will never be as cheap as a namespace. But at 125 milliseconds and single-digit MiB of monitor overhead, the blanket objection no longer holds. If the microVM becomes the unit the control plane allocates, the container quietly becomes what it always was underneath: a packaging format.