DevOps is one of the most mis-used terms I hear today. It is used in the wrong context so many times that I suspect that by next year it’s definition will cement in a common understanding that is yet to form (and different to how we now perceive it). To prepare for this; I will lay out what I think it should be.
Wikipedia’s definition says it best (simplified by me):
DevOps is a methodology that stresses communication, collaboration and integration between software developers and operational IT professionals.
Where the definition gets interesting is in it’s application. The division between development and operational practices in the IT industry is now polarising enough to create conflicts. This is a change that has increased by degrees over the last decade. People with an engineering mindset tend to assume the role of an operational engineer or a developer and neither camp does not like to cross into the other’s territory. Instead, they sit on their side of the fence flinging poo like naughty monkeys. A minuscule number of people exists that like to do both. But like other minorities, they tend to get shunted most of the time and then overly “needed” when required. The end effect is they tend to have poo falling on them from both directions.
This leads us to two perspectives of looking at the DevOps role. From a development perspective and the operational perspective. The most important characteristic for a DevOps engineer is someone who has equal empathy for developers and operational roles. The word empathy is quite deliberately chosen. To truly empathise with someone, you must fully understand their suffering. In this case, by understanding where a developer or operational person suffers the most; one then knows what technical issues need to be resolved. Empathy also drives the desire to bridge communication gaps (and also provides a mechanism to do so).
When I look for people who would be suitable DevOps candidates, I’m searching for an interest in both fields plus a keen motivation towards diagnostics. A good sign that a person is up to the task of being a DevOps engineer is that they can easily/happily be swapped into either role.
The development team is (typically) tasked with building an application that meets a bunch of requirements harvested from end-users. Some projects have non-functional requirements (i.e. requirements that have come from operational teams), but these are usually poorly communicated and hence their intention is never understood. Hence, non-functionals are usually prioritised till the end of the project and implemented on an “as required” basis. This model fails when important, low-level changes are required like logging, security or monitoring features.
When involved in a development project, a DevOps engineer will be working with the architects, designers and developers to make sure that the application will work well in it’s target environment in a way that can be supported by the operational teams. The simplest example of the value a DevOps engineer will add to a development project is to add context to log messages so that the operational person reading those messages can understand what the exact problem is (rather than the typical “an error has occurred”). A more complex example is tailoring the threading/locking semantics of the application to support the hardware environment and clustering “quirks”.
An operational team is primarily concerned with keeping the lights on. That is; maximum uptime and maintained sufficiently so that unexpected downtime risk is reduced. Operational teams are typically punished when downtime occurs. An unpredictable, unstable or time-consuming application is an operational person’s worst nightmare. Any application that takes time and effort (in an operational sense) to keep alive detracts from managed planning and pro-active maintenance. This reduction in forward planning costs a business in many ways:
I find it soul-destroying to witness an operational team in 100% reactionary mode. After working like this for a while, the people who are left tend to work in a “don’t give a shit” mode. Outwardly, this changes the perception of the team from a useful tool for the business to a “chorus of no”. When this happens, the natural reaction from the rest of the business is to find ways to bypass this team. The end effect here is a downward spiral where the operational team lacks relevance to the business and is less interested in the business (and vice-versa).
Typically, the definition confusion is based around the assumption that DevOps is part of an agile or lean process and therefore present to support rapid delivery. Whilst this is a valid observation, it does not describe DevOps to it’s full extent.
DevOps is a fantastic fit with agile/scrum projects as it enhances each iteration’s ability to operate in an operational sense. This is in contrast to worrying about operational concerns at the end of a project (hence, turning an agile process into waterfall due to the big “dump” at the end).
In fairness, the DevOps movement owes a lot to Agile. Agile projects quickly identify the need for DevOps and also provide the flexibility to start delivering resolutions to DevOps concerns. This has lifted DevOps from being an abstract concept that is rarely talked about to being a term used in almost every project delivery team.
There is my perception of DevOps. This comes from decades of performing this kind of role under various different guises. I am now over the moon that we now have a word for it. At least now that it is a recognised term it can now surface and be formally recognised.
Feel free to add any comments or thoughts below.