Twenty Years of Servers: What Actually Matters

I started in IT when servers were physical things you could touch. You racked them. You cabled them. When one failed, you drove to the data centre and swapped a power supply. Now I manage infrastructure I'll never physically see, distributed across regions I'll never visit, running workloads for people I'll never meet.

The technology is unrecognisable from 20 years ago. The principles that matter haven't changed at all.

What's different

Scale. Twenty years ago, an "enterprise" environment was maybe 200 servers. Today it's thousands, plus containers, serverless functions, and SaaS services that blur the line between infrastructure and application. The tools scaled to match: automation, orchestration, infrastructure as code. You couldn't manage today's environments with yesterday's methods. You'd need an army.

Speed. Provisioning a server took weeks: order hardware, wait for delivery, rack and cable, install OS, configure. Today: New-AzVM and it's ready in minutes. The bottleneck shifted from infrastructure to decision-making. The limiting factor isn't how fast you can provision. It's how fast you can decide what to provision.

Responsibility. Infrastructure used to be a cost centre. Keep the servers running, keep the network up, stay within budget. Now infrastructure is strategic. It determines how fast the business can move, how resilient it is to disruption, how secure it is against threats. The job grew from "keep it running" to "enable the business to run."

What hasn't changed

Discipline matters more than tools. The best migration tool in the world won't save you if you haven't mapped your dependencies. The best monitoring platform won't catch the incident your alerting rules were too coarse to detect. Tools amplify capability. They don't replace judgment. The difference between a good infrastructure engineer and a great one isn't tool knowledge. It's the discipline to test restores, validate migrations, and not trust the status dashboard.

Documentation is underrated and underdone. Every environment I've inherited had documentation problems. Every environment I've built has documentation problems. The goal isn't perfect documentation. It's good enough documentation that someone else could recover the environment if you got hit by a bus. If your "documentation" is in your head, you don't have documentation. You have a bus factor of one.

The best people are relentlessly curious. The engineers I've learned the most from share one trait: they don't stop at "it works." They ask why it works. They ask what happens when it stops working. They read the documentation for technologies they don't use, because understanding adjacent systems makes you better at your own. Curiosity compounds over a career.

Nobody cares about uptime until it's down. Infrastructure is invisible when it works. The only time anyone notices is when it fails. Getting comfortable with being invisible is part of the job. The goal isn't recognition. The goal is that nothing bad happens, and when it does, you fix it before anyone notices.

What I'd tell someone starting today

Learn the fundamentals. Not the latest tool. The fundamentals: TCP/IP, DNS, authentication, storage, operating systems. Tools come and go. TCP/IP has been the same since before you were born. DNS is older than you are. Knowing why a packet doesn't arrive is more valuable than knowing the latest deployment pipeline.

Learn to script. Not because automation is trendy. Because automation is leverage. A script you write once that runs a thousand times is a thousand tasks you didn't have to do manually. PowerShell, Bash, Python — doesn't matter which. What matters is the instinct to automate anything you do more than twice.

Learn to explain technical concepts to non-technical people. The best technical decision you'll ever make will be overruled if you can't explain why it matters to someone who controls the budget. Technical skill gets you the job. Communication skill gets your recommendations implemented.

Learn to be wrong. You will make bad calls. You will deploy something that breaks. You will miss an edge case that causes an incident. The difference between a good engineer and a great one is how fast they admit the mistake, fix it, and learn from it. Defensiveness is career-limiting. Humility is career-accelerating. The people who say "I was wrong, here's what I learned" are the ones who get trusted with bigger decisions.

The arc

Twenty years ago I was racking servers in a cold data centre, hoping the cables I'd run at 2am would still be plugged in correctly when I came back. Today I design infrastructure from a terminal in my home office.

The tools changed. The scale changed. The architecture changed. But at the core, it's still the same job: keep the systems running, make them faster, make them cheaper, make them more reliable. Do it quietly. Do it well. When something breaks, fix it. When something can be better, improve it. When someone asks how it works, explain it.

That's been a good career. I'd do it again.