DevOps is many things
Being at the top of the hype-cycle, there’s lots of stuff being written about DevOps versus various standards, frameworks and religions. Most of it isn’t really helpful because the author isn’t clear about what he or she means by “DevOps”. Is it a bird? Is it a plane? Well, yes – DevOps is many things, you just have to be clear about which part of DevOps you want to compare with ITIL®, IT4ITTM etc. So let’s disambiguate DevOps.
Many of the inaugural illuminati behind DevOps have been notoriously reluctant to define the beast, probably from a genuine concern that by defining it, they’d kill something that is still emerging1). On the other hand, those later-but-still-early adopters who do not intuitively feel what DevOps is, are really struggling to understand it and get value out of it. So there is a valid need to codify it, while at the same time not ossifying it.
Cultural norms, technical practices and architecture
Let’s take a look at definition by one of DevOps’ mover and shakers, Gene Kim. In an interview with Aprill Allen2), Gene defined DevOps as “the set of cultural norms and technical practices that enable organizations to have a fast flow of work from development through test and deployment, while preserving world-class reliability, availability, and security.” More recently, Gene added “architecture” to the set. So DevOps comprises cultural norms, technical practices and architecture. This is the first question to ask when somebody mentions DevOps: are you talking about cultural norms and/or technical practices and/or architecture?
Why is this relevant? Because, for instance, when we take a deeper look at cultural norms and technical practices, we see that they have differing scopes. Cultural norms3), such as respect, trust and a ‘no victims’ attitude, are applicable to all aspects of IT, business, or life in general for that matter. On the other hand, most of DevOps’ technical practices are more limited in their application. Technical practices can be grouped into practices that improve (1) flow, (2) feedback, (3) continual learning and experimentation, and (4) integrating information security, change management and compliance4). A minority of practices – such as for continual experimentation and learning – are applicable throughout the whole IT value stream and beyond. But most of the practices are related to specific IT value streams. Take the flow-related practices. Most of the practices in this domain seem to start with “continuous”:
- Continuous integration: frequently synchronize developer’s working copies with a shared mainline5)
- Continuous testing: automatically test to obtain immediate feedback on risks6)
- Continuous delivery: the ability to always put a product into production5)
- Continuous deployment: automatically deploy into production whenever product passes QA5)
We are still not there
But we’re not there yet. Even within a seemingly obvious term like “deployment” there is room for confusion, witness a lively discussion on Rob England’s IT Skeptic blog7). Traditionally, deployment has been associated with software: “a new release is deployed to the production environment.” What’s wrong with that? Well, nothing except that in a progressive DevOps setting, the new software has been live in the production environment long before users get to actually use it. Feature flags and user profile configurations are used to provide access. Some people refer to this ‘service request fulfilment’ as deployment as well, so when somebody says “deployment” it would be very helpful to state what is being deployed. Is it about application software deployment or application service deployment?
So if you want to debunk some of the nonsense that is being bandied about, drill down until you discover meaningful verbs and objects. The crisper and more countable the verb, the better the disambiguation.
- Mark Smalley http://allthingsitsm.com/kill-devops/
- Gene Kim http://knowledgebird.com/interview-gene-kim-devops/
- John Willis http://itrevolution.com/devops-culture-part-1/and http://itrevolution.com/devops-culture-part-2/
- Gene Kim, Jez Humble, Patrick Debois, and John Willis, The DevOps Handbook http://itrevolution.com/devops-handbook
- Various contributors http://stackoverflow.com/questions/28608015/continuous-integration-vs-continuous-delivery-vs-continuous-deployment
- Wikipedia http://en.wikipedia.org/wiki/Continuous_testing
A definition by one of DevOps’ mover and shakers, Gene Kim. In an interview with Aprill Allen2), Gene defined DevOps as “the set of cultural norms and technical practices that enable organizations to have a fast flow of work from development through test and deployment, while preserving world-class reliability, availability, and security.” More recently, Gene added “architecture” to the set. So DevOps comprises cultural norms, technical practices and architecture. This is the first question to ask when somebody mentions DevOps: are you talking about cultural norms and/or technical practices and/or architecture?