Observed facts: Uber says Odin runs workloads across roughly five million cores, including old and new x86 and ARM hosts, with single-core performance varying by nearly a factor of two. For Kafka, Uber reports that the utilization spread narrowed from eight percentage points to three and allocated cores fell by about 8% during rollout.
Mechanism: Uber assigns host performance factors, converts CPU usage into normalized compute units, computes cluster targets in those units, then translates the targets back into physical cores for the selected host. Why now: The company’s mixed on-premises and public-cloud fleet, along with stateful placement constraints, makes raw core counts a poor proxy for comparable capacity; stateless traffic cannot simply be redistributed across equivalent instances.
The model also has a feedback loop: Uber says production CPU data is used to tune factors by technology after synthetic benchmark factors proved insufficient. The implication is that fleet abstraction need not mean pretending machines are equivalent; a scheduler can preserve hardware choice while normalizing the resource contract above it. First implication: For operators with mixed hardware and stateful workloads, a performance-based target can reduce over-allocation on fast hosts while protecting workloads moved to slower hosts.
Evidence boundary: The figures are Uber’s reported results for its own Odin rollout and Kafka case, not an independent evaluation or a guarantee for other fleet sizes, workload mixes, or cost structures. First watch condition: Whether Uber’s production-derived performance factors remain stable across technologies and workload mixes, and whether the reported allocation and reliability gains persist as rollout expands.
The useful test is not whether core counts converge, but whether normalized targets continue to deliver comparable service under real placement changes.