From the data centre to cloud SRE: what changed in twenty years, and what didn't

Wed, 21 Oct 2026 00:00:00 +0000

I started in operations in 2006. For the first eleven years I worked on enterprise Linux and data-centre operations at a large bank. From 2017 to 2023 I did DevOps and SRE work on big-data platforms. Since September 2023 I have been building and running infrastructure for a trading firm on AWS, where latency matters as much as uptime.

That path covers most of the big shifts in how infrastructure is run. People often describe it as a revolution. Some of it was. A lot of it was the same work with better tools. This post is my attempt to separate the two.

What changed

Provisioning went from weeks to minutes

In the data centre, a new server was a project. Someone raised a request, hardware was ordered, racked, cabled, and built. Capacity decisions were made months ahead because mistakes were slow to fix.

At the bank, a new server took at least two weeks. That covered everything from the project team’s request, through architecture design, capacity planning and resource allocation, to deployment.

In the cloud, a new instance is an API call. That is a real change, and it shifts where the effort goes. The hard part is no longer getting a machine. It is deciding whether you should have one, who owns it, and how you will know when it is no longer needed.

Infrastructure became code

Build documents and hand-applied changes gave way to Terraform, configuration management, and pipelines. The benefit is not just speed. It is that the intended state is written down, reviewed, and versioned. A change has a diff, and a diff can be read by someone else before it ships.

The trap is assuming code means correctness. A Terraform plan that destroys and recreates a resource looks just as tidy as one that adds a tag. Reading plans carefully is still a human skill.

Pets became cattle (mostly)

Long-lived servers with names, history and careful hand tuning were normal in the data centre. Rebuilding one was a risk, so you nursed it. Today the default is replaceable instances built from images and templates. If something is wrong, you replace it.

“Mostly” matters. Databases, stateful brokers and some latency-critical hosts still deserve pet-like care. The skill is knowing which is which and being honest about it.

Monitoring became observability

Early monitoring was largely up/down checks and threshold alerts on CPU, disk and memory. Now we have metrics at high resolution, structured logs, traces, and the ability to ask new questions of the data after the fact.

The tools are much better. The discipline is still the hard part: alerting on symptoms users feel, not on every cause you can measure, and deleting alerts that nobody acts on.

On-call became a practice, not a punishment

SRE gave operations a vocabulary: service level objectives, error budgets, blameless reviews, toil. Those ideas existed in pieces before, but naming them made it possible to argue for them. An error budget turns “is it reliable enough?” from an opinion into a number that product and engineering can both look at.

Earlier in my career, incident reports focused on who was to blame. Now the focus is on finding the cause and preventing it from happening again.

The cost model flipped

In the data centre, cost was mostly capital spent up front. Once a server was bought, using it more was nearly free. In the cloud, cost is a running meter. Every idle instance, oversized volume and forgotten snapshot shows up on a bill each month.

This makes cost an engineering concern, not just a finance one. Tagging, rightsizing and cleaning up are now part of operating well.

Failure modes moved

A data-centre failure was often physical and local: a disk, a power supply, a switch. In the cloud, the hardware is someone else’s problem, but you inherit new failures: API rate limits, service quotas, misconfigured permissions, dependency on managed services you cannot see inside, and blast radius created by automation that does the wrong thing quickly and everywhere.

Systems are more distributed, so failures are more often partial. Something is slow rather than down. That is harder to detect and harder to explain.

What didn’t change

Linux fundamentals

Under every managed service and container is still a kernel, a scheduler, a network stack, file systems and processes. When something is slow or odd, the tools I learned early still apply: understanding CPU and memory pressure, I/O, network queues, and what the kernel is actually doing. In latency-sensitive work this matters more, not less.

In my experience, Linux kernel tuning is essentially the same in the cloud as it was in the data centre.

Change discipline

Most incidents I have seen discussed, in any era, trace back to a change. The bank taught me that changes need a plan, a reviewer, a window, and a rollback. Pipelines and feature flags make changes smaller and faster, but the questions are the same: what could this break, how will we know, and how do we undo it?

Capacity planning

Elastic capacity does not remove capacity planning. It changes it. You still need to know your peaks, your headroom, your limits and quotas, and what happens when a dependency cannot scale as fast as you can. “Autoscaling will handle it” is a plan only if someone has tested it.

Backups and disaster recovery

A backup you have not restored is a hope, not a backup. That was true with tapes and it is true with snapshots. Cloud regions and availability zones make recovery designs easier to build, but they do not test themselves, and they do not protect you from deleting the wrong thing with the right credentials.

People and runbooks

At three in the morning, the quality of a runbook matters more than the quality of the architecture diagram. Clear ownership, clear escalation, and written steps that a tired person can follow have not been replaced by any tool. Automation is the best runbook, but someone still has to know what it does and when it should not run.

Writing trade-offs down

Every infrastructure decision is a trade-off: cost against resilience, speed against safety, simplicity against flexibility. The decisions that aged worst, in my experience, were not always the wrong ones. They were the ones nobody wrote down.

When decisions from meetings or architecture designs aren’t documented, people later end up arguing about them, or nobody can understand why things are the way they are.

What I would tell someone starting now

Learn the cloud tools, because that is where the work is. But learn what is underneath them too. Linux, networking, and the habits of careful change will outlast any particular platform. The tools changed almost completely in twenty years. The judgement the job needs barely changed at all.

Eric Wang