There has been a spate of articles published recently – triggered by discussions at the ’2nd DevOps State of the Union’ event – that have identified an apparent need to agree on a definition of DevOps. The folks at ScriptRock wrote a typically excellent piece on The Problem with Defining DevOps which is worth reading (including comments), and Steve Thair of the DevOpsGuys followed up with a very useful post about the need to adopt a different cognitive frame when thinking about DevOps.
Since 2012 I have helped people from perhaps 30 different organisations in Europe, India, and the UK to adopt, improve, understand, and/or experience DevOps (via client engagements and the Experience DevOps workshop, which I co-facilitate). Reflecting on the conversations I have had with people about their challenges and successes, I have come up with a useful working definition of DevOps that holds for all these organisations, without resorting to a vague “DevOps is… good” platitude:
Highly effective, daily collaboration between software developers and IT operations people to produce relevant, working systems
Here is why I think this definition works well.
Definition of DevOps
In order to build and operate the kinds of complex, distributed software systems required for 2014 and beyond, we need to emphasise effectiveness over efficiency for technical teams. Delivering changes rapidly, reliably, and repeatedly is not possible if we aim to minimize ‘costs’ at specific points of the value chain, as this kind of efficiency usually ends up causing unnecessary constraints. We instead should focus on flow and completion of work in progress: Change Request tickets should not sit in a queue for days; we should not separate ‘testing’ as something that happens only ‘after development’; and changes should not sit waiting weeks and weeks for the Staging or Pre-Production environment to be available.
Interaction between teams focussed on ‘new features’ (Dev) and teams focussed on ‘maintaining service’ (Ops) must be regular (at least daily) and built into the rhythm of work in the organisation, not just at certain project checkpoints (Inception, Service Transition, etc.).
Collaboration literally means ‘working together’ (co-labor-ation) – not the the idea of ‘occasional updates via Skype’ that some folks have. The ‘working together’ means ‘working together at the same keyboard and screen’ (co-lo or remotely via screen sharing). Dev and Ops people working at the same screen using the same tools is a crucial part of making a more effective delivery and operations practice; I have spoken about the collaborative value of tools for DevOps, most recently at DevOps Exchange meetup group.
Anyone whose primary focus on a given day is on enabling new features using code I count here as a software developer, whether they are working with applications or infrastructure. I also include testers in this group, as an understanding of code is increasingly important for effective testing in a DevOps and Continuous Delivery context.
and Operations people
Anyone whose primary focus on a given day is smooth, safe, effective running of the main Production or Live environment I count here as an Operations person. This means definition covers teams that are segregated (‘Dev’, ‘Ops’) and also teams where roles are shared or rotated.
We need to emphasise that the systems we build and run are produced by a combination of Development and Operations people. The old idea of ‘Dev producing’ and ‘Ops running’ systems is both unhelpful and inaccurate. Instead, we see ‘the system’ as including the teams and processes included in delivery and operations: metrics, monitoring data, operational improvements, RUM data, and other valuable feedback (think: Continual Service Improvement!) flowing from Production and Ops teams towards Dev teams.
The systems we (Dev + Ops) build must meet business needs and be useful for customers. This means we need strong engagement with Product Owners and others in ‘the business’ – together with metrics from Production – in order to be sure we are delivering what is really needed.
The systems we build must actually work effectively in Production, addressing operational concerns such as reliability, performance, diagnostics, traceability, etc. That is, the systems must have been built with operability in mind, including the IT Operations folk as customers.
The systems we build are a combination of written software, IT infrastructure, auxiliary systems such as monitoring, log aggregation, etc., and teams of humans: algorithms + silicon + wetware carbon.
Some organisations such as Netflix have very little separation between teams for ‘new features’ and teams for ‘maintaining live service’, but we can certainly say that Netflix has:
Highly effective, daily collaboration between ‘people focussed on new features’ and ‘people focused on live service’ to produce relevant working systems
Separate ‘Dev’ and ‘Ops’ teams is not a pre-requisite for DevOps! I characterised the Netflix DevOps ‘topology’ as ‘Fully Embedded’, but other DevOps team topologies exist and work in different contexts.