When Gitops doesn't make sense

There are few topics more pervasive than GitOps in engineering these days. With the benefits becoming increasingly clear every year, we recently highlighted the impact of GitOps for the enterprise. However, that does not mean its benefits are universally clear-cut. It’s important to understand when GitOps makes sense, and when it doesn’t.

Before we get stuck in, let's just make sure we're all talking about the same things: the GitOps we're discussing here is syncing of declarative configs from a Git repository into a target system e.g Kubernetes. The syncing is done by a GitOps operator which pulls from the repo into the target system.

What GitOps is great at

GitOps is an effective way to improve operational efficiency by enabling automated deployments and continuous delivery. Since every change to the infrastructure is initiated through code and stored in the repository, it becomes much easier to enforce consistent practices across environments, reducing the risk of configuration drift. 

Using this approach to manage live environments thus can help with security, resilience and compliance:

• As GitOps involves storing all configuration in a git repository, it is possible to avoid live network connections between development infrastructure and production infrastructure,
• Rolling back configuration involves reverting a commit in the repository and
• Git history provides a built in audit log which is useful from a compliance perspective.

This makes GitOps a great choice for deploying to high security environments and production environments in highly regulated industries. 

André Alfter gave a talk at Kubecon EU about using GitOps with the Humanitec Platform Orchestrator to deploy to air-gapped environments. Here GitOps is a critical part of what enables this high security use case. You can find here a case study for a similar setup.

Some things are tricky with GitOps

Slow developer experience

GitOps is inherently an asynchronous system. Things are eventually consistent based on latency caused by pipelines and the GitOps operator itself. This means that there can be a substantial amount of delay between a developer pushing their change and the change being fully rolled out.

Managing dynamic environments

It is difficult to model dynamic environments with GitOps. A good example is for preview or PR environments. These involve creating a new, ephemeral environment that exists for the time that a PR is open. The biggest problem here is modeling new environments - either as additional directories in a repository, an additional branch in a repository or even an entirely new repository.

Promotion between environments

In general, promoting between environments with GitOps involves managing file copies. As git does not have any insight into what the files mean, it cannot help avoid standard errors such as: copying config parameters such as database names from dev to staging.

Best of both worlds

Many organizations would like to benefit from GitOps in their Production environments while also benefiting from a non-GitOps approach for lower environments. This best-of-both-worlds approach risks complexity for developers if they are exposed to different ways of deploying.

An Internal Developer Platform can provide a consistent experience for developers while allowing the Platform Team to use different approaches for deploying to different types of environments. This is especially valuable when combined with ephemeral environments and automatic promotions. From a developer perspective, the use of GitOps becomes an implementation detail.

How to get started

You can also get started right away by speaking to one of our platform architects or joining our Minimum Viable Platform (MVP) program.

Take a look at our Red Hat OpenShift platform reference architecture implementation including ArgoCD which was recently published on GitHub and as a whitepaper.