There are multiple tools available today for various aspects of DevOps, i.e building/shipping of code, Infrastructure automation, Observability, Security, Governance, Cost awareness and such. Companies stitch together these tools to create a software lifecycle and an end-to-end experience for the developers. However, creating such a platform is not trivial!
Multiple tool-chains and personas in various stages of the DevOps cycle may create integration gaps and handover inefficiencies. Collaboration through Tickets, Documents, Run-books or simply talking to various stake holders introduces a sequence that slows down everything. This is also known as DevOps Tax by many.
What is Concurrent DevOps ?
Sid Sijbrandij, CEO of GitLab, coined the term "Concurrent DevOps"(1) which he calls a "benefit statement"; A philosophy that can increase the DevOps efficiency and reduce overall collaboration time for all persons involved. It says that if these handovers and multiple tool management can be avoided, it will speed up your SDLC and can give very different results.
Being concurrent has been an elegant trend in the last couple of years. For example, not so long ago collaborating on a manuscript on a word doc involved having several draft copies sent back and forth on emails. Then came Google Docs which cut short all the time wasted in collaboration, controlling versions and made collaborating on a manuscript so simple and intuitive.
Concurrent DevOps is a take to solve the same problem for the DevOps process. Most of the current approaches involve handovers between teams and tools that are sequential in nature. All other aspects of software engineering have already evolved to being concurrent in nature. In a Concurrent model, people will have increased visibility to all aspects of DevOps and will significantly increase the efficiency and speed of innovation.
Our Views:
In our (Facets.Cloud) view, Concurrent DevOps is the next maturity model for agile software teams.
In our collective experience of speaking to numerous tech leaders, here are few things that stand out which can get addressed by adopting a concurrent devOps principle.
As the numbers in services x deployments x environment grow, visibility, predictability and efficiency reduces. This ideally should get solved by adding more team members, but it doesn't !
Dependency on a few - Knowledge sitting with specialised people, ad-hoc scripts or code that can be understood only by a few but impacts everyone
Poor visibility on to how my work affects others, how others work affect me, when will be I be unblocked.
As we Imagined a place where Development, Quality, Security, and SRE teams can effectively collaborate for complex set-ups, the following three requirements emerged to support concurrent devops.
1. Shift Left / Decentralisation
Decentralisation of creation or modifications of resources like applications, databases, caches, and the interaction between them is a necessity for agility. In a decentralised setup, developers should have the means to achieve the above rather than rediscovering the ways. Similar decentralisation is required for quality suites, security policies, alerts, dashboards and cost awareness to effectively ship and operate software. It is also unrealistic to expect everyone to understand everything - hence simple and familiar constructs and tooling is a must!
2. Collaboration / Visibility
It is important to have a single source of truth, where everyone can rely on to know the state and transition of the environments in its entirety. This single source of truth also empowers everyone to effectively collaborate and have complete visibility over all aspects. It counters the tribal knowledge and ad-hoc changes by design. Additionally, MTTD and MTTR metrics can improve significantly with better visibility and collaboration.
3. Governance / Guardrails
Central Guardrails are essential in a decentralised construct. In a concurrent devops, the specialised teams who set-up the centralised guardrails are just like any other teams. They are simply empowered to set controls around cost, security, compliance, sizing, release process/pipeline etc. that applies to every decentralised change being applied to the environments.
How should one get there?
One question that we are asked often, can we build this ourselves? Of course! Concurrent devOps is a principle first and a tool later. We would assume top global technology companies have solved it for themselves!
We at Facets.cloud, feel teams concurrent devOps platform can be simplified for organisations who wish to adopt but do not want to excessively spend on effort and expertise. Do write us to know more or collaborate!
This post was originally posted here.
References
https://about.gitlab.com/blog/2019/07/17/concurrent-devops/
Top comments (0)