A Fortune 2000 once called me about a defect problem in their mainframe environment.
They’d made what seemed like a productivity upgrade — giving each developer their own virtual environment to modify their service individually.
On paper, it sped up individual work.
In reality, it broke their CICD process.
The integration testing that had been a natural part of every update was now bypassed. Developers could push faster, but collectively they were creating more defects because integration happened too late.
That’s the macro problem here: when each platform in your organization has its own delivery rules, the enterprise loses consistency — and quality suffers.
The macro problem: consistency across platforms
In most enterprises, code and configuration management isn’t a Kubernetes problem — it’s an enterprise problem.
A developer might:
Deploy a service to a VM on Monday.
Push changes to a Kubernetes microservice on Tuesday.
Update a SaaS integration on Wednesday.
If each of those platforms uses a different methodology for version control, promotion, and rollback, you’ve created friction and increased the risk of mistakes.
The challenge is aligning delivery methodologies across platforms so developers, operators, and auditors share a consistent mental model — no matter where the workload lands.
Where GitOps fits
GitOps answers this question for Kubernetes:
“How do we keep cluster state in sync with our declared state in source control — continuously, automatically, and audibly?”
It’s a methodology for Kubernetes and other declarative systems, but it’s not a universal concept.
If Kubernetes is the platform for your apps, GitOps can become the backbone of your software lifecycle.
If Kubernetes is just a platform, GitOps needs to slot into the same governance and delivery patterns your other platforms use — otherwise you’ve just created another silo.
FinOps analogy: Just as FinOps principles—visibility, accountability, optimization—must be adapted to cover your full portfolio, the principles of GitOps—declarative state, version control, automation—should inform your broader enterprise strategy, even if the specific tools are Kubernetes-native.
The tipping point for a formal GitOps project
Every org starts with GitOps as a practice — some conventions, a repo, a pipeline.
It becomes a project when:
More than a handful of people can change cluster state.
Environments multiply and manual promotion is too slow.
Risk and compliance teams start showing up with clipboards.
A single bad push can break workloads in multiple regions.
At that point, GitOps isn’t just a developer habit — it’s a platform capability that needs ownership, governance, and tooling.
Adapting GitOps to the existing methodology
If Kubernetes isn’t the platform in your enterprise, GitOps should ideally feel like an extension of your existing delivery methodology, not a completely separate one.
That could mean aiming for:
Consistent change review gates across all platforms.
Repository and branching strategies that align closely enough to reduce developer context-switching.
Unified audit trail formats so risk and compliance teams can trace changes from code to production without platform-specific detective work.
You may not get there perfectly — Kubernetes has its own quirks and patterns — but the closer GitOps aligns with your existing delivery disciplines, the less friction you’ll introduce for developers who work across multiple platforms.
The two dominant shapes of GitOps
Once you’ve addressed the macro problem and decided GitOps is worth formalizing, you’ll encounter two main operating models:
1. Central Console Model
One pane of glass for policy, authentication, and visibility.
Works well when governance and onboarding app teams are your top priorities.
A natural fit if your other delivery platforms also use centralized visibility and control.
2. Distributed Controller Model
Repeatable, per-cluster controllers with no central dependency.
Works well when scale and autonomy are more important than shared dashboards.
A natural fit if your other delivery platforms are operated with more local autonomy.
How this impacts Argo CD vs. Flux
Once you know which model aligns with your existing delivery methodology:
If your processes rely on centralized visibility and policy enforcement, Argo CD’s “Central Console” model will feel familiar and easier to adopt.
If your org already operates with distributed, platform-specific autonomy, Flux’s “Distributed Controller” model will match how you manage other delivery platforms.
While both tools can be adapted to either model, their core architectures and philosophies naturally align with these distinct approaches, making one a more natural fit than the other depending on your existing methodology.
My take
Don’t treat Kubernetes GitOps as a greenfield discipline.
Treat it as an extension of your enterprise code and configuration management strategy — one that plays nicely with the delivery platforms you already run.
The goal isn’t to make Kubernetes special. The goal is to make it just another lane on the same operational highway.