Many of us have heard of DevOps but far fewer could define it. So just what is it?
According to Wikipedia, DevOps is "a portmanteau of 'development' and 'operations'" and is "a software development method that stresses communications, collaboration, integration, automation and measurement of cooperation between software developers and other IT professionals".
If that doesn't do it, try this: "One way to understand DevOps is through the acronym CAMS- Culture, Automation, Measurements and Sharing."
That comes courtesy of Patrick Debois, an independent IT consultant who has been one of the leaders in the field of DevOps from the start.
Still too complex for you? Some think that complexity is one of the most appealing features of DevOps for, as Debois pointed out at a seminar held last year, the most popular T-shirt at the event said simply: "Keep DevOps Weird".
There is always a certain mystery around concepts that are difficult to understand, whether that difficulty comes from their complexity or from the simple fact that its users like it that way. But the complexity really only comes from the fact that DevOps is two concepts run into each other.
Software development is well understood by the enormous community of developers and their professional colleagues - it is all about code. Writing code, implementing code, testing code, re-writing code, hair loss from the stress of coding, and so-forth.
Operations is all about looking after the systems that run that code. It is the operations staff who work out how much processing power the software will need to run, how to make the software secure, how to make it run efficiently, and how to keep it running.
The issues start to arise because those two groups of people look after the same systems but otherwise exist in two relatively separate worlds. The way developers tend to look at it, they are the ones who create the software which the operations staff then go on to break. And then they shout at each other.
Perhaps that is an exaggeration but I suspect it is a situation that many people will recognise.
Now, introduce DevOps into that mix and those two communities have to learn how to work in a new way, one where they cooperate with each other fully and whole-heartedly for the good of the organisation.
There are almost as many definitions of DevOps as practitioners. The Agile Admin (TAA) website, run by a team of developers who look at DevOps as academics would, describe it as "the practice of operations and development engineers participating together, over the entire service lifecycle [of systems], from design through the development process to production support".
They then add an important corollary and point out that this is a major change from previous methods.
DevOps is also characterized by operations staff making use of many of the same techniques as developers for their systems work. The idea is that instead of avoiding each other in the workplace, operations and development people should learn to work together in mutual cooperation.
In some respects, none of this is exactly new. As Opensource.com pointed out recently, DevOpps is a replacement and continuation of agile, which is "a group of software development methods in which requirements and solutions evolved through collaboration between self-organizing, cross-functional teams". The Agile Manifesto set this out in full in 2001.
This all stems from the belief that the code is not enough. The code is only completed when it has been fully tested and is operating in production as designed. The Agile Manifesto is quick to point out that agile is not a prerequisite for adopting DevOps "but a good starting point".
So if DevOps doesn't replace anything, why consider it?
The answer, as the manifesto points out, is that DevOps may not be a replacement for everything or anything but in fact is a useful adjunct to many IT areas. For example while some see DevOps as a backlash to ITIL (the IT Infrastructure Library) or ITSM (IT Service Management), DevOps and ITIL are compatible, says Opensource.
ITIL and ITSM "remain the best codifications of the processes that underpin IT Operations, and actually describe many of the capabilities needed in order for IT Operations to support a DevOps-style work stream".
And while DevOps has been seen by some as NoOps - a backdoor method for removing the whole IT operation, it will often put more responsibility on development to manage code deployments and maintain service levels.
Where should I go next?
Although DevOps is a relatively new field, it has been around long enough to develop its own library of source material for those who want to learn more. A good place to start would be Paul Swartout's brief but authoritative book, Continuous delivery and DevOps: A quick start guide.
If there is one organisation that sums up DevOps, it would be Amazon Web Services (AWS), which has DevOps in its DNA. Not surprisingly AWS has its own guide to DevOps which starts here.
Puppet Labs, which along with Chef Software is a leader in the DevOps community, points to the Liverpool Victoria building society as a case study in how the methodology can help organisations. Before using Puppet software, the database administration teams that manage Oracle installations "were receiving builds they couldn't use as-is, so they had to modify them [but] once Puppet Enterprise was brought in [they found] they could move more quickly, and simply add on modules as needed".
In another example, the makers of research and analysis tool Splunk used Chef to automate "everything from basic configuration to continuous integration of application updates in the Amazon EC2 infrastructure supporting Splunk Storm", according to the companies.
With Chef, Splunk created a pipeline in which each stage of the development process was automated and integrated, "accelerating time-to-market and increasing business agility", the companies said.
If you work in IT, whether as a developer, systems analyst, programmer, engineer, database admin, or security expert, at some point you will need to know about DevOps.