Here's something the container ecosystem doesn't say loudly enough: runc is not the only option, and for a growing number of production workloads, it's the wrong one.
AWS Lambda doesn't run your function in a Docker container. It runs it in a Firecracker microVM. Fly.io's Machines? Firecracker fork. Google's multi-tenant GKE nodes? gVisor. Cloudflare Workers? WASM. These companies didn't reach for exotic runtimes because they were bored — they reached for them because the default isolation model was insufficient for their threat model, their latency requirements, or both.
This article takes one tiny Go HTTP server and runs it through all five of them: runc/distroless, gVisor, Kata + QEMU, Kata + Firecracker, and WASM/WASI. You'll see exactly what changes (almost nothing), what the real numbers look like, and — most importantly — which runtime belongs in which situation.
TL;DR: gVisor, Kata, and Firecracker all run the exact same 3 MB OCI image — only --runtime=X changes. WASM is a different compilation target entirely. Cold-start ranges from ~20 ms (runc) to ~500 ms (Kata/QEMU), with Firecracker splitting the difference at ~125 ms. Request latency overhead at steady state is shockingly small across all of them. The real cost is memory and compatibility, not throughput.
