I'm new to Dev.to, and will probably post about DevOps, so thought it was important to share what I mean by the phrase
DevOps: A culture where people, regardless of title or background, work together to imagine, develop, deploy and operate a system.
The term DevOps is more than 10 years old now, but if you ask 10 people for a definition of the term you'll get at least that many answers. I wrote my definition a few years ago so that people would know what I mean when I use the term in talks and writings.
A culture
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 in futility, and would be silly even if it wasn’t. Nathan Harvey explained this quite well in his talk “Rugged Enterprise DevSecNetQAGovOps”. (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.)
It’s about developing and operating a system. They are verbs.
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 around 2006 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.
Lots 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.
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, a team member on call gets paged. Not the person.
As Amazon CTO Werner Vogels says; “you build it, you run it”.
Platforms play an important part
It’s important to note that with the definition (and the evolution of my understanding of DevOps since originally writing this) I don’t mean to imply that the team creating the system is the only one who controls any part of their infrastructure.
I’m a huge fan of making a platform available to the organization. A proper platform can enable teams to be self reliant while also ensuring important factors such as security and compliance are accounted for.
I was planning on adding another post describing what I mean when I say platform, but my ThoughtWorks colleague Evan Bottcher has already done a much better job than I would on Martin Fowler’s site at https://martinfowler.com/articles/talk-about-platforms.html.
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, not catchy titles.
Top comments (0)