GitOps is like exercise: A little is good for you, but more is much better. Just as jogging a couple of miles every other week won’t hurt but also won’t dramatically improve your health, managing something like 30 or 40% of your processes using GitOps won’t supercharge your approach to IT operations. If you want to realize the full benefits, you must go all in. 

I am not qualified to offer advice on establishing a healthy exercise regime. But I do know a thing or two about GitOps and how to make the most of it. To that end, here’s a look at why going all-in on GitOps can be challenging, how you can overcome the challenges and why doing so is worth the effort. 

While you don’t strictly need GitOps to take advantage of API gateways, GitOps streamlines and scales the management of this key infrastructure in modern application architectures. 

To ground the discussion, I’ll focus on a common use case for GitOps today: Using it to manage APIs in conjunction with an API gateway, which helps to deploy, observe and secure APIs.

GitOps: Defining the Basics 

GitOps is the use of Git, the open-source version control system, as a single source of truth for managing infrastructure configurations. The goal behind GitOps is to replace manual configuration management with automated, code-driven workflows. 

When you do this, you gain a variety of benefits, such as: 

• A centralized source of truth — in the form of Git repositories — for infrastructure configuration 

• The ability to manage infrastructure using declarative configurations and apply changes automatically and continuously to ensure the current state has not diverged from the declared state  

• Simple and efficient collaboration, since everyone involved in configuring and managing infrastructure can operate from a centralized hub 

• The ability to track changes to infrastructure configurations over time using Git’s built-in version control features 

• Quick and easy rollbacks to an earlier configuration in the event you encounter a problem 

• The ability to validate configurations using software agents, frequently known as linters. 

For example, if you are operating an API gateway that you can manage using an infrastructure-as-code (IaC) approach, you can leverage GitOps to configure the gateway using code that you store in a Git repository. That makes it possible to scan and validate the code prior to applying the configuration. In addition, you can track changes to your configuration through Git, and everyone on your team can easily monitor and collaborate around management of the API gateway using Git as a centralized source of truth.  

The State of GitOps Adoption 

It is easy to talk about the benefits of GitOps. Adopting GitOps, however, can prove more challenging. Likely, more than 90% of organizations in a recent CNCF survey report that they are using GitOps to some extent, yet many have implemented it across just a fraction of their cloud-native deployments. Businesses are eager to adopt GitOps, but extending it across their IT environments is proving much more challenging. 

That’s a shame because the value of GitOps increases exponentially when you implement it systematically and consistently across your organization. When you can manage every cloud native deployment using a GitOps approach, as a consequence, declarative and automated processes become baked into your culture and transform your business. 

In contrast, a partial GitOps implementation might improve the efficiency of a few processes, but it won’t level up your overall operations. It will also leave you with inconsistent processes because some are managed via GitOps while others rely on manual techniques. And your teams will be caught in the middle, juggling disparate sets of tools — one set to enable GitOps and another designed for legacy operations. 

This is why GitOps should ideally be an all-in affair. Implementing GitOps here and there is better than not using GitOps at all, but you won’t come close to realizing the full potential of GitOps until it is a consistent, systematic process that extends to all facets of your business and operations. 

Overcoming GitOps Implementation Hurdles 

But again, going all-in on GitOps is easier said than done. Here are the main challenges businesses encounter, along with strategies for working past them. 

Workflow Changes 

Perhaps the most obvious challenge to implementing GitOps is the need to evolve workflows from traditional, manual approaches to ones rooted in Git. You must ensure that all stakeholders know how to work with Git and are prepared to make it their go-to solution for managing configurations. 

For example, if your goal is to manage an API gateway using GitOps, you need your engineers to be able to manage configurations for the gateway using code and to know how to manage that code in Git. 

 There is no magic bullet to solve this challenge overnight, but education is key. Organizations aiming for complete GitOps adoption should educate developers, IT engineers and anyone else who plays a role in configuration management in how Git works and how to use complementary platforms, such as GitHub or GitLab, which the business might use to store configuration code. In addition, education initiatives should explain why GitOps is so valuable, in order to achieve buy-in for full-scale GitOps adoption. 

Finding GitOps-Friendly Tools 

Because GitOps is a relatively new concept, not all tools work seamlessly with a GitOps-based approach to configuration management. Implementing GitOps is particularly hard in cases where you are working with tooling that has limited or no native support for declarative configuration management (meaning the ability to describe a desired state using code and enable it automatically). For instance, even if you use a platform like Kubernetes (which does support declarative configurations), you might pair that with a legacy API gateway within your stack that doesn’t natively support a GitOps approach because they are not designed to be managed using code and declarative configurations. 

