What is GitOps?

By Cornelia Davis, Chris Hill, Dwayne Holmes, Tom Limoncelli, and Gail Murphy

There isn’t really clarity in the industry as to what GitOps is. After two days of discussion and consensus building at the 2021 DevOps Enterprise Forum, a team of experts came to the following conclusion: GitOps supports the DevOps agenda in a particularly effective manner (where Git is the interface for operational actions).

But that’s only the very highest level definition. The following post lays out a brief description of what GitOps is and how it can serve the DevOps community.

What is GitOps? 

Let’s look at how we build this out. 

First, on the far right in the figure above you’ll see we have some form of a runtime environment. We sometimes refer to this as infrastructure. That infrastructure could be bare metal, a cloud provider environment such as AWS or Azure, or it could be that you’re starting with Kubernetes, for example. 

For the examples we’ll use in this post, we’ll talk about Kubertnetes, in part because it gives you a bit of a leg up on some of the elements of GitOps, but this is just one example of a runtime environment. 

On the far left in the diagram, we have the humans who are caring for that runtime environment and the workloads running in it. As a part of their work, they will need to effect some change to that runtime environment – patch an operating system vulnerability or deploy a new version of an application, for example. There’s quite a lot that happens between the humans on the far left and the runtime environment on the far right. We’ll work our way from left to right – and then back again – to explain what GitOps is.

GitOps allows us to use Git, and extended capabilities that Git providers like GitHub and GitLab have made available, such as the pull request or merge request, as a key part of our operational practices. And here’s key point #1: We’re leveraging that – Git and the Git providers – as the primary interface for operations.

Now you’ll notice that we didn’t say it’s the API, rather it’s the interface. We are not just making calls to an endpoint somewhere, we are using the Git interfaces to collaborate with our teammates around those pull requests, implement access control, and more. The interface supports individuals who have the most relevant context to collaborate on a change review. This is what allows you to ensure the correctness of code config or infrastructure config changes earlier in the delivery lifecycle. In short, it’s an enabler of the shift-left we so love in DevOps.

And that collaboration, the review, is completely transparent. Every dialog, every change, every approval is automatically captured in Git, supporting full auditability of the change. Your auditors will love GitOps. Having all of those changes documented and tracked in this way also allows you to correlate changes with events that happen in the runtime environment, greatly aiding in troubleshooting and root cause analysis.

Again, Git as the interface for operations is the first important part of GitOps.

The next thing we’ll draw your attention to in the diagram is the arrow from Git to the runtime environment, and beneath that, some gears which signify automation. This suggests Infrastructure as Code (IoC), but for GitOps there is a bit more. In the figure you’ll notice that under “runtime environment” it says “actual state”, and under “store code/config” it says “desired state.” That provides the hint as to the nature of GitOps automation. 

We’re not storing imperative, brittle scripts in Git and using some automation to run those scripts against an environment where we aren’t completely sure of its current state. Instead we are depending on automation that is designed to assess the actual, current state of the runtime system, compare it to the declarative, desired state we have stored in Git, and bring them into alignment. It is a model of convergent automation. This is the #2 key element of GitOps, that the automation is convergent, making it ideally suited to the constantly changing environments that characterize modern IT landscapes.

Finally, the last part of GitOps—key element #3—is that there is an inherent feedback loop. While the notion that Git provides the interface to operations is central to GitOps, we recognize that there are times when you need to change things directly in the runtime environment. In these cases, GitOps must provide services that capture such changes in the source of record – and that’s in Git. If that direct runtime change should not be maintained, then GitOps is responsible for reverting it by reapplying what is stored in Git to the runtime environment. 

So that’s GitOps in a nutshell. 

How to Get Started with GitOps

In our upcoming white paper, we will layout next steps for the CIO and anyone else looking to implement GitOps. 

• Start where you already have declarative config and convergence automation, like Kubernetes. 
• Think big, start small, learn fast. You’ll want to start incrementally.
• Ask the right questions in your incident review that get to the automation, process, and style of infrastructure as code that GitOps serves.
  • How many human actions are needed to correct? (automation)
  • Are the recovery steps traceable? (process)
  • Is this a pet? (declarative infrastructure as code)

To learn when the white paper is available, sign up here.

Until then, Weaveworks has a great GitOps FAQ here.

- About The Authors

IT Revolution

Trusted by technology leaders worldwide. Since publishing The Phoenix Project in 2013, and launching DevOps Enterprise Summit in 2014, we’ve been assembling guidance from industry experts and top practitioners.

Follow IT Revolution on Social Media

• 
• 
•