The Five Cs of DevOps at Scale
By Jon Collins
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’:
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.
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.
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
We also have to account for the dynamics of the environment. Whether they are called sprints, timeboxes or whatever, DevOps requires repeated and controlled …read more
Read more here:: gigaom.com