In some cases, you can work around this issue by installing add-ons or using additional tools to enable a declarative approach in environments that don’t otherwise support it. However, this solution requires a lot of effort to implement, and it also increases the complexity of your operations by adding more tools to the mix. 

A better solution to this challenge is to migrate to tools that are designed to support declarative configuration management natively. Today, you can find GitOps-friendly tools for virtually every layer of a cloud-native deployment stack, so there is no reason to settle anymore for software that doesn’t offer full-fledged support for declarative configurations. 

Managing Secrets 

Managing secrets, such as keys that help secure traffic flowing through an API gateway, can be challenging when implementing GitOps, because you ideally do not want to store secrets in plain text within the same code that you use to manage configurations. If you do, anyone who can view your configuration code will also be able to access your systems and resources. 

Fortunately, there are simple solutions to this issue. One is to use a secrets manager, which lets you store secrets outside your code repositories while still making them accessible for authentication requests. Another is to embed secrets in your configuration code but ensure they are encrypted to prevent unauthorized access. Either approach lets you connect secrets securely to a tool that you manage declaratively. 

Managing Complexity 

While GitOps simplifies and scales operations in some ways, it can also make processes more complex as it adds new types of resources (like code repositories) to workflows. This is one reason why teams sometimes feel tempted to stick with legacy API gateways that don’t support declarative configuration: Initially, such solutions can seem easier to manage as they don’t require learning a whole new workflow and additional tools. However, the organization eventually pays the price with a lack of speed and agility in the long run. 

Best practices for keeping things manageable include consistently naming resources, maintaining consistent folder structures for Git code and using tools like kustomize to apply configurations consistently across disparate environments. 

Linting configuration code (meaning automatically detecting formatting issues) and establishing systematic review processes can help, too. 

Collaboration and Communication 

To deliver maximum value, GitOps must be accompanied by cultural change within your organization. You can do this by actively encouraging teams to leverage GitOps as a means of streamlining collaboration and communication. Highlight as well how GitOps increases transparency and efficiency. 

Over time, stakeholders tend to appreciate the value of GitOps organically. But you might have to kick-start the process to help shift your mindset and culture toward a GitOps-centric approach. 

Disaster Recovery 

GitOps simplifies disaster recovery in the sense that you can easily restore configurations based on Git code. When things go wrong — when, for example, a change to your API gateway configuration leads to a spike in latency — just revert the problematic change to the previous working state, and now you have time to investigate and identify the root cause.  

To take advantage of this capability, however, you must integrate Git-based operations into disaster recovery and response plans. Most organizations that have disaster recovery strategies in place did not design those strategies with GitOps in mind. Therefore, you would need to update your playbooks and educate engineers to ensure they are prepared to make Git a key pillar of disaster recovery efforts. Reverting to a previous state must not be a fearful event but a confident exercise. 

API Management 

GitOps goes hand-in-hand with an API-first approach to workflows. API standards, such as the OpenAPI Specification (OAS), offer a consistent approach to defining and managing APIs across all stages of the API lifecycle. In this way, they bring more consistency and order to GitOps. 

Monitoring and Observability 

The ability to monitor and observe GitOps pipelines is crucial for getting ahead of issues that may disrupt GitOps workflows. For instance, if someone accidentally removes essential configuration code that your API gateway depends on, you would want to know quickly so that you can revert the change. 

As with API management, open standards help here as well. In particular, OpenTelemetry, or OTel, makes it easy to collect metrics, traces and logs consistently from any application or tool. 

GitOps for Legacy Systems 

A final challenge you may encounter when implementing GitOps is finding your IT estate includes legacy systems that just can’t be updated to support a declarative approach. 

The ideal solution, of course, is to update to modern systems that are fully GitOps-compliant. But if migration isn’t possible, there may still be ways to bring some of the benefits of GitOps to legacy environments. For instance, legacy monolithic apps that currently run directly on servers could be redeployed using containers and Kubernetes. They would still be monoliths, but you would be able to manage their deployment declaratively. 

Conclusion: Going All-In on GitOps 

Recognizing the value of GitOps is easy. Implementing GitOps systematically across a business can be much harder. But as I have explained above, it is feasible to conquer each of the main challenges that businesses typically encounter on their GitOps journeys. Don’t expect to go all-in on GitOps overnight but do expect that with the right planning and tools, transforming your organization through GitOps is well within reach.