The last decade of programming has seen a number of revolutionary transformations. One has arisen from a monolithic application to a cloud-based micro-services running in containers. Another one has come from a set of practices around the DevOps methodology to align development and operation teams into a shared work process. And it’s not finished, introduced in 2017 by Weaveworks, the GitOps methodology is becoming the new standard to move faster in production in a reliable / secure way while continuing to bring teams to work closer. What is GitOps?

GitOps is another methodology of work that aims to optimize the time / effort between the developers and the operation team members. The main component of the GitOps methodology is obviously Git, a versioning source control tool acting as a single source of truth for declarative infrastructure and application configurations.

Git is not the only part of the ecosystem. The methodology relies on a combination of tools ensuring the current state of your infrastructure/applications converges towards the desired state declared in Git. With a version control system at the center of the delivery pipelines, developers can submit pull requests to accelerate and simplify application deployments as well as operation tasks. The modification of the infrastructure is therefore made easier for everyone to understand the impact of each update as everything is centralized in one place.

To sum up, the GitOps methodology can be represented by:

How does it work?

The main idea behind GitOps is Infrastructure as Code. This means using code to create and configure each piece of the infrastructure (networking, virtual hosts, security policies, etc) and store all the config files within a version control system, with automated processes, to make the desired state match the current state.

Basically, the idea is to have one or multiple Git repositories with the current state of the infrastructure and create a pull request each time an update is required. This is as simple as following the same steps that the developers have followed for decades to release their source code: create a pull request, ask for a review and finally merge it. Once the update is merged, the tool managing the automatic deployment takes care of it. This is usually an operator deployed on remote hosts, but it may also be a component waiting for a webhook to apply a specific pipeline.

What are the benefits and the disadvantages?

Moving to a new technology or work methodology is always a challenge. This is always a matter of, what are the benefits of this? What problems will it solve? Isn’t it another waste of time?

Applying the GitOps methodology can take a tremendous effort depending on the current state of the ecosystem because it will demand from the teams to code the management logic of the infrastructure and application deployments. Working on that does not have a real impact on the business, it does not create new revenue and can be seen as a waste of time without bringing “proper value”. But, you have to think in the long run because it can bring a lot of benefits:

• Productivity, meaning that everyone uses the same continuous deployment methodology, making it easier to onboard new people.
• Reliability through revert/rollback and fork features, empowering easier update testing in a dedicated environment before applying changes.
• Standardized workflows centered around one single source of truth in Git.
• Reduced potential manual mistakes.
• Visibility, as it helps measure the deployment frequency and reduce the feedback cycle.
• Idempotence, synchronizes multiple times in a day the infrastructure without impact.
• Secrets as code, encryption at rest (Mozilla SOPS)
• Disaster recovery, as all the infrastructure is code, without any dependency to the underlying infrastructure-type (cloud, on-prem, etc). The disaster recovery plan can simply consist of running the code on another region in the cloud, on another Kubernetes cluster, etc.

Obviously the GitOps methodology comes with some disadvantages that have to be considered before moving to it:

• It usually asks for multiple iterations to find the right Git architecture, mono-repository, multiple repository, etc.
• It might require some training for some team members to correctly understand the processes brought by the GitOps methodology.
• It introduces another set of tools for observability as it is important to know if the system is in sync or not and detect potential drifts from the desired state.
• GitOps does not enforce nobody to use it as someone can potentially deploy manually an app in Kubernetes for instance, and this needs to be controlled.
• Tracking all the deployments is made difficult but still available in Git.
• Identity access management is complicated with one single repository. A good strategy needs to be put in place before starting.

Every change has their own benefits and disadvantages, the GitOps cannot be summarized by these few points, and it deserves a deeper study depending on the use case.

What are the use cases?

GitOps can be used for a various number of reasons, it allows an organization to use a single tool for controlling infrastructure, enabling version control for changes in configuration as well as the ability to constantly monitor for changes and give alerts.

GitOps can be used for numerous purposes. Indeed, it empowers organizations to use a single tool to control the whole ecosystem, enabling versioning control systems to change configurations as well as the ability to constantly monitor changes and alerts.

GitOps can be used to standardize the continuous delivery process in a company. Continuous delivery enables development teams to build, test and deploy software at a fast pace through incremental updates. Capitalizing on the experience of a single method allows to greatly improve the velocity of these users. That means a developer can focus on the development of a new feature instead of wasting time controlling each step of the deployment of the application. GitOps and DevOps

The DevOps methodology could be explained in a few words by “the combination of cultural philosophies, practices, and tools that increases an organization’s ability to deliver applications and services at high velocity”. At a high level, the purpose of DevOps is to reduce the friction between the team processes to increase business impact. DevOps is more focused on flexibility rather than accuracy.

By design, GitOps is focused on correctness. GitOps could be explained by “the convergence from the current state to the desired state through automated processes”. The source of truth is not anymore the CI/CD tool but the version control tool.

To summarize, GitOps is part of the DevOps methodology, it completes and improves the DevOps by allowing to control a versioned desired state.

Next?

Some people believe GitOps may be the future of DevOps because it is both a declarative and a cloud-native approach to configuration management. However, the future of GitOps may not be the right fit for everyone, as not every organization will want to rely on a single tool or even just view pull requests as the most optimal workflow for their infrastructures.

The purpose of this article was to provide an overview of the GitOps methodology. This is the introduction to a series of articles describing how to implement it in multiple ways. Stay connected!

For more information on the GitOps methodology:

• Awesome GitOps Github project
• GitOps book
• GitOps, the bad and the ugly
• GitOps, What? Why? How? YouTube video

About the authors

Hicham Bouissoumer — Site Reliability Engineer (SRE) — DevOps

Nicolas Giron — Site Reliability Engineer (SRE) — DevOps