Since the past couple of years, the term GitOps comes up often when any bunch of nerds get together. Hearing the term, we guessed that it is an offshoot of DevOps.
In this cut the digital clutter, I will explain what GitOps is and then we can make our own judgements on how far the apple has fallen from the DevOps tree.
GitOps 101
The term GitOps is centered around Git, and the principle that the methodology follows is that Git plays as the single source of truth. What is new in this you might ask as most projects used some form of Git and all our code resided in a Git repository. True! However, we go one step further and not only maintain the application source code but also the scripts that are used to build infrastructure.
With GitOps, there is only infrastructure as code (IaC) to build your environments and platforms. No GUI and no manual stuff. The scripts that spin up your infrastructure are version controlled and stored in the same repository. Through this we are truly looking at Git being the single source of truth.
GitOps takes into consideration all the continuous stuff (CI, CD, CT etc) and adds on top of it, a layer of infrastructure as code which is strictly enforced through a single repository – which is where Git has become a defacto standard.
Peeling the Next Layer of GitOps
In the last section, I simply stated what GitOps is about, how different it is from DevOps. I said take DevOps and add infrastructure in the form of code into source code repository, version control it, and then you get GitOps. Not quite that simpleton this new methodology is.
The question arises around who manages the infrastructure code. Those coming from a DevOps background would say that this is a part of the Ops responsibilities. Well, you would be mistaken. In GitOps, the developer is made responsible for infrastructure too. The developer needs to write the necessary infra code and push it into git.
Why would you give a purely Ops responsibility to a developer you might ask! Well, you should ask this question as it definitely deviates from what we consider as sane. Transformation is about disruption and the developer stepping into the ops shoes is one of them.
Now the rationale. With the developers at the helm of infrastructure provisioning, we are looking at the next level of collaboration. The developers are made responsible to choose the infrastructure they need and build it to their liking. The end result is a working software with desirable non-functional parameters. Developers often cite lack of infrastructure resources for their software to work at sub-par levels. With the keys to the infrastructure with the developers, they no longer have the cushion to pass the buck to the ops guys. As the saying goes – you own it, you ship it.
Where is the Control?
With the keys to the Porsche and the mansion with the developers, they can literally play god, and do what they want to do. Where are the controls to ensure that guardrails still govern the developer’s ways of working.
For GitOps to be effective, the desired state of the environments must be written in a declarative specification. This can be done for each of your environments, and this declarative specification sits on the source code management along with the rest of the code and is versioned. This becomes the system of records (SOR).
A tool that works very well with declarations is Kubernetes. The Kubernetes system is highly idempotent leading to drive the cluster towards the desired specifications.
Secondly, the Kubernetes system can observed just as easily. The properties of the cluster can be viewed and the convergences and divergences between the actual state and desired state be detected.
Why is GitOps the Next Big Thing?
Why do I feel that in the next few years, most organizations will be jumping onto the GitOps bandwagon? Today we are getting to a stage that a minute spent on maintenance or incident resolution is a minute wasted, money that is flushed down the toilet. And most often than not, troubleshooting takes a long time due to increased dependencies and the lack of accelerators that can make operations next to nothing.
Here GitOps has an edge. With the entire gamut of system coming under a single repository, and every change to the system registering on this system, any of the bugs can be fixed by fixing the code. And the best part is that we use a pull CI-CD pipeline rather than the traditional push pipeline. Through this, production issues can be fixed via pull requests rather than meddling with a live system. In essence, the changes that we effect can either make changes to the container, make changes to declarative specifications or fix errors in the environments.
