What went wrong with DevOps (r)evolution?
It looks like high hopes for a significant jump in the effectiveness of the software development process thanks to DevOps adoption have evaporated. Unfortunately, this disillusionment and frustration are growing among many of the once enthusiastic followers of Google, Airbnb, Amazon, and other digital senseis.
For over a decade, companies commonly embraced DevOps to control the software development process end-to-end through its self-serviced DevOps teams. “You built, you run it.” To raise effectiveness, awareness, speed, and quality of their software products. To end “over the fence” communication, delays, and failures. To face the digital business challenges and opportunities: work within the cloud-defined environment, open to and explore innovation, reduce time-to-market, and enable quick and flexible adoption to a rapidly changing landscape.
Anti-DevOps
Instead – DevOps engineers got stuck between the fast-changing environment, deployment pipelines, configuration, and environment management, fighting with its rising complexity and toolsets heterogeneity, unable to stabilize teams mixed of over-skilled seniors and under-skilled juniors. As a result, DevOps teams became ineffective in how highly skilled developers were used and too challenging for inexperienced developers.
The misconceptions and errors in DevOps adoption were observed and commented on from the very beginning. Thus we know, for example, 12th DevOps Anti-Patterns. Furthermore, a more elaborated, evidence-based typology of DevOps Anti-types was established by well-known authors of “Team Topologies” Matthew Skeleton and Manuel Pais.
One such misinterpretation is the DevOps Silo model, appointed “between” existing Dev and Op units; it may be a good solution for a start, but no longer than 12-18 months. The other – Dev Don’t Need Ops model – arises from the arrogance and ignorance of developers and its management team, who assume Ops skills and competencies belong to the past in the Cloud Era. At the opposite extreme, the low maturity of the entire organization and the arrogance of Ops may result in Rebranded SysAdmin model. Authors of this typology noticed that it becomes increasingly popular as many ex-Ops rebrands try to catch the waves of the DevOps hype. This mimic becomes even more open and bold in the Fake SRE model, where Ops renamed themselves SRE Team and did nothing more. History makes a circle in that case, as the company returns to a separate Dev and Ops scheme.
There and Back Again
The root cause of these problems was already mentioned: a deficit of highly skilled developers. Digital champions suck in the most considerable talents in a genuinely out-of-proportion way. DevOps is too demanding for the rest of the teams and companies.
Companies decided then that there is no pure DevOps achievable to all, but a master-level model for companies like Google, Airbnb, or Amazon and customized DevOps. Consequently, DevOps as a model splits into several types and keeps dispersing into new subtypes. Moreover, the model itself is adopting-to a “local” context rather than proving to be the “global” standard, mighty enough to set the tone of IT organization evolution and force the adoption.
And still, it’s reasonable. Software development teams use many tools provided by various vendors. Automation of the software development process requires it. The scale of complexity is the individual case of the company situation. Usually, we meet environments consisting of many components, including legacy ones. The landscape is vast. Managing such complexity devours the space and time DevOps engineers should devote to perform better software development.
Recently I spoke to a developer from a mature IT organization (the international bank), frustrated with the ineffectiveness this situation generates. He told me: DevOps works as a high-level abstract idea among high-rank managers. It might be a way to do things, but it turns out to be a time-consuming, costly, and competences-wasting manner of managing the software development process. Highly skilled developers should be focused on code quality instead of being distracted by such things as environment setup or managing the entire software delivery process.
ANY QUESTIONS?
LET'S TALK!
We will answer all your questions!
Podobne wpisy:
Are you a Cloud Native organization?
Cloud native leads to innovation
DevOps needs support. The Rise of the Software Engineering Platforms