Gareth Rushgrove is known by many people as the creator and editor of the popular DevOps Weekly email newsletter, and he spent several years working for the U.K. Government Digital Service (GDS) on GOV.UK and other projects. As Senior Software Engineer at Puppet, you can find him building some of the latest infrastructure automation products when he isn’t speaking at events on a wide variety of DevOps and related topics.
Linux.com: Why are so many organizations embracing DevOps?
Gareth Rushgrove: it really does vary. Sometimes it’s a matter of individual teams adopting new practices to get things done. Sometimes it’s a strategic initiative from IT management. Often it’s both at the same time meeting in the middle. At this point the data and the success stories, for instance from the DevOps Report, make it clear that not doing so puts you at a disadvantage, both for hiring skilled developer and operations professionals, and from a competitive standpoint regardless of what your organization does.
Linux.com: Why are individuals interested in participating?
Gareth: It’s becoming clearer to everyone that there are better ways of running complex systems, and that the impact of engaged employees plays a big part in that. DevOps as a movement has been very practitioner driven, so many of the conversations center around improving the quality of life for individual developers and operators – whether that’s talk of alert fatigue, burnout, or improving monitoring to make visibility of the running system a first class concern. Individuals get involved because it can make their jobs more impactful, but also because it humanizes operations as a craft.
Linux.com: What’s the primary advantage of DevOps?
Gareth: I don’t think a single advantage exists. DevOps has always been a banner under which many different practices co-exist. It’s not a framework or prescriptive approach to a single problem. The reality is different types of organizations, and different sizes of organizations, benefit from different practices. It’s all about context. Most organizations are under pressure to get software out to users more quickly and can benefit from reducing the cost of keeping the lights on. But you might also simply be trying to get more out of your existing IT estate, staff and budget, or trying to hire and retain qualified staff in a competitive market. You can’t really ‘do’ DevOps, but you can embrace various associated practices depending on particular problems your organization is trying to solve.
Linux.com: What is the overwhelming hurdle?
Gareth: It’s easy to say the main hurdle many organizations face is finding people. And it’s true the market for people with experience of being involved in a DevOps transformation is hot at the moment. But lots of organizations already have great people, but the processes and constraints they operate within pose the problem. DevOps can provide the impetus to break down old silos and adopt more effective ways of working. The formal literature is starting to catch up too – Effective DevOps from O’Reilly, The Puppet State of DevOps Report and the upcoming DevOps Handbook from Gene Kim et al. provide a really good introduction.
Linux.com: What advice would you give to people who want to get started in DevOps?
Gareth: If you can, head to a Devopsdays event. These are local conferences that attract people like you, who are interested in what better operations looks like. Listen to the speakers, ask lots of questions and have lots of conversations. Then take that back and apply it to your organization’s problems. Realize that DevOps is an area where you’ll often feel out of your comfort zone on either the technical content or the human factors side, but that’s what makes it interesting. Try and lean towards the topics you find more uncomfortable; if you’re generally regarded as a bit of a geek then explore the people side, if you’re in a management position explore the technical topics. It’s not that you can ignore one side or the other, but that successfully adopting DevOps practices is a classic sociotechnical systems problem – you need equal measures of technical know-how as well as empathy for other practitioners to get the best results.