This is something I have wanted to write about for a long time, ever since I started working with helping define GitOps as a member of the OpenGitOps project. Although I have been seeing this from time to time ever since I started working in IT, having to correct people when they use the term GitOps over and over again made me realize a couple of things. One, we are really bad at naming things in our industry and that leads to confusion. Two, when people hear new terms they rather want to interpret it and then spread that as gospel, not spend a few minutes learning what the term actually means.

It is all in the name, except when it is not

Naming is hard, OK? We have a couple of choices here, like something that is descriptive and impossible to misunderstand (boring, usually), or something that sounds “cool” (more open for interpretation). A few examples of this would be:

  • TCP, UDP, IP, FTP, etc…: We all know exactly what this is, but that is because we had to learn what it was. You take a long, descriptive and “boring” name, abbreviate it, and then everyone has to learn the meaning of it anyway. Sometimes without actually knowing what the abbreviation stands for. But at least we know what we are discussing and you either know what it is or not.
  • GitOps, DevOps, DevSecOps, MLOps, FinOps: It might make sense at first, but after the popularization of DevOps (which people totally misunderstood and use in the wrong way), the *Ops pattern have been used and misused over and over again. These have all specific meaning but people use them in generic ways

Example Cases

DevOps

This has been an annoyance for many of us. It has been used as a describer for roles and teams, but it should never be used in that way. The name of a role or a team is very descriptive and should give you an idea of what they are working on. While it is true that DevOps is about using code for tasks and automation, it is also about collaboration and breaking down silos. Placing DevOps in a silo is so… anti-DevOps.

First of all, no one person or team is doing DevOps. Either we are all doing DevOps or we are not. DevOps is a collaborative culture, it should be done by dev and ops, infrastructure and security. DevOps is using a shared toolset and procedures.

Unfortunately, in the aftermath of the DevOps movement, we often see cloud engineers and platform teams being labeled as DevOps. It’s often described as those who make the pipelines work, that creates the tools used by developers, and even those who work on cloud infrastructure. This just shows that those naming and assigning DevOps to teams have no idea what DevOps actually is.

My analogy for years have been that calling someone a DevOps engineer is like calling a car mechanic a “power tool engineer”. While it is true that car mechanics use power tools, that does not describe what the person is actually working on.

GitOps

This one is maybe the most irritating one for me, especially as someone who helped write the GitOps principles. Before, during, and even after writing the principles there was discussions on changing the term to something more fitting. As soon as someone hears Git and Ops together, they think that it is the act of putting code (infrastructure or configuration) in Git and then automating it.

In reality, GitOps is an operational model that adhere to four defining principles. These can be read at opengitops.dev, but let’s break it down real quick.

GitOps means defining your desired state somewhere immutable and versioned, have software agents in your system that pulls in the desired state and then to continuously reconcile the desired state with the current state. In other words, the system itself has to listen to the source and manage itself. This does not mean putting Terraform into Git and then use pipelines to push the change, this means that the system ensures that what you wish to be true is true.

This is not the solution for everything, but it is a powerful operational model for application delivery, especially when you are building platforms with Kubernetes. It does not require Kubernetes to work but it comes natural for it. In Kubernetes we have controllers that looks for change in the API server and then ensures that is what is happening, and GitOps is just an extension of that. Actually, the desired state does not even have to be in Git, as long as it is stored somewhere versioned and immutable. That means it can be stored as an OCI artifact or even in blob storage.

DevSecOps

This one sometimes goes a bit under the radar, but it is often misrepresented even by the most

DevSecOps is not DevOps just taken a bit further, a replacement for DevOps or anything like that. Security should be a conscious effort by everyone, and DevSecOps is how your security team can enable those efforts in every part of the software development lifecycle. While DevOps is about faster release cycles, focus on automation and autonomy, DevSecOps is all about implementing the tools to ensure the tools at the teams disposal are secure and safe.

While DevOps cannot be tied to one role or team, DevSecOps can be. Someone should focus on integrating security and compliance into automated workflows, environments and toolsets. The main difference is that while DevOps is a collaborative culture, DevSecOps is something one need to implement. No matter where you build your service or product, it comes with everything needed to “do” DevOps but security needs to be configured.

Why does this matter?

Communication and expectations. If there is one thing that I have seen throughout my career, it is that most of the time during a project is wasted on setting expectations and communicating the obvious. People create their own reality based on their understanding of these themes and that leads to friction, bad planing and much more.

I am not writing this to point any fingers. This is a human trait and not unique to our business. There are plenty of things that I do not know very well, but based on my understanding I guesstimate. The main issue is that it is also very human to think that we understand a topic completely, which can lead us down some rabbit holes.

My plead is that you either read up on and try to learn the actual definition of these terms before trying to implement them. Don’t look for only one source, because there are plenty of others that have put their own interpretation out there as fact.

We will never be at the point where there is a common understanding of all of these different domains, but if you haven’t dived deep into something, please start the a conversation about it with a disclaimer like “My understanding is that…” to not assert it as fact. I try my best to do this all the time, as I know that there are plenty of things that I do not fully grasp, yet.