Systems Outlive Their Assumptions

Every capacity plan starts from assumptions about requirements: how much memory a service needs, how fast storage has to be, what a unit of compute costs. The assumption that rarely gets examined is that those requirements hold still while you execute against them. They do not. The hardware moves underneath the plan, the suppliers retire parts out from under the hardware, and the people move out from under all of it. A system you provision this year can easily run longer than the team that chose it. A capacity plan that assumes the requirements of today will describe the machine of 2041 is not a plan; it is a snapshot that decays.

The hardware keeps moving

Take storage. For roughly fifteen years the standard answer for transactional storage was the 15,000 RPM enterprise drive. Seagate’s Exos 15E900, marketed as the world’s fastest hard drive, publishes an average latency of 2.0 milliseconds and a few hundred IOPS per drive in mixed workloads.¹ A current-generation NVMe drive such as the Micron 9550 publishes 3.3 million random-read IOPS with read latency around 60 microseconds.² That is roughly thirty times better on latency and nearly four orders of magnitude on IOPS. Anyone who sized a storage tier around spinning-disk assumptions built a plan for hardware that no longer exists.

Memory is the sharper lesson, because it inverts an assumption people carried for decades: that memory keeps getting cheaper. Since late 2025, AI demand has flipped it. TrendForce’s third-quarter 2026 survey forecasts conventional DRAM contract prices rising another 13–18% quarter over quarter, with server DRAM undersupplied and a growing share of procurement governed by long-term supply agreements.³ The cost of memory is much higher than it was a year ago, and the trend is not a blip; it is capacity being reallocated to a different buyer.

The previous generation is being retired out from under live fleets while this happens. Samsung stopped taking DDR4 orders in mid-2025, Micron sent end-of-life notices in June 2025 with final shipments in the first quarter of 2026, and SK hynix, last of the three, plans to finish DDR4 shipments by April 2026.⁴ A memory generation that powered server fleets built through 2020 is now the scarce part, and it is scarce because the suppliers walked away from it.

Compute capability tells the same story at longer range. Amazon EC2 launched in August 2006 with a single instance type, m1.small. AWS now publishes more than 400 instance types and maintains a “previous generation” page that recommends the latest families for new applications.⁵⁶ The accelerator market moves even faster: an NVIDIA A100 carries 80 GB of HBM2e; two generations later, a B200 carries 180 GB of HBM3e with close to four times the memory bandwidth.⁷ The same workload, run a decade apart, is not the same workload.

The machine outlives the team

Here is the part that turns hardware drift into a planning problem. The median full-time worker in the United States had been with their employer 3.9 years as of January 2024, the lowest since 2002, and 22% of workers had been with theirs for a year or less.⁸ The biggest Cassandra clusters I have seen have been running for about 15 years (chapter 12). Over the life of such a system, the median engineer changes employers three or four times. The people who sized it will not be in the room when the memory supplier sends the end-of-life notice.

The lifecycle clocks are public and long. CentOS 7 shipped in 2014 and reached end of life on June 30, 2024, a full decade with the date announced years in advance, and the CentOS project blog post pleading with operators to start planning early.⁹ Even the best-instrumented buyers are recalculating in both directions: Amazon extended the useful life of its servers from five years to six effective January 2024, then moved a subset back from six to five effective January 2025, citing “the increased pace of technology development, particularly in artificial intelligence and machine learning.”¹⁰¹¹ Read that last sentence twice. The buyer with the most operational data in the world is telling you the pace of change accelerated enough to shorten the working life of its own fleet. That is the environment your fifteen-year cluster lives in.

Why engineering teams won’t drive this

They shouldn’t, and it is not a failure. An engineering team’s horizon is the sprint and the quarter: deliver the feature, close the ticket. AWS Compute Optimizer is that horizon mechanized: it analyzes the last 14 days of utilization metrics by default, or 93 days with enhanced metrics, and produces rightsizing recommendations from that window.¹² That window answers one question, what this service needs this month. No lookback window answers the question a fifteen-year deployment actually poses: what will the memory market, the storage market, and the accelerator roadmaps do while this system runs until 2041. That is not a flaw in the tool. The question is out of scope for anything that watches your fleet, because the answer lives outside your fleet, in supplier roadmaps, end-of-life notices, and earnings filings. Someone has to be assigned to look there on purpose.

The capacity plan for a decade

So the capacity team owns the decade view, and four things make it real. The plan should name the SKU migrations that are already scheduled (DDR4 to DDR5 is underway now) and the ones visible behind them, with rough dates and a migration window; capacity planning that only counts nodes is planning for a hardware landscape that will not survive the plan (chapter 11). Track the vendors’ lifecycle clocks: end-of-life notices, last-order dates, useful-life studies, and supply reports are all published, and nobody collects them by default. This is where AI is a genuine help; the same class of models that strained memory supply can watch changelogs, press releases, and earnings transcripts continuously and surface the dates into a capacity calendar. You do not need a team reading everything, you need an automated watch with a human who reads what it flags. Re-test the requirements assumptions on a calendar: every quarter, name the assumptions the plan was built on, memory gets cheaper, storage tiers are interchangeable, compute per dollar keeps improving, and check which one the quarter just proved wrong. And never let the plan be static, because a plan without a review date is a document that has already started to decay. The review cadence is the plan.

Some of the systems you provision today will live longer than the people who chose them. The hardware will change under them, suppliers will retire parts from under them, and teams will turn over around them. Engineering will keep shipping what the month needs; that is its job. The capacity plan is where somebody is paid to think about the decade. Put the decade in it, and keep it moving.

Sources