DevOps: The Big Misunderstanding
As DevOps has spread, it has strayed from its original spirit, sometimes to the point of meaning the opposite. Let’s set the record straight.
This is the story of one word: “DevOps.”
We’re tired of hearing the “it works on my machine” excuse, only to then wait three months to deploy to production. Especially since, within the company, there’s a dedicated team that manages production, and going through them is a mandatory step. A team that tells you you didn’t use the right template for the documentation and that, anyway, it’s summer, so we’re freezing all operations for two months 😱
Hence the idea that managing production, and more broadly operations, should be the responsibility of the development team. Develop and manage operations. Deploy to production as frequently as possible to make the process less painful, several times a day, or even with every commit (trunk-based development). In any case: You build it, you run it. It’s an excellent idea; no complaints there.
What’s problematic, though, is how we actually use it. Starting with the famous line: “Let me introduce you to Lucas, the team’s DevOps.”
Hmmm… let me think… no. What’s the problem? That means a single person will be in charge of operations for the entire team. When Lucas is on vacation for the entire month of August, how will you manage? And if Lucas were to get run over by a truck, how would you handle it?
Sound familiar? Bingo! It’s the same problem as before, but on a team-wide scale 👏
You might say that all this is only partly true, since Lucas will have set up a CI/CD pipeline before he gets too close to the truck. Well done. And you’d be right: we have to hope the pipeline works even if Lucas isn’t there: that’s kind of what we expect from a CI/CD pipeline.
Except that “Lucas, the team’s DevOps guy” is the kid-friendly version, for those under 18. The adult version is “a DevOps team,” and that’s from real-life experience, needless to say. Sad, really.
So, what should we do? As is often the case, we just need to go back to the original concept and listen to what the term DevOps actually means: developers who are skilled in managing operations. This means that I, as a developer, cannot afford to ignore these topics. A developer who doesn’t care about how to deploy their code to production is like a chef who claims to make a beautiful soufflé but has never bothered to figure out how to bake it.
Ultimately, Ops should be at least a secondary skill for the much-sought-after T-shaped professionals. That is, I need to be able to do simple things on my own, for example, setting up CI/CD via GitHub to deploy to Docker, all in a monorepo with proper secret management. Simple and effective. The goal is to easily push to production, not to work with K8S or Terraform.
It’s great if one person has a stronger affinity for these topics and helps the rest of the team build their skills. Ideal, even. But offloading everything onto that person and entrusting them with all Ops-related tasks is shooting yourself in the foot. DevOps is a collective practice. Having one person on your team responsible for all Ops tasks means missing the point of DevOps.
The same goes for security. I can’t ignore the basics of security, or else I become a walking vulnerability. That’s where the DevSecOps movement comes in. A basic understanding of these topics is no longer really optional today.