Whatever happened to capacity planning

Job listings are a fossil record. Search one of the large boards for "capacity planner" today and the results are warehouse logistics and electrical utilities, with a thin seam of telecoms. Thirty years ago the same title was a fixture of corporate computing, a person, often a small department, whose job was to predict how much computer the business would need next year and to be measurably wrong by as little as possible. The title has almost vanished from software organizations. The work, this essay will argue, has not; it has been renamed, moved after the fact, and handed to whoever opens the bill.

Begin, as usual, with the definition. Capacity planning is the practice of forecasting demand on a system, translating that forecast into resources, and buying those resources ahead of need. Three separate acts: a prediction, a translation, a purchase. The textbook version has not changed since the mainframe era, because none of the three acts depends on any particular technology. What technology changes is who performs them, how often, and whether anyone notices when they are performed badly.

On the mainframe the discipline was unavoidable, because the purchase was enormous and slow. A machine upgrade was a capital request with a board signature and a delivery calendar measured in quarters. Getting the forecast wrong in one direction meant the month-end batch run broke into the business day; wrong in the other direction meant a very expensive room staying very cool for nothing. So the forecast became an institution. Practitioners had their own professional body from the mid-1970s, the Computer Measurement Group, with conference proceedings full of queueing theory applied to real workloads. Usage was metered, charged back to the departments that generated it, and reviewed quarterly in a meeting where finance and engineering sat at the same table and argued from the same spreadsheet. It is worth pausing on how unusual that sentence sounds now.

The client-server wave of the 1990s loosened the discipline without killing it. Servers were cheap enough that the forecast could be lazy: size for the peak, then double it. Overprovisioning became the plan rather than the failure, and the capacity review shrank from a quarterly institution to a purchasing habit. But a habit is still a decision made in advance, and somebody still signed for the hardware before the demand arrived. The three acts, prediction, translation, purchase, still happened in that order.

Then came the slider. Amazon opened EC2 to the public in August 2006 with instances rented by the hour, and the industry drew what seemed the obvious conclusion: if capacity can be summoned in minutes, forecasting it is wasted motion. Why predict demand when the platform absorbs whatever arrives? Autoscaling groups turned the response into policy. The capacity planner's spreadsheet quietly stopped being updated, and nobody grieved, because elasticity was, and is, genuinely valuable. A retailer no longer sizes its estate for the November it hopes to have. A startup no longer buys servers for users it may never meet. The mainframe's cruel arithmetic, where an optimistic forecast was concrete poured in the wrong place, dissolved into an API call.

But look closely at what actually happened to the three acts, because none of them disappeared. The prediction survives, compressed into the autoscaler's configuration: a minimum count, a maximum count, a target utilization. Those numbers are a demand forecast, whether or not anyone calls them one, and they were typically written by whoever last edited the YAML, at the altitude of a code review, without a finance person in sight. The translation survives inside instance types and pool sizes. And the purchase survives most vividly of all: it arrives every month, itemized to a decimal point that suggests precision and aggregated to a level that prevents understanding.

What the cloud actually eliminated was not capacity planning but the moment at which it happened. The mainframe forecast was made before the spend, in daylight, with a signature. The autoscaled estate makes the same decision continuously, implicitly, and settles up afterward. The feedback loop that once ran through a quarterly meeting now runs through an invoice, and an invoice is a poor teacher: it arrives weeks after the behavior it describes, it names resources rather than causes, and the person who reads it is rarely the person whose YAML wrote the cheque.

The industry's response to this has been to reinvent the old institution under a new name. FinOps, as a movement, is usually described as bringing financial accountability to cloud spend, which is accurate and slightly evasive. Read its actual practices, unit economics, showback and chargeback, forecasting reviews, commitment planning, and what appears is the Computer Measurement Group's agenda wearing a lanyard. Chargeback, the mainframe's most resented ritual, is back without apology. The reserved-instance commitment, three years of compute bought ahead at a discount, is a capital purchase with a delivery calendar; procurement's clothes on capacity's body. We have essentially rebuilt the 1980s capacity review, except monthly instead of quarterly, and after the money is spent instead of before.

Some organizations have taken the argument further and simply gone back to buying computers. The most publicized was Basecamp, whose exit from the cloud, announced in 2022, was narrated to completion by its CTO in mid-2023 with the observation that their workloads were stable, their demand predictable, and the rent therefore a bad trade against ownership. Strip the polemic and what remains is a capacity plan performed in public: a known workload, a measured curve, a purchase made ahead of need. The heresy was not leaving the cloud. The heresy was forecasting, and finding that the forecast was cheap.

The honest counterargument deserves its paragraph. Elasticity is not a fad, and for the volatile parts of an estate the slider beats the forecast decisively. Launch traffic, viral spikes, batch experiments, anything genuinely unknowable: for these, paying the cloud's premium to avoid a prediction is correct, in the same way insurance is correct. The failure mode is not using the slider; it is using the slider for the half of the estate that has grown a steady, boring, forecastable baseline, the quiet workloads that have not surprised anyone since 2021, and paying the premium for an option that is never exercised. Owning the baseline and renting the spike was, for the record, how the mainframe shops handled Christmas, and the mainframe's survival suggests their arithmetic was not naive.

What was lost in the dissolution, more than money, was a conversation. The quarterly capacity review forced a specific exchange: engineering explained what the systems would need and why, finance explained what the business could carry, and the forecast that emerged was owned by both. The invoice-driven loop has no such table. Cost enters the architecture only after it has become a problem, at which point it arrives as an escalation rather than a plan. The capacity planner, whatever the title's faults, was a person whose job was to stand between those two rooms and be accountable for a number. Titles like that do not dissolve because the work ended. They dissolve because the work was cut into pieces too small to see, and pieces too small to see are pieces nobody owns.

The prescription, if an essay is allowed one, is modest. Somewhere in the organization, the three acts should be reassembled into a visible ritual for the stable half of the estate: a forecast written down before the quarter, compared against the bill after it, with both engineering and finance in the room and the variance explained by a named person. Call it FinOps if that releases the budget; the practitioners of 1975 would recognize it instantly, and would perhaps be too polite to ask why it took twenty years of invoices to rediscover the meeting.