Cloud paper route: Firecracker and cluster management

Why it matters

Research interviews in cloud computing expect you to discuss papers the way authors and reviewers do: what problem, which mechanism, what evidence, what is argued versus measured, and what remains open. This route anchors on Firecracker, which is short, concrete and full of explicit trade-offs, and places it beside cluster management (Borg) and a production workload study (Serverless in the Wild), so that isolation, scheduling and elasticity connect.

Core ideas

Reading order.

1. Firecracker (NSDI 2020): why AWS Lambda needed VM-grade isolation with container-like density and startup, how a minimal KVM-based VMM provides it, and how Lambda uses it.
2. Borg (EuroSys 2015): how a large cluster manager admits, places, preempts and isolates work, and how it evaluates packing policies.
3. Serverless in the Wild (USENIX ATC 2020): what a production FaaS workload looks like and how a per-application policy trades cold starts against memory.

Optional context: DRF for multi-resource fairness, Heracles for interference-aware co-location, and the OSTEP appendix on virtual machine monitors as background for Firecracker.

What to extract from Firecracker. The six requirements the authors set (isolation, overhead and density, performance, compatibility, fast switching, soft allocation); why containers force a choice between syscall filtering and compatibility, and why language-level isolation could not run arbitrary binaries; the design choices (KVM, a small Rust VMM, a minimal virtio device set, block devices instead of filesystem passthrough, a REST API, token-bucket rate limiters, one VMM process per microVM inside a jailer); how Lambda uses microVMs as slots with a pool of pre-booted VMs; and the argument that oversubscription is a statistical bet that holds only for uncorrelated workloads.

Argued versus measured. Isolation is argued qualitatively: a smaller trusted computing base, a hardware virtualization boundary, defense in depth, and deployment guidance on side channels. Boot time, memory overhead and I/O are measured on one bare-metal host against QEMU and Cloud Hypervisor. Statements about Lambda in production are reported experience, not controlled experiments. Keep the three kinds of claims apart in your notes.

Connections. Firecracker relies on Linux for scheduling and memory management, so noisy-neighbor problems move rather than disappear (interference topic). Borg's reclamation and overcommit are the cluster-level counterpart of Firecracker's soft allocation (scheduling topic). Serverless in the Wild explains why fast switching matters economically (elasticity topic).

Common misconceptions

• "Firecracker shows VMs beat containers in general." It argues for one set of constraints (untrusted multi-tenant code, arbitrary Linux binaries, high density) and accepts trade-offs: a limited device model, no VM migration, and block I/O below QEMU in its own evaluation.
• "The evaluation measures isolation." It measures boot time, memory overhead and I/O; isolation rests on design arguments.
• "Borg's utilization gains transfer to any cluster." They depend on Google's mix of production and batch work, its constraints and reclamation, and were measured by compaction in simulation from production checkpoints.
• "Serverless in the Wild recommends a longer keep-alive." It shows that one fixed window fits a skewed workload badly and that adapting per application improves the trade-off.
• "The abstract and evaluation are enough." Assumptions in the design sections (Linux guests, small functions, the threat model) bound every claim.

How to approach it

Read each paper in three passes with its paper guide, fill in the structured notes, and prepare a two-minute and a ten-minute explanation of Firecracker. For each paper, write one follow-up experiment you could actually run, such as measuring microVM boot-time distributions on your own host or replaying the Functions trace against another keep-alive policy.