DevOps: A culture where people, regardless of title or background, work together to imagine, develop, deploy and operate a system.
Yeah, I know. The world needs another definition of DevOps like I need another (whatever). I heard the term DevOps Engineer one too many times in the past few days and felt like I needed a better way to explain what it is (and isn’t).
You can’t “do” DevOps.
… where people, regardless of title or background …
A lot of people think of DevOps as Developers and Operations. Thought of this way, the term DevOps leaves out of a bunch of groups involved in the process. Trying to add everyone involved to a single term is an exercise if futility, and would be silly even if it wasn’t. Nathan Harvey explained this quite well in his talk “Rugged Enterprise DevSecNetQAGovOps”. Video Here (Spoiler alert: If you mix Sugar, Flour, Cocoa, Salt, Baking Soda and a few other things together, you don’t get SugFloCocSalBak, you get a cake.)
A variety of backgrounds is every bit as important. This is why diversity (in all of its varieties) is so stressed at good DevOps events. If everyone has the same experiences and viewpoints, your chance of creating something with wide appeal is pretty darn low. To say nothing of the fact that it’s just the right thing to do.
All of this as a very long way to say it means the whole team.
… work together to imagine, develop, deploy …
There was a project at ThoughtWorks a little over ten years ago that spurred much of our work on Continuous Delivery. The team developed a Java application on Windows, and when it was “done” they deployed it onto Solaris. It didn’t work.
What if the people who really knew how to run the Solaris systems and would end up being responsible for the application for years to come had been on the team? Better yet, what if they were pairing with the people creating the code? Better even still, what if that whole team was responsible for the application for the rest of its life?
Dev: I’m gonna do it like this
Ops: If you do it that way it will blow up when we try to use NFS on Solaris
Dev: Oh, what if we did it this way?
Ops: That would work, but still could be flaky and result in us both getting paged at 3AM.
Dev: I don’t want to get paged at 3AM, what do you suggest? (slides over pairing keyboard)
Ops: Let’s do it this way.
Months of rework avoided.
Note our fictional alteration of history did not include the Ops person learning advanced Java. It also did not involve the Dev person getting certified on Solaris. It involved a team with a broader knowledge of how the system would be run. (Oh, and as a result the Dev person learned a bit about Solaris and the Ops person learned a bit about Java. Happiness.)
I’m sure you can think of similar interactions between all types of roles.
… and operate a system.
(Note: System is the word I’m least comfortable with in this whole thing. I couldn’t think of a better one sitting here in an airport, but feel free to let me know if you do.)
The key here was actually hinted at in the previous section. If the system goes down at 3AM, the team member on call gets paged. Not the person.
As Amazon CTO Werner Vogels says; “you build it, you run it”.
DevOps is definitely not a role.
A job title of “culture where people, regardless of title or background, work together to imagine, develop, deploy and operate a system engineer” would be pretty silly. I believe “DevOps Engineer” is just as bad.
Hire the skills you need to fill out your team. If you need help with automating the deployment of your system, feel free to hire an experienced release engineer, even if they don’t know dockerdockerdocker.