A single control plane for a million machines
Meta’s homegrown cluster manager, Twine, has been in production for a decade. Unlike common alternatives such as Kubernetes, which bind workloads to statically assigned clusters, Twine does away with the cluster concept entirely. A single control plane manages up to one million machines across all data centers in a geographic region, letting workloads migrate freely between data centers without manual intervention.
This design is a deliberate departure from how most large organizations run shared infrastructure. While partial consolidation is common, full consolidation—where any machine can run any workload—is rare. Twine achieves it through several decisions: natively sharding and scaling every component to avoid central bottlenecks (no federation layer required), supporting workload-specific customization on shared hardware, and collaborating with applications on life cycle events rather than imposing them.
One notable hardware strategy is the shift toward small, power-efficient machines as a universal computing platform. The fleet is converging on a single compute machine type with one CPU and 64 GB RAM, eliminating the usual menu of high-memory and high-CPU variants. This move has yielded an 18 percent savings in power and a 17 percent reduction in total cost of ownership.
Scaling without clusters
Traditional cluster management systems statically assign machines to clusters, and workloads are bound to those clusters. The result is stranded capacity and extra operational overhead, since migrating workloads across clusters is difficult. Twine's regional control plane sidesteps this by treating all machines in a region as one pool. Every component is sharded and scaled independently so that no single piece becomes a bottleneck as the fleet grows to millions of machines.
Applications get a say in their own lifecycle
Cluster managers typically restart or update applications without consulting them, which can break availability guarantees. Twine's TaskControl API gives applications a way to collaborate with the control plane on container life cycle events. An application's TaskController can, for example, dictate the order and timing of restarts—useful when a system like ZooKeeper prefers to update followers before the leader to minimize failovers. This prevents the control plane from restarting an application mid-operation, such as while it is building a data replica.
Reconciling customization with sharing
The fleet runs thousands of applications, and those applications benefit from tuning their environment. The web tier, for instance, gains 11 percent higher throughput from OS kernel adjustments like HugePages and CPU scheduling tweaks. But a shared infrastructure requires standard configurations so machines can be reused freely. Twine reconciles these goals with host profiles: named sets of hardware and OS settings that workloads can customize. Because machine allocation and profile switching are fully automated, fleet-wide operations—such as swapping machines between workloads to relieve network or power hotspots—don't force a tradeoff against workload performance.
The result is infrastructure that behaves as a single shared resource rather than a patchwork of purpose-built pools. The full details of the system were presented at OSDI 2020 and are available in the paper “Twine: A unified cluster management system for shared infrastructure.”
