What is Concurrent DevOps: The next maturity model of DevOps

DevOps aims to streamline the continuous cycle of software delivery, from code to production.

Managing and using all the tooling required in the different stages of the CI/CD pipeline is a monumental task. You need many tools that take care of all the aspects of DevOps- infrastructure automation, building/shipping code, providing observability, security, governance, cost awareness, etc. Companies end up making internal platforms that stitch these tools together to create ad hoc end-to-end solutions. However, building these kinds of platforms is not trivial!

Added to this, multiple personas - dev teams, test teams, and ops teams- work on the same application, data, and resources at each stage. Research by Atlassian concluded that collaboration is a key factor in DevOps success.

The usual way of collaboration is through tickets, documents, playbooks, or informal communication between various stakeholders. This sequential handover of data, artifacts and other resources introduces handover inefficiencies and gaps in integration, ultimately slowing down the whole process. It creates multiple views of data. This is also known as DevOps tax.

All this undercuts the advantages of DevOps itself!

What is Concurrent DevOps ?

Sid Sijbrandij, CEO of GitLab coined the term “Concurrent DevOps” which he describes as a ‘benefit statement’. This philosophy of concurrency has been an elegant trend in the last couple of years. To explain the concept, Gitlab cites the example of Google Docs. Previously, collaborating on a manuscript involved a word doc having several drafts being handed over to collaborators, going back and forth through email exchange. Then came Google Docs which cut the time spent passing documentation around allowing collaborators to work on a controlled version at the same time.

The idea behind Concurrent DevOps is to solve the same problem for the DevOps processes. Most collaborations involve sequential handovers between teams and tools, by making this collaboration concurrent instead of sequential, we can have increased visibility to all aspects of DevOps and significantly increase the efficiency and speed of innovation. Let’s remember all other aspects of software engineering have already evolved to being concurrent!

Our Views.

In our view, Concurrent DevOps is the next maturity model for agile software teams.

We’ve spoken to many tech leaders in the industry, to understand the issues they currently face. Adopting concurrent DevOps will solve the following main issues:

1. The combinatorial growth from the increase in the number of services x number of deployments x environments can be explosive and reduce visibility, predictability, and efficiency.  You’d think the solution would be to add more people, but that doesn’t work!
2. Dependency on a few: Specialized teams have specialized knowledge but they work in silos. Ad-hoc scripts and code generated to solve immediate problems can potentially impact multiple teams but they are understood only by a few.
3. Poor visibility: Multiple views of data and artifacts creates fragmented visibility of the overall status. Dependency and workflow across teams are not well defined. There is no well-defined way for one team to know when they are going to be unblocked and how their work will impact other teams.

As we imagined a place where Development, Quality, Security, and SRE teams can effectively collaborate for complex set-ups, we realized that the following three requirements emerged to support Concurrent DevOps.‍

1. Decentralisation: Decentralizing management of resources like applications, databases, caches, etc. is necessary for agility. In a decentralized setup, anyone from any team should have the ability and means to create and modify resources rather than reinventing the entire process every time they need it. This should be available to all personas, developers, QA, etc. Similar decentralization is required for quality suites, security policies, alerts, dashboards, and cost awareness to effectively ship software. Simple and familiar constructs and tooling are a must to achieve decentralization because it’s unrealistic to expect everyone to understand everything.
2. Collaboration: It is important to have a single source of truth that everyone can rely upon to see the health of the state of all environments in their entirety. This single source of truth also empowers everyone to effectively collaborate and have complete visibility over all aspects. It counters the tribal knowledge problem and ad-hoc changes by design.
3. Guardrails: Counterintuitively, central guardrails are essential for decentralization. For concurrent DevOps, specialized teams should set up centralized guardrails. They should be empowered to set controls around cost, security, compliance, sizing, release process/pipeline, etc. which apply to every decentralized change being applied to environments.
   

How can you adopt Concurrent DevOps?

We are often asked by customers, can we do this on our own? Of course! The principles and culture of DevOps have to be adopted first before focusing on tools. In theory, an organization can develop in-house tools to adopt concurrent DevOps principles but it is not trivial and requires specialized teams and the know-how of more than 30+ tools!

We at Facets.cloud feel the Concurrent DevOps platform can be simplified for organizations that wish to adopt it but don’t want to spend excessively on effort and expertise.

Contact us today to find out how we can help you.

‍