The Five Cs of DevOps at Scale

Source – gigaom.com

DevOps advocates will no doubt be familiar with the term “Wall of Confusion”, as it goes to the heart of why the best practices arose. As a recap on what DevOps is about, it offers a solution to a familiar challenge: if you are looking to develop and deliver new software applications and services as quickly as possible, how do you address the fact that operations practices are not always aligned with those of development? As I wrote last week, it’s a laudable goal, for sure.

However, it can be difficult to deliver DevOps beyond the initiative or single-group level, despite the very best intentions of those involved. I can think of two recent scenarios. In the first, a large city institution, those driving DevOps practices saw initial success but then found their sage words and high energy levels being sapped as attempts to engage the broader community of internal developers met with apathy. And in the second, a DevOps-based part of a consumer-facing organisation was being ramped down as it was out of kilter with the practices of other areas, undermining its ability to deliver.

Naturally, I’ve been racking my brains as to why this should be. As a starter for ten, I believe it is down to several elements, each of which is necessary for DevOps to scale beyond the level of an isolated group. Take any away and the effect is to dilute its potential value, and therefore calling into question the point of doing it at all. By some handy coincidence, these all happen to start with ‘C’:

Commodity

DevOps works best in an environment where the infrastructure building blocks are relatively uniform. A recent conversation with Pivotal’s Michael Coté circled around the topic that cloud-native developers didn’t have to, or indeed have any desire to tinker with the containers, operating systems, virtual machines or other elements of the stack upon which they built. Whether or not they are missing out is moot: the result is a lot less complexity.

Consistency

There’s another very human factor involved in DevOps success. A well known fact is that frequent (I hesitate before I use the word ‘continuous’) deliveries of software requires a significant amount of discipline: I would proffer that high levels of discipline are the exception, not the norm in the human psyche. For someone who is disciplined, the possibility that everyone else may not be able to be so may be difficult to accept.

Collaboration

DevOps is a highly collaborative, even sociable approach to doing things. If yours is an environment where social interaction is a norm, you might find it hard to imagine how anyone would want to work differently. While collaboration tools may be deployed, collaboration itself is not something that will, or indeed can, just happen in an environment where it does not already factor. Its absence inevitably slows things down, potential also increasing project risk

Continuity

We also have to account for the dynamics of the environment. Whether they are called sprints, timeboxes or whatever, DevOps requires repeated and controlled cycles, each measured in less than a month: when one has finished, the next is about to start. Working at this frequency is a massive challenge for many organisations: if yours is the kind of place which sees “let’s fix a meeting… when can everyone make it? OK, three weeks’ time” as a norm, then DevOps will inevitably falter.

Charisma

Finally, and like it or not, DevOps is as much a community as it is a practice. Its leaders are the kinds of people that others want to be like, whose easy-going zeal can cut through the fog and make sense of it all. As I wrote in the guru’s dilemma however, once the mentor or consultant has left the site, the organisation will be left to its own devices. And, over time, may find itself reverting to type.

So, why do these factors make things so much harder? The answer is that they impact our ability to respond to change in an already complex environment. Anything we develop has a best-before date, from the moment of decision to the moment where we our creation starts delivering value. Software development is forever living on borrowed time, with the imminent risk of being overtaken. Any friction in the process can mean that the result arrives after it would have been useful, to the detriment of many well-intended projects.