DevOps culture, more than tools

How did DevOps start?

The DevOps movement began over 10 years ago. Patrick Debois was trying to apply agile mindset to the infrastructure he was managing, although without much success. Later he met Andrew Clay Shafer, who was working on the idea of agile infrastructure, and Jean-Paul Sergent, who was exploring ways to improve collaboration between development teams and IT operations teams.

They planned to share their ideas at a conference. In 2009, Debois saw a talk from Flickr about the cooperation between developers and operations to achieve multiple deployments per day in production. This motivated him to organize a conference in Ghent (Belgium). Calling it "Agile Systems Administrators" didn't seem like the most attractive name for the conference, and it ended up being called "DevOpsDays".

Currently, you can search for "DevOps" jobs and find a wide variety of required skills and roles. Some positions focus on Terraform or Ansible, others resemble an AWS Cloud architect or a Docker/Kubernetes expert, but few mention a DevOps mindset. Patrick Debois himself published a diagram about DevOps roles on his blog:

Since the conference that coined the term DevOps, the number of associated tools is growing day by day. Tools capture all our attention most of the time. However, the collaboration between developers and operations is the cornerstone of the DevOps mindset with the focus on continuous delivery.

DevOps Team Structure

Normally, each team within the same company has different responsibilities, so their priorities and objectives are different. This creates bottlenecks and delays in the delivery of new functionalities. And this is one of the fundamental causes that originated the DevOps movement.

The relationship between teams in the DevOps context was analyzed by Matthew Skelton in 2013 in “DevOps Topologies”. Here you can find one of the most common ways to accelerate deliveries: creating a specialized DevOps team for automation and CI/CD. Although you have to be careful since it is categorized as an anti-pattern because this team can become a silo (and DevOps is about breaking silos, right?).

This study on teamwork (not just DevOps) evolved with Manuel País and together they wrote the book “Team Topologies” where they analyzed the different ways of structuring teams for software development.

In the book they present different patterns for organizing teams and also describe the hidden forces that drive the relationships between teams.

One of the many key points of the book is the concept of **cognitive load**. A person is capable of retaining a certain amount of information to perform a task. And the same goes for a team.

Now imagine a team that works with a large number of tools or a team that handles many different responsibilities (or both). Inevitably, delays and bottlenecks will appear due to changing contexts, multitasking commitments, or days filled with meetings. Once again, the motivation of DevOps is to eliminate any delay to achieve a fast flow. The book provides guidance on how to address these situations.

What will be next?

Ten years after DevOps began in 2009, software development has evolved: cloud computing, infrastructure as code, microservices, docker, kubernetes...

So, is DevOps still relevant or has it become another empty trendy buzzword? Maybe we will hear Kris Buytaert talking about it at DevOps Barcelona 2022. In the meantime, we recommend you to read:

• "13 years of devops and 130 presentations later: how my devops mental model changed" by Patrick Debois
• "From Devoops to Devops, 10 years of learning" by Kris Buytaert