For twenty years, cloud architecture rested on a single unwritten premise: compute capacity is infinite.
You benchmarked your service on a specific virtual machine shape, hardcoded it into your Terraform configs, and set up an autoscaler. Systems architecture was taught as an optimization between two variables: performance and cost. Availability and elasticity were treated as invisible constants provided by the cloud provider. If your traffic spiked 10x overnight, the assumption was that the datacenter would always have thousands of that exact chip waiting on demand.
That model is quietly breaking.
Between the massive infrastructure demands of AI and physical hardware lifecycles, datacenter capacity is physically bounded. At Google, the architectural strategy to address this is Design for Obtainability (DfO). I want to write down my read of what it means, why the old model broke, and how systems architecture is shifting.
The two-variable model
When we optimized systems purely for performance and cost, we treated infrastructure like a deterministic contract. Sizing an application meant finding the sweet spot on a benchmark graph, locking that configuration in, and expecting the underlying hardware to never change.
Today, that two-variable optimization is no longer enough.
If an application cannot obtain compute during a traffic surge, its theoretical benchmark performance is zero and its cost model is meaningless. Obtainability—the ability of a system to reliably secure the hardware it needs to execute—is now the non-negotiable third pillar of systems architecture.
Why now: the AI squeeze
There is a simple reason this is surfacing across the industry right now: AI.
The public discussion around AI usually focuses on model weights and GPU training clusters. But in production, AI inference and agentic workflows create a fundamentally different operational profile: massive, bursty, and memory-intensive.
When autonomous agents execute tools, retrieve context, and generate tokens in parallel, compute demand does not arrive as a smooth web traffic curve. It arrives in synchronized, unpredictable surges.
At the same time, the physical supply chain is tightly constrained. Memory manufacturers have prioritized fabrication capacity for High Bandwidth Memory (HBM), tightening standard DRAM supply and driving server memory to roughly 90% of the total server bill of materials. Meanwhile, older server generations are steadily reaching end-of-life while newer generations scale up.
When thousands of automated autoscalers simultaneously demand the exact same legacy machine shape during a regional peak, they don’t get elasticity. They get stockout errors (ZONE_RESOURCE_POOL_EXHAUSTED).
The datacenter didn’t run out of compute. The software simply refused to run on anything other than one specific server model.
The migration trap
The standard engineering reaction to capacity bottlenecks is to plan a migration: “Let’s upgrade all our fleets from older chips to the latest generation.”
While newer silicon delivers superior energy efficiency and higher throughput, treating a hardware upgrade as an availability strategy misses the root architectural problem.
Swapping one hardcoded chip for a newer one in your deployment manifests does not eliminate capacity risk. It simply moves your single point of failure onto a newer production line. The moment regional demand spikes for that specific processor, your autoscaler hits the exact same wall.
True resilience does not come from finding the “safest” chip. It comes from architecting software that can bend across different hardware types without breaking.
How Design for Obtainability works
Design for Obtainability shifts infrastructure from a static hardware dependency to an abstract compute capability with defined performance boundaries.
Instead of demanding a single machine shape, workloads define a prioritized fallback map across processor generations and architectures:
- Primary target: Modern, high-efficiency silicon (such as current-generation Intel or specialized accelerators) for optimal baseline performance.
- Architecture fallback: Automatic spillover to alternative architectures (such as AMD or ARM-based silicon like Google Axion).
- Granularity fallback: Assembling required capacity across multiple smaller machine shapes using container bin-packing rather than waiting for a single large host.
In Google Kubernetes Engine (GKE), this is handled natively through Custom Compute Classes (ComputeClass). Platform teams declaratively define ranked fallback tiers directly in Kubernetes manifests. When primary nodes are constrained during a spike, the cluster automatically provisions secondary hardware pools.
The design property I care most about is active upward migration. The scheduler does not leave your workloads stranded on fallback hardware permanently. The cluster continuously monitors inventory in the background, and the moment preferred Tier-1 silicon frees up, it gracefully migrates workloads back to your primary hardware.
Aligning the commercials
Technical flexibility is useless if procurement governance penalizes you for it.
Historically, Committed Use Discounts (CUDs) locked organizations into specific machine families to capture volume pricing. If an application spilled over to an alternative chip vendor during a surge, that compute was billed at full on-demand rates.
Modern FinOps strategies rely on spend-based commitments (Flex CUDs). Because the discount attaches to total compute spend rather than a rigid machine name, an application can dynamically route across Intel, AMD, and ARM architectures throughout an afternoon while preserving its contracted discount tiers.
The reality check
The empirical difference between rigid single-SKU scaling and flexible spillover is stark.
Internal capacity modeling across high-demand enterprise regions shows that relying on on-demand provisioning of a single hardcoded machine family yields roughly ~10% capacity assurance during tight constraint windows. Opening the workload’s scheduling tolerance across a multi-family fallback map elevates capacity assurance to ~87% under the exact same conditions.
Just as the industry had to unlearn perimeter security to adopt Zero Trust over the last decade, platform teams now have to unlearn the assumption of infinite, homogeneous compute.
The systems that scale reliably in the AI era will not be the ones that bank on an endless supply of identical chips. They will be the ones designed to bend under pressure, absorb peak demand, and keep running.
Opinions are my own.