Cloud and Infrastructure: Renting Instead of Guessing

Before the cloud, running a website meant buying servers. You estimated how much traffic you would get, bought machines for that, and installed them somewhere.

The estimate was always wrong. Buy too few and the site fell over when it mattered. Buy too many and expensive hardware sat idle, depreciating.

Worse, you had to buy for your busiest hour. A shop with a large seasonal peak needed enough capacity for that peak all year round, and most of it did nothing most of the time.

The cloud did not invent the server. What it changed is that capacity became something you rent by the hour instead of buying in advance — which turned a large uncertain bet into a variable cost. That is a financial change more than a technical one, and it is the source of nearly everything that followed.

What the change actually enabled

Starting became cheap. A new project can run on almost nothing and scale up if it works. Previously the initial capital requirement filtered out ideas before anyone could test them. This lowered the cost of finding out whether something works, which matters more than the hardware saving.

Failure became cheap too. If it does not work, you stop paying. Sunk capital in unused hardware was a genuine barrier to abandoning things, which is loss aversion with a physical object attached.

Peaks stopped requiring permanent capacity. The gap between peak and average demand is often large. Renting means paying for the peak only during the peak.

Operations became someone else's specialty. Physical security, power redundancy, hardware replacement, and network engineering are real disciplines. Most organisations were doing them badly because they were not the point of the business.

There is a straightforward economic reading of all this: cloud providers made computing capacity into a commodity that others build on, which is commoditize your complement operating at industrial scale — and it explains why so much foundational software is given away by companies that sell the infrastructure it runs on.

What it costs

The trade-offs are real and frequently discovered late.

It is not always cheaper. Renting is cheapest for uncertain or spiky loads. A large, steady, predictable workload is the case where owning hardware can genuinely cost less — sometimes substantially. Several companies at significant scale have moved workloads back for exactly this reason, and it is a legitimate calculation rather than a failure to understand the cloud.

Costs are variable, which cuts both ways. Spending scales with use, which is excellent when use is low and alarming when something misconfigured runs all weekend. The absence of a hard ceiling is a genuine risk that owning hardware did not have.

Dependency is real. Building on a provider's managed services is more productive and harder to leave. The switching cost is not usually the raw compute — it is everything built around it. This is an ordinary economic moat, and being on the wrong side of one is uncomfortable.

Concentration creates shared failure. A large fraction of the internet depends on a small number of providers and a smaller number of regions. Outages therefore take down apparently unrelated services simultaneously, which is emergence producing a failure mode nobody designed.

Someone else's priorities apply. Maintenance windows, deprecations, and pricing changes happen on the provider's schedule.

Two things that are widely misunderstood

"The cloud" is not one thing. Renting a bare virtual machine and using a fully managed database are very different commitments. The first is close to substitutable; the second embeds provider-specific behaviour throughout your system. Most complaints about lock-in are really about how far up that stack an organisation chose to build, which was a decision rather than an inevitability.

Multi-cloud is usually a worse answer than it sounds. Running across several providers to avoid dependence means using only the features they have in common, maintaining several sets of expertise, and carrying more complexity — while Gall's Law suggests the added complexity brings its own failures. It is sometimes justified, generally for regulatory reasons, and it is not a free hedge.

The reasonable default for most organisations is to use managed services deliberately rather than accidentally: accept dependence where the productivity gain is large and the alternative is genuinely worse, and keep the pieces that would be expensive to migrate closer to portable.

What has not changed is the underlying question. Someone still has to own machines in buildings with power and cooling. The cloud moved that responsibility to organisations that specialise in it and rearranged how it is paid for. Both are real improvements, and neither makes the physical layer disappear — which becomes obvious every time a region goes down and a great many unrelated things stop working at once.