The other day, at the bottom of an email, in the middle of an entirely unrelated string of communications, the person I was conversing with asked, “By the way… What does DevOps mean to you?”
The response I gave was, essentially, a spur-of-the-moment blog post. Here it is:
To me, DevOps is a label that describes a situation where there are no walls, no gates, no transitions, and no ceremony between Development and Operations. They are seamlessly integrated (when viewed from “above”) into a single, value delivering, IT entity. From within, there may be individuals who specialize on “one side or the other,” but even those individuals interface seamlessly and directly without the need for an intermediary. Most importantly (in my humble opinion) DevOps means that everyone—from Jr Analyst, to Mid Dev, to Sr. Test, to Director of IT—is equally responsible and accountable for the product from inception through retirement, meaning the Devs are just as likely to be maintaining the system in Prod as the Sys Admins are, to be doing configuration testing in the Dev Environment.
In reality, very few people or organizations can even imagine something this seamless. So in practice, DevOps tends to be a much more siloed, linear process:
- The Dev team does their thing, then promotes it to ‘the servers/cloud’ when it’s time to go live. – And because the Devs do the promotion to production, magically they are now “DevOps”
- THEN the support team takes care of it – This is probably the team that did the promotion to production & support yesterday, but since promotion went to the Devs, these folks aren’t Ops anymore.
To me, this is the same “dumb” (again, in my humble opinion) process mislabeled as DevOps because all they’ve really done is move a task from one group to another.
Why it’s important to define your terms
Because of this common misunderstanding, I don’t generally talk about “DevOps” without first defining the term unless I’m with people I know agree with my vision of it. And sometimes I use a much more wordy but sure-to-get-my-point-across phrase in place of DevOps, which is “Continuously Integrated, Tested & Delivered Agile DevOps in the Cloud” or simply “Agile, Cloudy DevOps.” I find these made up phrases to be both more descriptive and, funny enough, that more techies understand what I’m referring to than when I just say DevOps.
What we can learn from Agile, Cloudy DevOps
Most definitions from a tech site or Wikipedia or wherever are “ok” in so far as they go. However, pick a company that claims to practice DevOps and I’ll give you 50/50 odds on whether or not they do something congruent with one of those definitions (and of those who do, under 50% of those do it well). Outside of safety critical and/or seriously regulated environments, I find that both the very best and the very worst teams I have ever encountered in terms of delivering value to their business/customers qualify as “Agile, Cloudy DevOps.”
Personally, I really like working in “Agile, Cloudy DevOps” environments. It’s a culture that fits my personality and my natural work style. And make no mistake, it is at least as much about culture as it is about precise definitions. “Agile, Cloudy DevOps” will only be successful with a strong core of experienced people who want to work together, coupled with an entire team who trust one another, agree on vision and refuse to allow one another to fail. If your team is inexperienced, has trust issues, competency issues, management issues, (or more or less any issues), going “all-in” on “Agile, Cloudy DevOps” is a serious mistake.
However, you don’t need to go “all-in” on “Agile, Cloudy DevOps” to get a lot of value from its concepts and practices. Cherry-picking the ones that best fit your team and your scheme of producing, delivering and supporting software/apps can greatly benefit any “DevOps” company.
What do you think of this method of describing DevOps? Do you agree, or think anything is missing? What does DevOps mean to you? Let us know in the comments.