Why another comparison
I enjoy talking to technologists, and other IT professionals about the state of DevOps and what implications it might have for the future. Often however during our conversation I will hear something to this effect:
There are just so many definitions for what DevOps is. It just doesn’t have a fixed definition of any kind.
As the DevOps movement is important to me I’d like to take a moment to help define what DevOps is, if not so much for others, but for myself.
From my reading and research DevOps has a broad but well defined definition with very specific and wide ranging implications on best practices for the life cycle of a project - development , deployment, and operation management. There are several pioneers and I won’t name them all but I’ll name the ones that have personally profoundly affected my thinking on the subject Martin Fowler, Jez Humble, and Gene Kim, and well there are many more but those are the ones that first blew my mind. A good working definition is through the mnemonic device:
- C - a group culture
- A - using automation to remove unnecessary work
- L - applying Lean development practices to the entire project, infrastructure included
- M - a strong use of measurement or metrics in the decision making process
- S - Sharing among historical silos: Dev. and Ops. as primary examples
A few good websites that quickly tl;dr’s DevOps are New Relic’s page on the DevOps lifecyle and AppDynamics definition of DevOps through the above acronym, CALMS, or to write it in the negative used by THHGTTG “Don’t Panic”.
So it’s not a title
DevOps isn’t a title. A company can certainly have DevOps ambassadors however isolating a DevOps team is antithetical to the entire notion of what DevOps is. That is if nothing else an alternative poor mans approach to determine what DevOps is, is by understanding what it isn’t. Really quite fine web pages concerning the nature of DevOps as an outlook as opposed to a division are Pete Cheslock’s blog article DevOps in Your Job Title Is Doing You Harm and Jez Humble’s
So I don’t care what you call me as long as …
That is there are implications when I claim on LinkedIn that I’m a “DevOps advocate”. The first is that I don’t need to have DevOps in the title to be part of a DevOps community. Linux administration as part of the IT workforce is just as much a part of the DevOps movement as the title DevOps engineer. In principal it’s about how the company and its IT workers function. Secondly nothing is perfect, and most companies who see the DevOps light are incrementally designing their work flow to be more in line with a DevOps paradigm, and the simple reason for this is that it works. I aim to be of use in knowing how to properly use technology, but in a manner that will positively affect the dev-ops (-business-client) work flow, which includes stability, high availability, scalability etc. in relation to infrastructure and the part I play in the whole.