Why is it important that we defend the idea of DevOps, separate from the role of Operations?
As you might expect from our twitter conversation, I have a lot of thoughts on the term DevOps. I first heard it at the Velocity conference in 2009 during what I think is still the best introduction to the subject.
At the time, I was working for a medium size adtech company and I was just blown away by the idea of CI/CD. I was still doing semi-manual deploys and using CFEngine to manage an installation of ~1,000 servers. Deploys were a nightmare, oncall shifts were torture, and everyone was miserable (including the software engineers and the managers).
To me, the difference between DevOps the idea/methodology, and Ops the role is important. I’ve been at desperately dysfunctional companies where we had a true throw it over the wall mentality. The operations team was miserable and the company suffered because we couldn’t effectively run the services we were responsible for.
Apparently, adrian cockcroft doesn’t use the term NoOps anymore, but I think it’s a useful term. It’s the idea of DevOps taken to its logical extreme. It doesn’t mean that developers are responsible for everything and you don’t have infrastructure engineers, but it does mean that you don’t have to have dedicated Ops people on the engineering teams.
I think the evolution of the title shows the change in responsibilities and expectations for people doing the role. I started my career as a Systems Administrator. We managed our servers using hand-crafted bash and Perl scripts. In 2000–2009 this was Ops. Over that timeframe, we moved from handcrafting our own tools to using tools built by other people like CFEngine, Puppet, and Chef. My title eventually changed to Systems Engineer and then to Production Engineer. I spent more time writing code to manage systems and less time managing individual systems and putting out fires.
Now I’m an SRE. Is the role completely different from when I was a Systems Administrator? Not really. I’m certainly better at writing software, but I also still spend time debugging network and operating system issues. SREs are engineers who understand a lot about how the low-level things work and enough of how the rest of the system operates. I like how Google put it in the preface to the SRE book.
…we see that if software engineering tends to focus on designing and building software systems, there must be another discipline that focuses on the whole lifecycle of software objects, from inception, through deployment and operation, refinement, and eventual peaceful decommissioning. This discipline uses — and needs to use — a wide range of skills, but has separate concerns from other kinds of engineers.
Now look, Google thinks they’re special, and they’re the only ones who thought of using software engineers to manage their production infrastructure. I think anyone who has worked at other tech companies would say that there has always been a spectrum between pure-ops focused teams and pure-dev teams. Every team I’ve worked on has had a combination of people with low level network and operating system debugging skills and people with stronger software coding skills.
I think your Venn Diagram is great, but I think SREs works on everything on there. Large companies might have teams that specialize in one thing or the other, but at a smaller company, that whole chart is done by 1 or 2 people, hopefully using some of the tools all the DevOpsy vendors are trying to sell us. Site Reliability Engineering at it best is about building the tools and infrastructure that allow great Software Engineers to do better work faster and with less risk.
That’s why I think it’s important that we push back against the idea that you can just rename Ops to DevOps. An effective company will have Infrastructure Engineers (call them Ops, SREs, IEs or Production Engineers) who work on the systems used to deploy, monitor, and maintain the code in production, and Product Engineers (Devs or SWEs) who primarily develop new features or modify existing ones. Both groups are super critical and have specialized sets of skills. I’d argue that as things get more complicated, we’ll specialize even further (and some of us already are).
What I know doesn’t work is the old-style “throw it over the wall” development. You cannot have Dev teams and Ops teams that don’t work together to build and run your applications, so when I say DevOps is a methodology and not a title, it’s important as much as because of what it is but also because it’s in contrast to what it is not.
Hacker Noon is how hackers start their afternoons. We’re a part of the @AMIfamily. We are now accepting submissions and happy to discuss advertising & sponsorship opportunities.
To learn more, read our about page, like/message us on Facebook, or simply, tweet/DM @HackerNoon.
If you enjoyed this story, we recommend reading our latest tech stories and trending tech stories. Until next time, don’t take the realities of the world for granted!