What is DevOps?

Enterprise IT has been taken by storm by DevOps as both a buzzword and a movement. In this post I’m going to attempt the impossible – describe what DevOps is and isn’t, why it is so popular and what is the core value that is likely to remain once the hype train has left the station.

DevOps at its heart is about aligning development and operations teams, and in expanded variants anyone who is a stakeholder in the delivery of IT, to ensure they are working optimally together. When put like that it really seems like a no-brainer and it is surprising (and somewhat disappointing) that it has taken us this long to finally come to this conclusion.

Err… Are you sure? I’ve heard other definitions, what else is DevOps?

DevOps is also about:

Enabling the delivery of software at high-velocity. While you don’t need velocity to get benefits out of DevOps, it’s often a core driver
Taking advantages in tooling advantages, particularly in CI/CD and Operational tooling (more on this later)
Fixing processes which have in many instances been left to rot or have stuck too close to the ITIL bible
Selling stuff under a new and shiny banner
A massive cultural shift to behaving in a more start-up like fashion where everyone focuses on adding value
A collision Lean, Systems Thinking, Agile and various other borrowed philosophies applied to the domain of high-velocity software delivery

Why do we need DevOps?

When your IT Department is small, Dev and Ops may be one team (or even one person). In these instances, you tend to be operating in a DevOps like fashion already. As the department grows, it is natural to fit people into specialised groups based on their job function. Unfortunately, human nature being what it is this tends to create “us-and-them” cultures where dev care about delivering features and operations care about system stability. Because change itself, without careful controls, tends to decrease stability this puts the two groups at loggerheads creating frustration, low morale, poor efficiency and poor outcomes. DevOps provides a blueprint for how you can both go fast and be stable.

Doesn’t change always make systems unstable?

Jez Humble and team have actually done some incredible research on this point. If you doubt that you can both go fast and be stable, I encourage you to dive into their work. The summary of their research is that implementing DevOps well leads to lower MTTR and faster change. In fact, you need both to be successful. You can read more of their research at devops-research.com: https://devops-research.com/research.html.

The reason for this is that DevOps is essentially about de-risking delivery as early as possible through a combination of processes, people (culture) and automated tooling.

A few notes of caution here. In a large Enterprise IT environment, systems are often tightly coupled and interdependent. This makes a move to DevOps more complex as you need to consider knock-on effects of change. In practice, it may not be possible for you to easily decouple these Enterprise releases and automated testing may need to make compromises. Your architecture may have been designed assuming big bang changes and it may be that because systems are not composed into logical services, they are difficult to test in isolation.

Should everything be DevOps?

It’s worth going right back and understanding why those silo’s and walls were originally created and being critical of your own reason for exploring DevOps. Is there a strong business driver to deliver change faster? Is what we are doing now inefficient or causing low morale? Change for changes sake rarely ends well and you must be clear on why you are changing.

Some corporate cultures are addicted to the drama and battles that come with dev vs ops wars. It may be that politically, the organisation is just not ready to embrace collaboration which can be extremely uncomfortable to traditional command-and-control leadership styles. DevOps may be “better” across the range of dimensions that are identified in the puppet state of devops report, but that doesn’t mean that change isn’t hard and there will be resistance.

Is it all about tools?

There are generally two types of DevOps evangelist. The traditional technologist who talks incessantly about various tools and what value they will bring and the hipper “cultrualist” who is all about the human element (somewhere there are DevOps process lovers but I have yet to meet one). In some ways both are right. While overly focusing on tools can be unhealthy, the reality is particularly in Enterprise Environments change does often come tool first. The reason for this is not that it is the most effective way to bring about change, it is simply that corporate inertia and politics make it very difficult to change processes first.

Whether you go people/process or tool first is going to depend highly on your organisation. However, whichever approach you use it’s valuable to separate into two phases. The first is a spearheading phase, made up of tech spikes / proof-of-concepts, breaking rules and exploring. The second is about embedding, re-engaging with stakeholders and making the change permanent. Don’t think you can throw a tool in and get cultural change, that never works.

Variants

DevSecOps or “Rugged DevOps” attempts to consider how information security concerns can be captured and de-risked early, using techniques such as automated security scanning.

BizDevSecOps acknowledges that for a true end-to-end value it’s crucial to involve the business themselves in the process. This is significant organisational change, which not everyone will be ready for.

Additional Reading

One of the best online sites about DevOps is the DevOps topologies website: http://web.devopstopologies.com/. This site lists the major variants of DevOps talks through why each are used and which patterns to be avoided. It’s a great website.

The period table of DevOps by XebiaLabs is an attempt to map the various tools and where they fit. While not perfect, its a novel approach to visualising what is out there. See: https://xebialabs.com/periodic-table-of-devops-tools/