GitOps and the Rise of Everything-as-Code

GitOps is a term that is getting more and more popular to describe a certain way of handling the operations of an application or IT system.

In this blog post, we will look at the definition of GitOps and at its most important core principle: Infrastructure as Code (often referred to as “IaC”).

GitOps is considered the future of doing operations and we will line out why, what the benefits of GitOps are, and why you should also consider going GitOps!

What is Infrastructure-as-code?

Before we dive deeper into GitOps, we have to understand the concept of Infrastructure as Code (IaC). IaC is a different way of managing IT infrastructure. Instead of performing manual tasks in a tool such as the Azure portal, the “state” of the infrastructure is centrally managed via a git repository. This could even be the same git repository that already hosts the code of an IT application. The engineer declares what the state should be, and the IaC tool takes care of achieving that state. We’ve written a guide to testing Infrastructure as Code that goes more into detail.

The opposite of doing declarative coding is known as imperative. To understand the difference and benefits of doing your infrastructure as code, see the following example for running a virtual machine in Azure, in an imperative way and declarative way:

Imperative - the old way (self-written logic)

Retrieve all virtual machines. If there is no virtual machine in Azure, set up a new virtual machine in Azure, if it is already there, do nothing.

The engineer in this case has to write logic and verify the state and whether that state is achieved, for example by calling the Azure CLI for all virtual machines and checking whether the one that needs to be there is already there or not.

Even worse: in a pre-DevOps time this was a manual task done via calling the operations department: “Hey John, I need a new virtual machine in Azure!”.

Declarative - the new way (as code)

I want one virtual machine to be there in Azure.

The engineer only has to write the desired state: the tool (e.g. Terraform) takes care of actually achieving the desired state.

As you can see, managing infrastructure becomes a lot easier this way. The engineer no longer has to keep track of what is already there and what should be there. Instead, the engineer just declares what there should be and the tool takes care of doing so.

Read our blog post on providing a declarative API if you want to learn how and why we built an API that uses the declarative approach, as opposed to a regular imperative REST API.

Everything as Code

IaC has meanwhile become such a success that we can actually see other aspects of IT being handled “as code” as well. This is usually described as “Everything-as-code” or “X-as-code”. The as-code movement has meanwhile made its way to CI/CD, security, and even code quality standards as well. The rule nowadays for developers is: if it can be managed as code, we do so.

Just last week, I ran into this example by myself, in this case for the tool Netlify. Netlify is a way to build and host your front-end project in an easy way. The screenshot below quickly demonstrates how closely related “configuration as code” and the actual “manual” configuration in the user interface are:

What is GitOps?

So then, to make the main question of this post: what is GitOps?

It has to be said that although IaC and GitOps could be considered separate things, there is a good chance that people using IaC are already doing GitOps. If you have hooked up a CI/CD pipeline to your IaC repository, you’re already doing GitOps, nice job!

GitOps builds on top of the principles of Infrastructure as code (or anything as code). By declaring our desired state in code, we can now also hook up CI/CD tools to actually operate the desired state that is declared in our code.

To put it briefly: GitOps is doing IaC in Git and automating away the Ops through CI/CD. Together they become GitOps. Historically, Kubernetes is the first tool that heavily used GitOps.

What are the benefits of GitOps?

By declaring and operating your infrastructure in a GitOps way a lot of benefits are unlocked. These are comparable to the benefits of tracking your application code in Git:

1. Including our infrastructure as code in a git repository creates a single source of truth. By being able to check out the git repository, anyone at any time can figure out what the state of the infrastructure should be. There is no longer a Word document or Excel sheet laying around in some folder that should contain this information.
2. When making infrastructure code declarative, instead of writing custom code that rolls out the infrastructure, it becomes less complex. This makes the infrastructure as a whole better readable. No need to guess anymore what the code might be doing. It is just stated what the state should be, which is much easier to grasp than imperative code.
3. The infrastructure is as close to the application code as it can be. If possible, you can manage the infrastructure of your application fully in the same git repository as the application code that is run on the infrastructure. This also enables kickass workflows such as doing application & infrastructure changes in the same pull requests.
4. When you write your infrastructure as code, then you allow yourself to reuse infrastructure. You could for example define your infrastructure once, and deploy it both for a test and a staging environment from a single declaration.
5. You are unlocking all benefits of using git. By tracking infrastructure changes in a git repository, all git benefits are automatically unlocked. Think about branching, tracking history, and most importantly, collaborative pull request workflows for reviewing and accepting changes.
6. Given the rise of CI/CD tools out of the success of Git, it is also obvious that GitOps provides the best automation opportunities. Declaring your infrastructure as code is one thing, but automating all other tasks away is an obvious next step to improve the way you do operations.

It’s pretty cool what people do with GitOps. For example, the contributors at Infracost combined the benefits of points 5 & 6 and built an open-source tool that estimates the $ you increase or decrease on your infrastructure costs when opening up a new pull request in GitHub.

GitOps enables agility

GitOps in the end achieves that same, known workflow for DevOps teams that they are already used to for managing IT infrastructure, or other aspects.

Need to change the size of the VM used? Just open up a pull request/merge request and the change will automatically be rolled out to the right environments.

The GitOps workflow will ensure that teams get the same speed and agility of changing application code. This is key to enabling business excellence, which is growing closer and closer to a company’s ability to deliver software fast.