What's the big deal with GitOps? A quick introduction

First came DevOps. Then DevSecOps. Now, the latest 'it' thing is GitOps. While it may sound like another buzzword, its usage is rather useful. But what exactly is GitOps? Why does GitOps matter? Is GitOps just another trend, or is it something that you can leverage for your apps and software development processes?

What is GitOps?

There are two parts to GitOps - the git part, and the Ops side of things. In a nutshell, GitOps is a code-based infrastructure that relies on Git as a single source of truth. If this single source of truth changes, so does the deployed product. It also means that the app's infrastructure and systems are reproducible with the ability to create synchronous updates.

GitOps is also a way of controlling the way systems are automatically created, updated, and deleted. You can use pull requests as part of the automated deployment processes to configure and set the infrastructure.

The act of having a single source of truth and running everything from a centralized deployment resource may sound like the intuitive thing to do - it hasn't always been the case.

The concept of DevOps vs. reality

In reality, most systems are implemented via manual deployments with manual hardware management. This includes the task of connecting and provisioning machines, creating layers, and provisioning APIs with load balancers. This often involves large amounts of manual configuration work with various scripts living in different spaces. When an app is small, this method appears manageable. However, if the team composition changes through growth or system admins leaving, it can cause havoc by leaving knowledge gaps to create systems knowledge decay.

DevOps migrated this issue over to the developer. GitOps truly solves this issue through an enforced single source of truth. It allows the team to collectively version control the system, track and apply any systems modifications. Histories can be reviewed, which also gives the ability to audit and identify when security vulnerabilities, bugs, and any other issues are introduced.

At its core, GitOps is a method of implementing continuous deployment that requires minimal intervention once it's set up. This is the major difference between DevOps and GitOps. With DevOps, there is a process of tinkering and intervention involved to get things into production. GitOps, in contrast, involves only setting up the pipeline and ship code directly into different spaces once a code merge is approved.

How GitOps work

On the surface, GitOps is a simple concept. It's the process of centralizing your code, documentation, and infrastructure around a version control system (in our case, it is Git) so that it can be automated and deployed.

But how exactly do GitOps works?

Imagine that you have a project. Someone on the team does a pull request, edits the code, issues a merge request. Once the code is approved and the merge request is completed, the automated GitOps operator detects the change, another automater declares the change as operational, then it gets deployed. Once the pipeline is set up, there isn't a requirement for any manual intervention.

The good parts of GitOps

Declarative system

The process of deploying code to infrastructure is often done through a series of steps. This can cause issues if the order generates a different set of responses that are divergent from the expected norm.

In contrast, GitOps relies on a series of facts to deploy. The app's declarations are stored and versioned in Git, and the order of facts implementation is not a vital part - only that the end result is what is stated and expected. This allows for cluster infrastructures to be deployed or rolled back with speed.

System state versioning

Using Git as the single source of truth also means that versions are canonical. Rollbacks are simplified through a simple git revert, which is going back to the previous application state. Commits can be signed to enforce authorship and traceability for larger teams.

Approved changes automatically applied

Once the code is merged, changes will be automatically applied through triggers that implement the CI/CD workflows. This means that once your code is committed and merged to the target branch, there is no need to do anything else to deploy.

The bad parts of GitOps

Lack of secret management

It's unsafe to store secrets in Git repositories. Why? Because it extends the scope of accessibility to people and spaces that may not need it. The purpose of secrets is to create security layers and boundaries. If secrets such as private keys are exposed, it creates a vulnerability for your application. The security issue and scope of the breach also increase if the key is non-revocable.

Not designed for programmatic updates

Git is designed for manual editing and conflict resolutions. This means that if you have an app that requires frequent updates, Git would be unsuitable especially if updates are occurring in parallel and by multiple parties. Git's linear processes are great for smaller teams but can cause issues if multiple teams are working on the same repository and branches.

Struggles with complexity

As your teams and environments grow, so do the number of GitOps repositories and application environments required to be supported. This means that every repository requires access rights configuration, management, and maintenance. As the complexity and number of Git repositories grow, so does the time spent on creating automation and provisioning of GitOps repositories.

Wrapping up

GitOps is loved by smaller projects and startups because of the agility it can bring to a project. While it's being touted as 'the next big thing' in automation, GitOps is more a natural progression towards decoupling the developer from infrastructure work.

The aim of DevOps and GitOps are the same - to help the developer deploy apps as quickly and with minimal friction. As new products, services, and ideas becomes available, so do the techniques of achieving this. GitOps is one of the multiple ways a developer can achieve automated deployment. If you're already using git, making updates to your app becomes a streamlined process that doesn't require any additional manual deployments once the pipeline is set up.