I was perusing through Twitter-land recently and ran across a tweet talking about a DevOps meetup in the Los Angeles area that was underway. And it went on to denote that the first opening question posed to the entire group was: What are the minimum requirements for DevOps? Huh?~!
My immediate reaction, however, was how absurd the question in of itself is. Not to disrespect the people participating in this roundtable, but the whole premise is wrong.
DevOps is not something you do, so how do you answer a question about minimum requirements?
This sort of conversation about DevOps continues to constantly flip itself on its head itself and become more ironic by the day. As a community, it is great that we all begin to assess for ourselves and our organizations the impact it has on the people, process and technology continuums. But we must constantly be mindful of the fact that you can’t download DevOps, you can’t buy DevOps and there is no silver bullet for DevOps.
Now being it that I wasn’t in the room, I fully recognize that I am making certain assumptions about this question. The intent of it could have been meant to ask:
Where do we start with DevOps?
Fair question and one that we hear all the time here at UpGuard. Most of us are realizing that it is ALL about the people. How we collaborate. How we learn. How we communicate with one another. Of course, there is a very important place in the equation for tools and technology too and as we always say…
Don’t automate what you don’t understand.
There is a tendency for organizations to dive into automation as the panacea for their DevOps envy, which can be a great kick in the ass for some large, entrenched Enterprises but also can lead to new tool silos emerging, skill gaps between key resources, and potentially slow things down rather than speed up the flow of delivering the next big thing. Now why would we want that?
Top 10 DevOps “Operational Requirements