2021 State of DevOps Report

21. 07. 2021

Overview

[even the people in the report are peeking at my IPA :-]

2021 State of DevOps Report is the 10th edition of this super insightful annual report. Each year, thousands of people share their experience in applying DevOps principles while authors crunch the data and serve us valuable insights. Last year I discussed the report with Alanna Brown who started the report in the first place. Alanna is one of the kindest people I met – you should listen to our conversation and see for yourself!

This edition is a special one: apart from revealing the trends, it nicely summarizes what happened in the last 10 years and gives us a glimpse into the future.

I opened a bottle of nice IPA the other evening, wanting just to take a look at the report. In the end, I read the whole thing in one piece, nodding to myself almost all the time.

Huge thanks to main authors Nigel Kersten, Kate McCarthy, and Michael Stahnke, as well as all additional contributors.

Here are some of the highlights – for the full experience I encourage you to read the report.

Models such as 3 Ways of DevOps, CAMS and CALMS all emphasized that while DevOps was made possible by automation, programmable infra, and more accessible prog languages and APIs, it was fundamentally a human-centered movement, focused on improving the interactions between people.

I like how the report starts, with a clear message that DevOps is fundamentally a human-centered movement.

If you’re doing technology just for the technology and you’re not trying to overcome some friction of the human kind of siloing or group siloing or information siloing or whatever, then you’re just doing the engineering part and you’re not, in my opinion, doing the DevOps part.

Patrick Debois, Advisor, Snyk

I like this so much because too many times new conversations about DevOps steer toward Jenkins and Kubernetes… damn if it was that easy, most of us wouldn’t have a job today.

The combination of Alanna’s expertise in spotting market trends and meaningful insights into their evolution with Nicole’s rigorous research methods, and their joint efforts to share this work broadly, helped to set new industry standards for high performing teams.

It was a perfect storm! Alanna talked about this in our conversation – how she met dr. Nicole Forsgren, Gene Kim, and Jez Humble, and how their collaboration launched the report on a whole another level.

…even though DevOps is everywhere, it’s rarely done well at scale, particularly in the enterprise.

This is so true and in line with what we all see in the field. In large organizations, there are pockets of success but generally, organizations have a hard time rolling the success out across all teams and lines of business.

PSA: In the interest of full disclosure, this is where I ran out of IPA(!) and had to switch to my wife’s gin tonic. IMHO, this didn’t deteriorate my reading capabilities, she made a light one.

The most highly evolved firms benefit from top-down enablement of bottom-up transformation.

Let this one sink in… Transformation happens in the trenches but needs to be fully supported from the top. Neither can leadership execute the changes nor can teams authorize themselves.

You can’t engineer DevOps but when you say “automation engineer” people think you are a Q&A tester.

Katharine Yi, Senior Cloud Engineer at Arena Analytics

Again, I feel seen. We refuse to put “DevOps” in the role name and rather opt for “automation engineer”. That led us to people with automation degrees applying for the job, expecting it has something to do with manufacturing and conveyor belts.

The argument over whether “DevOps” belongs in job and team titles is nearly as old as the DevOps movement itself, and from comparing past surveys, we see that we reached “peak DevOps team” in 2018, and are now nearly back at 2016 levels.

As I said, I’m personally against it and I will die on that hill

We suggest that organizations move away from the use of “DevOps teams” towards clearer team names, and in particular that the use of stream-aligned and platform teams is a well-defined path to achieving DevOps success at scale.

Team Topologies FTW! It is such a useful approach to structuring and organizing your teams that you must give it a chance. Read all about our experience with Team Topologies and how we built a successful platform team.

I have seen more success when organizations focus on the developer experience – creating guardrails that reduce the burden and enable agility, including a mechanism for feedback. Some amount of discipline enables speed.

Courtney Kissler, CTO, Zulily

Courtney led several large-scale organizations and knows how it is done: we need to make “right” easy to do. Hence guardrails and mechanisms for feedback.

DevOps is not synonymous with automation.

YES YES!!1! We always focus on automation because it’s easier than dealing with messy organization, people, relationships, interactions, politics, incentives, mindsets, what-is-value questions.

DevOps is not just automation, yet automation — and in particular, the kind that automates repetitive, soul-crushing work — is what enables us to find the capacity to focus on deeper structural improvements, and to shift our focus to delivering value for other teams and our users.

I use cloud therefore I must be good at DevOps, right?

Most people are adopting rapidly evolving public cloud platforms, but ignoring most of the benefits by deciding to treat the whole thing like it’s an early 2000s on-premise virtualization installation.

Hard no!

What about Dev(Sec)Ops?

A: The first view is that DevOps is a way of working, DevSecOps shouldn’t exist as a separate label

B: The second view is that our industry needed an explicit call to action to start including security from the beginning

I’m on A-team. But I hear you B-team! Just like John Willis once said, paraphrased: if that’s what is needed for this industry to start thinking about security then I’ll go along with it!

The biggest blockers for organizations toward the high end of the middle are found in failure to create cultures of knowledge—insufficient feedback loops, unclear responsibilities, and failure to share best practices.

This seems easy but it’s hard

Executive leadership may not have the ability to change the daily habits of teams or engineers, but they do have a lot of influence over organizational structure and value streams. The formation of a platform as a product and one or more teams to support that platform is an action executive leadership can take to expand DevOps success.

I like 2021 edition a lot! I see I’ll be citing this a lot for the next 360sh days.

People take a look at the report!