Sergey Nivens - Fotolia
Keep DevOps operations relevant in the age of code
The operations role isn't going away in DevOps, but it is going to change -- in some cases, dramatically. Expert Matthew Heusser explains what you need to do to be prepared.
When I was right out of college, I actually interviewed for computer operator jobs twice. The first was an overnight shift at a hospital, starting at 10 p.m. and ending at 6 a.m. Operators had to run backup jobs, type in the command from the command line, switch tapes when the tapes filled and stuff envelopes when there was nothing to do. It wouldn't be long until I'd see a listing of the career opportunities in IT, with programming, system administration and everything else exploding. It seemed only computer operators had a limited future.
It turned out that disks got cheap, and programmers could write jobs to eliminate the human work of the operators. Organizations can even outsource and automate envelope-stuffing.
Some machine ate the operator.
Today, that machine is coming for systems administrators. Here's what this means for DevOps operations teams.
Scripting unlocks DevOps
Of course, there have always been smart sys admins who wrote scripts. They'd write scripts to copy data, to clone machines, to check if machines were running and send a notification if they were down.
This was a type of code off in a corner and in a different language than the production programmers. This was code hidden from any sort of disciplined engineering progress and from the testers or any kind of portfolio management. Sys admins would create scripts to get a job done, and the scripts were usually small enough and worked often enough to be fine.
There is a newer, more powerful form of scripting coming. Now, the machines themselves are saved to disk and created through code. Technical staff can save the exact state of a machine in a file small enough to shoot around on network drives. The code to create these is probably going to be real production code, stored in version control, built under requirements and tested by quality assurance. Once that code is up, the technical staff can consume it, build test environments and even put new servers in production with a few mouse clicks.
DevOps skills transform sys admins into SREs
If they want a future in DevOps, IT ops pros need to know how to write and script code. Sys admins who've yet to adapt to DevOps face extinction. Those who've made the jump from sys admin to site reliability engineer have some advice for you.
Sys admins do DevOps, too
In this new world, there will still be a place for operations. Programmers, after all, don't know how to keep systems patched. They need a DevOps operations team to set up networked file systems and storage area networks, or to configure the load balancer. In order to run infrastructure as code, programmers need requirements and someone to tell them what the code should do. Meanwhile, most sys admins have the aptitude to learn the coding portion.
Most organizations are moving toward a DevOps operations team to build that infrastructure. Sometimes, we refer to that infrastructure as architecture. The goal is to give the organization push-button self-service. The architecture group just builds the vending machine.
Another model, one I am more comfortable with, embeds sys admins on the DevOps team, de-emphasizes job descriptions and enables the team to build the infrastructure themselves. For some reason, large companies are uncomfortable with this.
Lead a DevOps group
So, here's my suggestion for those on DevOps operations teams today.
Don't fight these changes. Lead them. Volunteer to join the architecture group. Make friends with a programmer, and get your scripts under version control. Find ways to build more powerful scripts, scripts that create infrastructure as code -- if you are running Linux, look into Docker -- but partner with a developer to make the script real software engineering, exposed to a business customer, with real requirements and testing.
Pretty soon, you might find yourself leading a DevOps operations group.
And that might just be OK.