Around 2015 the pitch was that the server cupboard was finished. Everything was going to the cloud, and anyone still buying physical kit was being sentimental about it. A decade later, plenty of companies did move most of their IT into someone else's data centre and are glad they did. A quieter number moved things back. Some never left in the first place.
That is not a story about the cloud being oversold. It is that the decision turned out to be per workload rather than per company, and the hardware under the abstraction still has opinions about your latency and your invoice.
The box is still there
Every cloud service runs on physical servers. When you launch an instance you are renting a slice of a machine sitting in a rack in a warehouse, drawing power and needing cooling like anything else with fans in it. The provider handles the parts nobody enjoys, which is most of why people pay them, but the hardware underneath still sets how fast your application answers.
That stops being an abstract point the moment your workload does not fit the menu. Instance families come in fixed shapes, with a memory-to-vCPU ratio somebody else chose. If you need a lot of RAM for a database and very little CPU, you buy the CPU anyway. If your software is licensed per core, the shape of the instance is suddenly a line item in a completely different budget. Own the machine and you write the spec: this much RAM, that RAID level, four network ports, local NVMe instead of a volume attached over the network.
What the invoice looks like in year three
For anything short-lived the cloud is hard to argue against. No upfront spend, no lead time, and you turn it off when the project ends. That is a genuinely different thing from what hardware offers, and pretending otherwise is how people end up with a rack they did not need.
The arithmetic moves once something has been running continuously for a few years. The monthly charge does not stop, and it drifts upward on its own as data accumulates. A machine bought outright is one number you can put in a plan. Enterprise hardware runs five years or more, the refurbished market makes that cheaper than most people assume, and finance teams tend to prefer a depreciating asset over a bill that moves with usage.
Then there is egress. Ingress is usually free and data leaving is priced per gigabyte, which is fine until the day you have to pull several terabytes out in a hurry and someone sees the invoice afterwards. It is the unglamorous kind of arithmetic nobody budgets for in advance, a bit like how counting business days turns out to be harder than it looks. Storage in a room you walk past does not have that particular edge.
Where the data physically sits
Some teams do not get a free choice. A law firm, a clinic or a local authority department may have explicit obligations about where records live and who can reach them. Being able to name the room, the rack and the person holding the key makes an audit substantially less interesting than trying to establish where a provider's backup replicas ended up.
The neighbour you cannot see
Shared hosts mean shared hardware, and a busy tenant on the same physical machine can slow you down. The usual name for it is the noisy neighbour problem, and the reason it is maddening is that your own metrics look fine. CPU usage is normal, the application is doing nothing unusual, and things are just slower on Tuesday afternoons for no reason you can point at.
The signal, when you can see it at all, is steal time: the share of cycles the hypervisor took away while your vCPU was ready to run.
$ vmstat 1 5
procs -----------memory---------- ---system-- ------cpu-----
r b swpd free buff cache in cs us sy id wa st
2 0 0 412332 98244 1884120 2103 4188 31 4 59 0 6
3 0 0 411980 98244 1884140 2456 4902 34 5 54 0 7
That st column is the one to watch. On dedicated hardware it is zero and stays zero, which is less of a performance feature than a debugging one. You stop having to rule it out.
Distance is not free either
A point of sale terminal or a line controller talking to a server on the same switch answers in about a millisecond. The same conversation with a region a few hundred miles away costs tens of milliseconds, every round trip, forever. If the protocol is chatty, that multiplies into something people notice. And when the connection to the outside world drops, the machine in the next room keeps serving.
Most real setups are both
Nearly every sensible arrangement I have seen ends up mixed. Email, video calls and the public website belong in the cloud, because they scale on demand and the large providers keep them up better than a small team can. File storage, accounting databases, backups and anything wired to specialist equipment often earn their place on hardware you control.
The useful habit is deciding workload by workload rather than picking a side and defending it at every planning meeting. In practice, moving one or two heavy, steady, boring systems onto your own iron is what trims the monthly bill, while everything spiky stays where it is.
If you are weighing it up, price the configuration you would actually buy instead of arguing from vibes. Vendors list what a given budget gets you, and seeing the real numbers on rack and tower servers alongside twenty-four months of invoices for the same workload settles the question faster than any amount of opinion. Sometimes the answer is that the cloud was right all along, which is also worth knowing before the next renewal.
Keeping it proportionate
You do not have to like or dislike the cloud. It is an excellent tool for some things and a poor one for others, and the same is true of a machine humming away in a comms room.
Hardware matters because it sets the ceiling on cost, speed and control no matter whose name is on the electricity bill. Teams that keep that in mind and judge each system on its own terms usually end up with infrastructure that costs less and pages them less often.
Top comments (0)