Preamble
From my armchair at Bon Secours Hospital in Galway, wrapped in a blanket, as Infliximab slowly flows into my veins, I decide to write this post. In 3 days, I will be 48 years old, as good a moment as any to look at the failure of a concept that could have changed everything in the world of Tech: DevOps.
Disclaimer: this text reflects my opinion and this world as seen through the lens of my personal experience.
To begin with, if we go by the definition on Wikipedia today: "Emerging around 2007 in Belgium with Patrick Debois, the Devops movement is characterized mainly by promoting automation and monitoring at every stage of software creation, from development, integration, testing and delivery to deployment, operations and infrastructure maintenance."
According to this definition, this article would not really make sense, so let me tell you what it means to me, and about my encounter with DevOps.
Introduction
At the beginning of the 2000s, most of the large organizations I work with have their IT departments divided up like this:
1) The "devs": they design the applications, or sometimes even application or library building blocks, following requirements and detailed specifications, some without even knowing what the resulting application does.
I will skip the different "classes" of "devs": programmer, analyst programmer, etc.
2) The "Ops": they are in charge of operations, notably deploying applications and bringing them into service, as well as application maintenance.
3) The "sysadmins", in charge of designing and operating infrastructure. Here again, I will skip the different "classes" of technicians, engineers, systems and network architects, etc. Their remit runs from hardware to services, including networks, operating systems, etc.
First remark : the "ops" are not sysadmins. It is a separate profession.
In these companies I work with, these 3 departments are completely walled off, so much so that the teams are often not even located in the same geographical area.
The tension between these different departments is palpable, each one complaining about the work of the others.
Some start looking into the problem and conclude that a significant part of it could come from each "group" not understanding the others’ work, constraints and objectives.
They then try to bring these groups closer together and observe the results: first through exchanges in which someone from one department works immersed for a few days inside another unit, and vice versa.
These operations bear fruit and lead to new experiments: members of each department are appointed as "permanent" contacts, responsible for maintaining strong links between departments, improving information flow and making collaboration more effective. At the same time, these immersive exchanges become widespread.
Finally, the last major step: physical moves begin to bring these departments together in the same location.
This moment, now far behind me, is what I would call the apex of DevOps: this is not about technology here, but more about an organizational, operational, and philosophical approach, creating and developing real synergy between the different technical departments of the company.
Tension drops, efficiency and productivity rise, as each understands the others better. These exchanges also improve their understanding of the shared objective. I think I was, at that moment, among the greatest admirers of these initiatives and of this nascent "DevOps" movement.
The sellers (thieves?) of words
While DevOps was bearing fruit, those I call "the sellers (thieves) of words" would soon try to seize the concept, strip it of everything that gives it its soul, and sell it back to us just like surimi sellers: by trying to palm off on us this vile industrial paste in place of the crab meat…
The hype has to catch on, and fast: and anything goes to get there. "DevOps" starts to become a catch-all word to describe a set of software solutions, and, progressively, step by step, all those who do not use this software are despised, then "excluded" from the movement.
The atmosphere turns ugly, and the world of Tech, previously reunified, starts to fragment again. At first, a split appears between users of certain established automation or industrialisation tools, including Ansible, and others: they are dismissed as "outdated" by users of technologies described as "more modern". But it does not stop there.
I will not even talk about those who chose, or continued, other approaches, such as basing their automation on in-house tools written in shell or in other languages: disdain for them remains about the only thing the others agree on as they start fighting among themselves.
The fall
More cracks appear, until they turn into a compound fracture between several worlds: this is no longer limited only to the automation tools: the code-management tools, the development methods, and even the infrastructure choices are affected.
At the same time, the term "DevOps" has lost its shine and much of its substance, and now describes a new job: a sort of cross between the sysadmin and the developer (most often a developer who starts trying to do infrastructure, with results that are more than mixed in some cases…), supposed to understand everything, do everything, and solve every problem.
Better still, a DevOps engineer would be a magician thanks to whom no problem ever arises. "Would be" is the word to remember here, because when I ask the management of organisations I deal with, the feedback tends to range from "passable" to "it is a disaster, but we do not know how to go back: we oversold it internally and approved colossal budgets that we now have to justify…". "Worse still, our headcount and/or costs have tripled," others complain.
The DevOps movement continues to grow more radical a little more each day: to earn the "title", a DevOps engineer must now be «cloud native«, use software and methods determined by "the group", and swear only by Kubernetes (this is changing, with a new breakaway faction around Nomad) for their infrastructure, or face disgrace.
The cherry on top, in order to become the ultimate DevOps engineer: he must spit (vomit) on all those who do not think or do not do as he does (and, along the way, on the technologies, methods, or languages they use).
The "best practices" now seem to be those of self-congratulation for having designed a heavier, more complex contraption than the neighbor’s, and which solves problems that did not exist, while needing entire teams to run it where one or two people used to be more than enough (all while claiming that there is no other good way to do it, and that this is supposedly the price of "quality"… what quality?). We are no longer very far from firefighter-arsonist syndrome…
The explosion?
As in every radical movement, you only have to wait… because there will always be someone more radical to attack those who are not radical enough: an extremist is, by definition, in any case, a permanently dissatisfied person. Some "hair-pulling fights" and other "flame wars" break out here and there, whether internally or on social networks and other group chats.
This movement (which in reality has not been the same one for a long time), which at first glance seemed united against everyone, starts to fracture in turn. At the same time, people who were rather neutral and did not belong to any group become radical in turn against this "right-thinking" that people are trying to impose on them against their will, and end up becoming allergic to these technologies and principles, regardless of any logical analysis.
Will an explosion be the logical next step? No one can predict it or know it with certainty, but what I am sure of is that it is never good for Tech to find itself limited, or even locked into «best practices«. Some would like to make you believe that if thousands of people have worked on a subject before you, then they are necessarily right.
Yet a glance back at the history of computing is enough to see that it is factually false.
Do not limit yourselves to these beliefs, which have nothing scientific about them. Contrary to what some are trying to impose on you: test as many solutions as you can for yourselves, iterate, innovate off the beaten track, and remember this: every time the solution that is presented to you for a problem is complex, there is very probably a much simpler way to solve it.
Try out as many approaches as you can, using the systems, software and languages you like, and gain your own experience. But do not fall into the trap of doing things only to please yourselves (save them for fun).
In the end, there is only one thing that will determine whether you were right or wrong: the level of satisfaction of your clients. What determines whether your choices are appropriate is the result they expect, nothing else (same thing if your client is yourself).
With that, keep well, enjoy the holiday season, and merry Christmas!
—
Christophe Casalegno
You can follow me on: Telegram | YouTube | Twitter | Facebook | LinkedIn | Twitch
7 comments