Adoption of containers and container orchestrators is still very much on the vertical part of the exponential s-curve, with a growing amount of engineering organizations, including very large enterprises, moving most of their workloads to different flavors of Kubernetes (on prem, self-managed, managed-services).
This creates the need for increasingly safer ways of handling application and infrastructure configurations, improving the overall security of delivery setups. Back in 2017 the team at Weaveworks narrowly avoided an almost fatal disaster that would have caused them to lose vital parts of their codebase, if not for the fact they were able to roll back to the previous application state, stored in Git. Their CEO coined the term GitOps, describing it as an approach to prevent simple configuration mistakes by storing the state of apps (and their dependencies) as code in a system external to the application itself. Weaveworks open sourced the first GitOps operator, FluxCD, which was quickly followed by another OSS competitor a year later, ArgoCD. The industry immediately jumped on the GitOps hype train as the solution for better configuration management.
However, like with so many tech trends, a large amount of new vendors rapidly emerged trying to jump on the bandwagon, each pushing their own slightly different (or outright contrasting) definition of GitOps. This, alongside the lack of best practices, clear definitions and community leadership, led to a growing confusion in the industry, with established analysts like Thoughtworks downgrading GitOps to “On hold, proceed with caution” (i.e. better not use it) in their 2021 Technology Radar, before they put it on “Assess (“worth exploring”) in 2023. The very company that created it, Weaveworks, shut down in 2024. This uncertainty, combined with its inherent shortcomings around scalability, has historically made the adoption of GitOps in the enterprise very tricky.
Tides are turning at last. The industry has been consolidating around fewer vendors and clearer definitions in the last couple of years, while at the same time enterprises have been adopting platform engineering to improve their security and scalability posture around configuration management. GitOps, when paired with an Internal Developer Platform (IDP), is finally ready for the enterprise prime time. Let’s see how.
A quick definition
Let’s start with a clear working definition. GitOps is an operational framework that takes application development and delivery best practices such as version control and CI/CD, and applies them to infrastructure automation in a declarative way.
According to https://opengitops.dev/, there are four key GitOps principles:
- Declarative: A system managed by GitOps must have its desired state expressed declaratively.
- Versioned and Immutable: Desired state is stored in a way that enforces immutability, versioning and retains a complete version history.
- Pulled Automatically: Software agents automatically pull the desired state declarations from the source.
- Continuously Reconciled: Software agents continuously observe actual system state and attempt to apply the desired state.
This sounds straightforward and pretty great in theory. You have “everything as code” versioned in Git, which is the single source of truth of your setup.
It’s important to mention though that just because you configure stuff as code, it doesn’t mean you do GitOps. Many teams like to say “they do GitOps”, when really all they are doing is leveraging Git enabled workflows that allow developers to stay in code and have that as the single source of truth. They don’t however use an operator like ArgoCD to sync their configs as code to their Kubernetes clusters, enabling things like air-gapped environments and leading to a higher degree of security and compliance.
The challenges and possibilities of GitOps
If you want to move past Git-based workflows into doing proper GitOps (working at enterprise scale), you should be mindful of the challenges this comes with. While there have been great improvements around setup maintainability from an operations team perspective, GitOps still does very little in the way of enabling developer self-service, i.e. true enterprise-level scalability.
In fact, it’s quite the opposite of it. In a GitOps setup developers need to declare everything, even the smallest implementation details, forcing them to understand the application and all its dependencies in depth. This not only keeps all the cognitive load on the app developers, it also creates high risks in terms of security and compliance across the entire engineering organization.
So how can GitOps be useful for a large enterprise when it can have such a negative impact on developers’ cognitive load and your security posture? You guessed it. When combined with an enterprise-grade IDPs built with a Platform Orchestrator.
Scaling GitOps for the enterprise
It’s no coincidence that companies in highly regulated industries are first movers towards a mix of GitOps and platform engineering. Both Palantir (see their Platform Engineers talk) and Bechtle (see full case study or their latest KubeCon talk) serve government clients with high security requirements, and have successfully combined GitOps and platform engineering to do so.
Bechtle for example leverages the code-based interface Score to shield developers from the complexity of the underlying GitOps setup. Developers simply request the dependencies their workloads need to run (e.g. postgres, s3 or dns below), without having to worry about any implementation details (e.g. which version of postgres for which environment).
The Platform Orchestrator then resolves the abstract request of developers against the rules and baselines set by the Ops and platform teams. It creates fresh app and infrastructure configs with every deployment, based on the resource definitions set by the platform team for each environment type.
Integrating GitOps and platform orchestration this way lets you standardize app and infra configurations and establishes a clear separation of concern between devs and Ops. This leads to 95% less config files and makes your GitOps setup way easier to maintain and scale with (securely!).
How to get started?
Despite the turmoil and challenges of the last few years, GitOps is here to stay. When combined with platform engineering, it has the power to deliver immense value for enterprises working in environments that require a high degree of security and compliance.
Build an Internal Developer Platform with Humanitec to get all the benefits of GitOps, at enterprise scale. You can get started right now through the Humanitec Minimum Viable Platform program.
