GitOps is not a religion: it's just a tool
GitOps started as a good idea. Declarative state stored in Git. Reconciliation loops keep your systems honest. Infrastructure as code, with traceability, rollbacks, and peer-reviewed changes. Who wouldn't want that? But somewhere along the way, GitOps became dogma. The belief took hold that "if it's in main, it must be true". That Git is the single source of truth, and that production should always converge to the current commit. That if you just reconcile harder, you'll get stability, predictability, Nirvana. That's the lie. Because if that were true, we wouldn't have bugs. And if you've been in software for more than five minutes, you know: the only bug-free system is the one that hasn't been written. GitOps doesn't prevent bugs. It just records them.
When Git becomes the bottleneck
Now picture this: you're in the middle of a production outage. A service is misbehaving. Latency is through the roof. Users are impacted. War room, your manager shouting, your colleagues crying. You find the issue, patch a fix locally, and validate it.
But: wait, to apply the change, you have to:
Velocity matters. Context matters. In high-stakes moments, GitOps becomes ceremony. It slows you down. It punishes intuition. And it hides complexity behind the illusion of "declarative simplicity".
GitOps is for infrastructure. Not everything is Infrastructure.
I admit it, the previous example was a bit too out of context. Not all working environments are so toxic: sometimes, slowing down is the best option to tackle the problem and fix the root cause.
We're on The Platform Brief, and sometimes we talk about Infrastructure, where GitOps shines at its best.
Kubernetes cluster bootstrap? GitOps.
CNI/CSI plugins? GitOps.
Monitoring agents? GitOps.
These components are relatively static, versionable, and detached from end-user behaviour: the good candidates for immutable, declarative workflows.
But not applications.
Applications are runtime data. They are created from human intervention. They depend on inputs that exist outside the Git universe.
Expecting Git to represent that world is like expecting your MySQL schema migration file to include the binary logs.
We don't commit the database contents into Git. We shouldn't do it for app state either.
A tool, not a silver bullet
GitOps is not a strategy. Neither a product. Bold statement: it's not even a best practice.
It's a tool.
And tools solve specific problems. When we treat them like religion, we force-fit them everywhere. GitOps became the hammer, and suddenly every deployment problem started to look like a nail.
But the world is complex. Can you imagine if every EC2 action you perform on AWS is committed to a single Git repository?
Platforms are products. Not just a pile of ̶s̶h̶YAML
A platform isn't just tech: it's a product. And users don't give a heck about the internals. They care about outcomes.
No one buying a car wants to hear how the fuel injector mixes gas with air. They want performance, comfort, and experience. The same goes for good platforms.
When you're building a platform, GitOps is just one of many implementation details. It can enable stability. It can improve traceability. Accountability, especially.
But if you centre your platform around Git instead of the developer experience, you've already lost.
Use GitOps: don't worship it
By all means, use GitOps. But use it like a scalpel, not a sword.
Use it for things that benefit from reconciliation. Avoid it when it slows down recovery.
And most importantly:
Don't let Git dictate your product. Let your product dictate how you use Git.
That's the difference between tools and dogma. That's the difference between infrastructure and platform.
And that's how you build systems that serve people, not processes.
GitOps holds and works because in our infinite brilliance. We made infrastructure a Yaml-spaghetti mess. Because from the good idea that infra and platform could be versioned to the likes of code, we took everything from dev practices called it cloud-native and refused the tools and methods that we already have and called them obsolete or legacy….and when we’re asked what about the data?…we say - that’s the application responsibility…. Things like Sveltos, ConfigHub are the transition to a response to solve this problem. My humble opinion
Love this take! It's a horrible feeling when prod is down and you're praying that your (probably slower than it should be) CI passes so you can roll out a fix. Or, you just open whatever escape hatch you've built in, and do something manual on the server 😱
Platform Architect @ Trace3 | PreSales and DevOps culture
2moBut all of my AI agents worship git. They even built an altar: https://github.com/idosal/git-mcp
Engineering Leader | AI Infrastructure | Networking & Observability
2moI would say GitOps is a concept, a methodology to use Git as reference to simplify keeping track of versions across hundreds if not thousands of services deployed potentially across multiple clusters or cloud environments. Thus, GitOps can be very powerful if used with proper tooling and automation or it can be a bottleneck if not implemented properly. In the example, the steps shown can be easily automated so it may not be fair to say GitOps cannot be used for rapid deployment or cannot be used for deploying applications.