This article is based on a perspective piece originally published on TechTarget (2018). The core arguments remain highly relevant as infrastructure-as-code adoption continues to accelerate.
History Repeats: From Operators to Sysadmins to… What?
In the early days of enterprise computing, computer operators held a defined place in IT. They ran overnight backup jobs, swapped tapes, entered commands by hand, and handled whatever manual tasks the shift required. It was a role that depended on human presence to compensate for the limitations of the technology.
Then disk storage became cheap. Programmers wrote jobs to automate what operators once did by hand. The role didn’t evolve fast enough, and it largely disappeared.
The same pattern is now playing out for traditional systems administrators. Automation tooling, cloud-native infrastructure, and infrastructure-as-code practices are systematically absorbing tasks that once required dedicated operational headcount. The question isn’t whether this shift is happening — it clearly is — but how operations professionals respond to it.
The Evolution of Scripting: From Corner Cases to Production Engineering
Sysadmins have always written scripts. Shell scripts to copy data, clone machines, check uptime, and fire off alerts when services go down. This was a practical and effective approach — small, targeted automation that solved immediate operational problems.
The problem was isolation. Those scripts lived outside version control, outside the testing pipeline, and outside any formal requirements process. They worked well enough in most cases, but they weren’t engineered — they were improvised.
Infrastructure as code changes the scope and the stakes. Today, entire machine states can be defined in code, stored in version-controlled repositories, peer-reviewed, tested, and deployed through automated pipelines. Tools like Terraform, Ansible, Puppet, Chef, and Docker Compose allow teams to treat infrastructure with the same engineering discipline applied to application code. The result is reproducible, auditable, and scalable environments — built and torn down on demand.
This is not just scripting. It is software engineering applied to infrastructure, and it demands a corresponding shift in how operations professionals think about their work.
Operations Still Matters — But the Role Must Evolve
The rise of infrastructure as code does not eliminate the need for operational expertise. Developers generally do not have deep knowledge of network file systems, storage area networks, load balancer configuration, patch management strategies, or security hardening. Those domains require experienced operations professionals to define requirements and translate business needs into infrastructure specifications.
Two common organisational models are emerging to handle this transition:
- Centralised architecture team model: A dedicated infrastructure or platform engineering group builds shared, reusable infrastructure components — essentially a self-service vending machine for development teams. Dev teams consume pre-approved, pre-configured building blocks without needing to understand the underlying complexity. This model scales well in large organisations but can create bottlenecks and distance operations from day-to-day product delivery.
- Embedded sysadmin model: Operations engineers sit directly within product or delivery teams, contributing infrastructure knowledge alongside developers. Job descriptions are deliberately blurred. The team collectively owns the full delivery pipeline. This model tends to produce faster feedback loops and stronger shared ownership, though large enterprises often resist the organisational ambiguity it requires.
Neither model is universally correct. The right fit depends on team size, organisational culture, and the maturity of existing DevOps practices.
Practical Steps for Operations Professionals to Stay Relevant
If you work in a DevOps operations role today, the single most dangerous response is inaction. Here are concrete steps to lead the transition rather than be overtaken by it:
1. Put Your Scripts Under Version Control
Start with what you already have. Move existing automation scripts into a Git repository. Write a basic README. Add peer review. This simple step immediately raises the quality bar and makes your work visible and collaborative.
2. Learn an Infrastructure-as-Code Tool
Pick one tool that fits your environment and invest in it seriously. If you are running Linux workloads, Docker and container orchestration are logical starting points. For cloud provisioning, Terraform is widely adopted. For configuration management, Ansible has a relatively low learning curve for those already comfortable with YAML and SSH.
3. Partner with Developers
Find a developer on your team or in your organisation and work on something together. You bring the operational knowledge — network topology, security constraints, performance requirements. They bring software engineering discipline — testing patterns, CI/CD integration, code review practices. The combination is far more powerful than either skillset alone.
4. Volunteer for Architecture and Platform Work
If your organisation is building a platform engineering or architecture group, put your hand up. These teams translate operational domain knowledge into reusable, consumable infrastructure. Your existing expertise in systems, networking, and reliability is directly applicable — and your involvement ensures the platform reflects real-world operational constraints.
5. Treat Infrastructure Like a Product
Good infrastructure as code is designed with users in mind — typically developers and other operations teams. Think about the interface you’re providing. Write documentation. Gather requirements. Test your code. Treat the internal teams consuming your infrastructure as customers. This mindset shift is what separates a shell script from a platform.
The Opportunity Is Real
Operations professionals possess contextual knowledge that is genuinely hard to replicate: how systems behave under load, where the failure modes are, what the network actually looks like at 2 a.m. during an incident. That knowledge is invaluable. The risk is not that machines will make it worthless — it’s that the knowledge remains locked in manual processes rather than encoded into automated, testable, repeatable systems.
The sysadmins who thrive in the next decade will be those who choose to encode their expertise rather than protect their manual workflows. Infrastructure as code is not a threat to operations — it is the mechanism by which operations scales.
Lead the change. Don’t wait for it.