What the GitOps Model Is and Why It's Taking Off

The tech world seems to love to coin new jargon that isn't always easy to define – and once adopted, jargon often seems to begat new jargon.

For example, just as folks were finally beginning to feel secure with their understanding of DevOps, along came DevSecOps; the latter being relatively easy to grasp because it basically meant adding security pros to DevOps teams. Now, organizations are adding GitOps as a Kubernetes deployment strategy, which isn't quite so intuitive to grok.

Luckily, if you understand DevOps or DevSecOps, you should be able to pick up GitOps rather easily.

As Christian Hernandez, a senior principal technical marketing manager at Red Hat (and a self-proclaimed GitOps enthusiast) observed recently in a GitOps-focused podcast, "The difference [between DevOps and GitOps] is really quite nuanced."

We're here to break down what exactly the GitOps model is and why it should be part of your Kubernetes deployment strategy.

The GitOps Model Demystified

Basically, GitOps is the practice of adding automated version control to every aspect of a container-based CI/CD (continuous integration/continuous delivery or deployment) environment – usually using Git, a version control system developed by Linux founder Linus Torvalds for tracking file changes in Linux.

Git has become something of a standard, used by developers at both proprietary and open source software projects for coordinating collaborative efforts during software development. It's also the versioning system used by many popular open source software repositories like GitHub and GitLab.

Although there are several ways that GitOps is practiced, they all basically follow the guidelines laid out by the UK-based Kubernetes-management startup Weaveworks, which came up with the term "GitOps." It has also contributed the software it developed for deploying GitOps, most notably Flux, to the Cloud Native Computing Foundation.

These days, the company is so intricately tied to GitOps that it calls itself "the GitOps company."

Jordi Mon, Weavework's product marketing director, told ITPro Today that Alexis Richardson, the company's founder and CEO, originally called the method "Operations by Pull Request," a reference to the Git term for the submission of code to be reviewed and merged into a project.

"Some time after that, someone in the team coined the term GitOps to make it easier to remember," he added.

According to Mon, the GitOps model is a way for DevOps to effectively work under an "infrastructure-as-code" model in which all components of the system – application workloads, configuration, and infrastructure – are managed and provisioned as code.

GitOps manages this by having everything on the system versioned, which allows operators to establish gateways not only to ascertain that the latest approved version of everything (including configurations and other items not traditionally versioned) is being used, but also to make sure that no changes are made that could affect security, compliance or other areas. It also makes life much easier for developers since they no longer have to spend time configuring every aspect of their code before deploying it.

"Ultimately, what this methodology allows you to do is actually have that flow of continuous delivery automated, but with the specific checks and balances that you want," Mon said.

Adopting the GitOps Model

Because GitOps is basically a tweak to standard DevOps practices, with foresight and proper planning, making the move should be little more than a bump in the road for most organizations.

"Does it require a lot of work?" Mon said. "Not necessarily. It requires a lot of Git dependency, so if people find Git daunting, then GitOps is probably is not their thing."

It seems that many DevOps teams don't find Git daunting: In Stack Overflow's recently released 2021 Developer Survey, more than 90% of the 76,253 respondents said they have "done extensive development work" using Git during the last year. This underlines the fact that Git is a versioning tool familiar to most developers – so much so that Mon said at Weaveworks they "take it for granted" that most DevOps teams are knowledgeable of enough features of Git to make them fluent with it.

Adopting GitOps also takes little to no investment in terms of infrastructure – that includes software needed to support the methodology. Most Kubernetes platforms already contain a Kubernetes controller, which is necessary to keep clusters in sync with the Git repository. This makes sure that they're running the right version of any software, and that they alert the system's operators in case of a problem, such as a possible bug or vulnerability that might require a rollback to an earlier version. Flux is probably the most popular software, but there are others, such as Argo CD, used by Red Hat in OpenShift.

This means that most companies deploying containers in a cloud-native environment already have the tools at hand to make the move from vanilla DevOps to GitOps. For organizations whose Kubernetes deployment strategy is to forego a vendor-supplied platform for a more homegrown solution, the GitOps model is a good fit. Most Kubernetes controllers, including Flux and Argo CD, are open source, meaning they're freely available to download and install.