Hello and welcome to the second of our 3 part series exploring the wonderful and innovative world of software subcultures. Even us geeky IT kids can get a little radical from time to time, and it’s a pretty good job that we do, too. In fact, much like the hippie subculture that gave rise to the popularity of The Beatles, who subsequently managed to change the face of pop and rock music forever, so too have some of software’s most influential figures started off by going against the grain, and yet have wound up being the genesis of some of the most important movements of our time. This series will explore 3 such movements – Microservices, DevOps and Agile – and will serve as introductions to a mini-series of eBooks which we are due to publish very soon. This week it’s DevOps. We hope you enjoy the series.

What Is DevOps?

Although the term sounds like military lingo – as if “DevOps” was the codename for some covert mission circa ’91 Dessert Storm – the word actually derives from the much tamer world of software development. A clipped compound of “development” and “operations”, DevOps is a term that describes a somewhat disparate group of concepts, which have nonetheless catalysed to form a single method of developing software.

Sound confusing? Good. It is confusing, and in fact what is meant when we say ‘DevOps’ is rather broad, nuanced, and, like many new terms, rather controversial with its very own army of detractors determined to see it squashed.

DevOps describes a sort of cross-pollination between three previously separate elements of the software building process – development, operations and QA (quality assurance).

It comes out of a collision between two related trends in the development field – Agile operations, and collaborative (between development and operations) processes.

Let’s take a look at a definition offered by Stephen Nelson-Smith of jedi.be:

“The DevOps movement is characterized by people with a multidisciplinary skill set – people who are comfortable with infrastructure and configuration, but also happy to roll up their sleeves, write tests, debug, and ship features. These are people who [are] making connections, because they can – because they have feet in multiple camps, they can be ambassadors, peace makers, facilitators and communicators. And the point of the movement is to identify these, currently rare, people and encourage them, compare ideas, and start to identify, train, recruit and popularize this way of doing IT.” 

Indeed, DevOps is a culture. It’s not a set of guidelines, rules or transcripts that absolutely determine the precise ways that development should be done. However, perhaps a little paradoxically, DevOps is about right and wrong, good and bad. Put simply, DevOps is software delivery done properly.

Granted, that’s more than a little woolly in terms of actionable and applicable processes. But that’s ok. In truth, DevOps means a lot of different things to a lot of different people. And the simple reason for this is because the topic is actually rather broad and covers a huge amount of ground.

So perhaps the first question should be where does DevOps come from? Let’s start there.

A Brief History Of DevOps

Wikipedia reveals the origin of the term most succinctly, and so I won’t summarise. The paragraph in full:

“At the Agile 2008 conference, Andrew Clay Shafer and Patrick Debois discussed ‘Agile Infrastructure’, afterwards creating the Agile System Administrators Group on Google. The term ‘DevOps’ was popularized through a series of ‘DevOps Days’ starting in 2009 in Belgium. Since then, there have been DevOps Days conferences held in many countries worldwide.”

It’s quite astounding, to my mind at least, that the term is actually already six years old, despite only finding its way into regular usage only relatively recently. Indeed, DevOps as a term has done the rounds, and has picked up many additional meanings along the way. But what I actually find most interesting is the misconception within the tech sphere yet outside of software circles that DevOps is something that’s normally associated with the small startup.

This, frankly, isn’t the case – albeit that, by necessity, startups have been doing a DevOps thing for years. Because of their limited size, team members within a startup often find it much easier to communicate with one another, learn from one another, and, over time, skill sets and responsibilities very often begin to overlap. Now, even so, this still doesn’t quite get to the true crux of the DevOps movement, but it’s nonetheless been there, simmering underneath the processes and procedures of many small startup companies for many years.

The popularity of the movement, and indeed the term, however, actually comes from the giants of the tech sphere. Google, Amazon, Netflix and the like. By necessity, these companies push out an awful lot of code every single day. In fact they do it right around the clock in multiple code pushes. Naturally, with so much code, there’s almost bound to be a few bugs in there somewhere. And that’s where a closer collaboration with operations – i.e. DevOps – has been borne. Developer tools like Puppet and Chef can help systems administrators automate a lot of this and address some of the most difficult infrastructure challenges.

DevOps brings in monitoring and other sorts of tools to immediately diagnose what the problems are.

Beyond Skills

When we drill down even further into the methodology of the DevOps movement, we actually come to realise that the concept goes much further than a multi-disciplinary approach. In fact, the DevOps methodology focuses on communication as much as it does anything else. It might seem like a rather ‘kindergarten’ concept, but communication really is one of the biggest keys to unlocking success – and the DevOps movement acknowledges this, reiterates it, and puts it firmly into practice.

DevOps focuses on the improvement of communication skills, not just throughout the team, but with the target business for which the software is being developed. It encourages a sensitivity and passion for this underlying business, adopting the attitude that it is the business that must succeed at all costs, and thusly opening up communication pathways between client and developers to ensure this.

Building quality software is not easy. In fact it is perilously difficult, as I’m sure I don’t need to tell you. Over the past decade or so, developers have really started to pay attention to this, and, as a result, we have seen things like the Agile movement come into fruition – and indeed you will not be surprised to learn that DevOps is actually an extension of Agile, as The Agile Admin explains:

“DevOps has strong affinities with Agile and Lean approaches. The old view of operations tended towards the ‘Dev’ side being the ‘makers’ and the ‘Ops’ side being the ‘people that deal with the creation after its birth’ – the realization of the harm that has been done in the industry of those two being treated as siloed concerns is the core driver behind DevOps. In this way, DevOps can be implemented as an outgrowth of Agile – agile software development prescribes close collaboration of customers, product management, developers, and (sometimes) QA to fill in the gaps and rapidly iterate towards a better product – DevOps says ‘yes, but service delivery and how the app and systems interact are a fundamental part of the value proposition to the client as well, and so the product team needs to include those concerns as a top level item.’ From this perspective, DevOps is simply extending Agile principles beyond the boundaries of ‘the code’ to the entire delivered service.”

The Dev House Problems That DevOps Solve

The world of software development – just like any other field or discipline – faces daily problems. Problems of resources, consumer demand, lack of talent and sometimes even innovation. But, all this aside, there’s one other thing that pretty much overarches the whole lot – a lack of communications and proactive structure to processes.

I’m not the only one who thinks this. Stephen Nelson-Smith was lamenting much the same in a post for Just Enough Developed Infrastructure (JEDI) last year:

“Let’s face it – where we are right now sucks. In the IT industry, or perhaps to be more specific, in the software industry, particularly in the web-enabled sphere, there’s a tacit assumption that projects will run late, and when they’re delivered (if they’re ever delivered), they will underperform, and not deliver well against investment. It’s a wonder any of us have a job at all!”

Quite. Software, as I’ve said, is not an easy thing to develop. Clients have very specific hopes and dreams for their projects and all we’ve got are fiercely complicated languages that we rather coolly call “code” in order to make ourselves sound clever, but in reality it’s often as baffling to us why something doesn’t (or does!) work as much as anyone else.

So, DevOps is a culture, first and foremost. Look out for our upcoming eBook where we really delve deep into the concept and the subculture, and discover a much more about what DevOps really is, what it isn’t, and get our teeth into some of the controversy that surrounds the concept and the movement.