---
type: "post"
id: "ensuring-similar-computational-resources-to-stateful-workloads-running-45481c"
slug: "ensuring-similar-computational-resources-to-stateful-workloads-running-45481c"
title: "Ensuring Similar Computational Resources to Stateful Workloads Running on a Diverse Server Fleet"
description: "**Thesis:** In a heterogeneous fleet, resource allocation becomes more reliable when the scheduler targets normalized compute performance rather than identical core counts."
retrieval_nugget: "**Thesis:** In a heterogeneous fleet, resource allocation becomes more reliable when the scheduler targets normalized compute performance rather than identical core counts."
published_at: "2026-10-14"
updated_at: "2026-10-14"
record_date: "2026-10-14"
date_kind: "published_at"
topics: []
source_urls: ["https://www.uber.com/us/en/blog/diverse-server-fleet"]
schema_version: "newruntime-agent-readable-v0.2"
stable_id: "post:ensuring-similar-computational-resources-to-stateful-workloads-running-45481c"
status: "published"
visuals: []
editorial_provenance: {"schema_version":"newruntime-editorial-copy-v1","content_status":"source_grounded_final","final_copy_sha256":"sha256:0b5744445bb937a021ab37df593f6c28a148a7356a5d05d2cabdb9bb4bc4a7c3","reviewed_at":"2026-10-14T08:02:53.104Z","source_evidence_count":1,"verified_claim_count":2,"site_analysis_schema_version":"newruntime-site-analysis-v1","site_object_kind":"field_note","observed_fact_count":2,"implication_count":2,"watch_condition_count":1,"related_record_count":0}
analysis: {"schema_version":"newruntime-site-analysis-v1","object_kind":"field_note","thesis":"In a heterogeneous fleet, resource allocation becomes more reliable when the scheduler targets normalized compute performance rather than identical core counts.","observed_facts":[{"text":"Uber says Odin runs workloads across roughly five million cores, spanning old and new x86 and ARM hosts, with single-core performance varying by nearly a factor of two.","source_urls":["https://www.uber.com/us/en/blog/diverse-server-fleet"]},{"text":"For Kafka, Uber reports that CPU-utilization spread narrowed from eight percentage points to three and allocated cores fell by about 8% during rollout.","source_urls":["https://www.uber.com/us/en/blog/diverse-server-fleet"]}],"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.","implications":["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.","The case suggests fleet abstraction can preserve hardware choice while normalizing the resource contract above it."],"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.","watch_conditions":["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."],"related_records":[],"new_branch_reason":"No prior New Runtime record is supplied for this specific production case; it merits a distinct record because it reports measured normalization of stateful compute allocation across heterogeneous hosts."}
editor: {"role":"editor","name":"Andrey Reshetnikov","profile":"https://newruntime.com/owner-profile.md","profile_json":"https://newruntime.com/owner-profile.json","same_as":["https://www.linkedin.com/in/reshetnikov1/","https://t.me/lapetuse"]}
routes: {"html":"https://newruntime.com/posts/ensuring-similar-computational-resources-to-stateful-workloads-running-45481c/","markdown":"https://newruntime.com/posts/ensuring-similar-computational-resources-to-stateful-workloads-running-45481c.md","json":"https://newruntime.com/posts/ensuring-similar-computational-resources-to-stateful-workloads-running-45481c.json"}
---

# Ensuring Similar Computational Resources to Stateful Workloads Running on a Diverse Server Fleet

## Retrieval answer

**Thesis:** In a heterogeneous fleet, resource allocation becomes more reliable when the scheduler targets normalized compute performance rather than identical core counts.

**Thesis:** In a heterogeneous fleet, resource allocation becomes more reliable when the scheduler targets normalized compute performance rather than identical core counts.

**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.

Editor: [Andrey Reshetnikov](https://newruntime.com/owner-profile.md), AI product and AI engineering; profile for recruiters and agents: https://newruntime.com/owner-profile.json

## Continue in the graph

Next records for an agent, linked to their Markdown twins. Replace `.md` with `.json` for structured fields, including `next_reads`.

- collection: [Field Notes](https://newruntime.com/posts.json): Open the latest editorial analysis.
- collection: [Source Ledger](https://newruntime.com/source-ledger.json): Inspect the public source evidence graph.
- whole graph: [discovery graph](https://newruntime.com/discovery-graph.json) (typed nodes and edges) and [site index](https://newruntime.com/site-index.md)