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 . I first heard it at the Velocity conference in 2009 during what I think is still the best introduction to the subject. DevOps 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 mentality. The operations team was miserable and the company suffered because we couldn’t effectively run the services we were responsible for. throw it over the wall Apparently, , 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 on the engineering teams. adrian cockcroft doesn’t use the term anymore NoOps Ops people 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 . 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. Ops 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 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. all the DevOpsy 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 but also because it’s in contrast to what . it is it is not is how hackers start their afternoons. We’re a part of the family. We are now and happy to opportunities. Hacker Noon @AMI accepting submissions discuss advertising & sponsorship To learn more, , , or simply, read our about page like/message us on Facebook tweet/DM @HackerNoon. If you enjoyed this story, we recommend reading our and . Until next time, don’t take the realities of the world for granted! latest tech stories trending tech stories
