Devops – Part 1: Devops, a European thing?
Devops, Devops, Devops, … the whole world is talking about Devops, but what is Devops ?
I have a slide deck where I tell people that a Devop is a 30 something Senior Infrastructure guy with a strong Development background, a lot of Open Source Experience, who is mostly European (.be / .uk) who likes Belgian Beer and Sushi. Of course that is an absolutely correct description the people involved in the early days of the Devops movement, but it has nothing to do with what Devops really is about. It’s just a fact that the first Devopsdays conference was held in late 2009 in Gent, and a lot of the people involved in the early days were these Senior Infrastructure guys.
But devops started out much earlier than this, but we’ll never know when it started because it’s nothing new, it’s just a new common name for things people have been already doing for ages. Devopsdays Europe started because a group of people met over and over again at different conferences throughout the world. These people were talking about software delivery, deployment, build, scale, clustering , management, failure, monitoring and all the important things one needs to think about when running a modern web operation. These people included Patrick Debois, Julian Simpson, Gildas Le Nadan, Jezz Humble, Chris Read, Matt Rechenburg , John Willis, Lindsay Holmswood and Kris Buytaert. On the other side of the ocean O’Reilly put on a conference that sounded interesting to a bunch of us Europeans : Velocity, but on this side of the ocean we had to resort to the Open Source , Unix, and Agile conferences. We didn’t really have a meeting ground yet. At CloudCamp Antwerp, in the Antwerp zoo, Patrick Debois decided to organise Devopsdays Gent.
Devopsdays Gent was not your traditional conference, it was a mix between a couple of formal presentations in the morning and open spaces in the afternoon. And those open spaces were where people got most value. The opportunity to talk to people with the same complex problems, with actual experience in solving them, with stories both about success and failure. How do you deal with that oldskool system admin that doesn’t understand what configuration management can bring him? How do you do Kanban for operations while the developers are working in 2 week sprints? What tools do you use to monitor a highly volatile and expanding infrastructure ?
Yet I still haven’t defined devops! :) So .. what is devops ? Lets start off with agreeing that we haven’t agreed on a real definition yet, and never will, but there is a lot of common ground that defines the ideas behind it. The idea that there needs to be more communication between the different stakeholders in an IT lifecycle – developers, operation people, network engineers, security engineers – need to be involved as soon as possible in the project in order to facilitate each other and talk about solving potential pitfalls ages before the application steps into production. Some people therefore say that devops is the wrong terminology and that it needs to be *ops, but if you say that out loud it becomes starops, which might lead to the confusion that it’s about rockstars in operations, which is not really the goal we’re trying to achieve, we’re trying to build teams that work together cross discipline with a joined goal.
Lots of people also think the devops ideal includes continuous delivery. The idea that you should be able to deploy multiple times a day, that automation will help you make such deployments possible and not problematic, not that it’s about being able to, but about having to. Obviously a full chain of automation from development to production helps here, adequate testing needs to be in place on all levels – functionality, scalability, availability, security.
Also the idea that the involvement of developers doesn’t end at their last commit, so that operations just pulls in the code and makes it run, but that they are also involved in keeping it running smooth. After all software with no users has no value. The involvement of the developers in the ongoing operations of their software shouldn’t end before the last end user stops using their applications. This also means that software developers need to provide the nessecary hooks in their application so we can automate testing, and measuring different components of the application both during test and during operation.
Summarizing this in an acronym coined by John Willis and Damon Edwards – CAMS. CAMS says devops is about Culture, Automation, Measurement and Sharing, but its definitely not a SCAM.
Nice post. Not a practitioner, I usually reserve comments out of respect for the amazing folks in this community who are and are contributors and thought leaders in it.
I love how DevOps gets defined in its lack of definition and yet everybody who’s clued in “gets it”. I guess we need the evolution of meaning.
As a one-time developer who remembers when that also often meant being “Ops” too — at NASA, as a member of a team of 3 on the STS ascent, orbit and decent simulation system, I also got to be on pager for support of the very rarified community of users who modeled shuttle missions and later as a developer of LAN-based products for use in clinical settings, I was usually second-tier support for customer calls — I think the “collaboration” inherent in the “culture” and “sharing” themes strike me the strongest.
That said, DevOps very much seems to me to be about returning to some important parts of the system back in the day when Dev and Ops were much the same team, if not the same person. With the massive complexity of the modern stack, much less the modern app, it will never be able to be the same person again but that spirit of collaboration must return for the good of the business, the objective of the exercise, and the mental well-being of all us involved.