Home

The Case Against GitOps: Moving Toward Dynamic Control Planes

For nearly a decade, GitOps has been the gold standard for platform delivery. The "Git as the single source of truth" mantra is embedded in almost every modern IaC stack. We assume that the safest way to deploy is to have every change tested, reviewed, and merged before it touches a cluster.

But while development teams moved to feature flagging and dynamic "at-rest" configuration years ago, Ops remains stuck in a cycle of heavy PR workflows for even the smallest configuration tweaks. I’d argue that the only reason for this is a lack of adequate tooling—a gap that modern control planes like Crossplane are starting to fill.

GitOps is for Intent, Not Reality

Accepting GitOps as the exclusive source of truth is a limitation. In the real world, configuration isn't static. We already accept on-the-fly changes in the form of HPAs, VPAs, and mutating webhooks. Why stop there? Why can’t our infrastructure react to the state of other services in real-time, without waiting for a human to merge a PR?

The Dynamic Control Plane in Action

Imagine a scenario where your infrastructure automatically scales or adjusts its security posture based on metadata stored in your developer portal. I recently prototyped function-backstage, a Crossplane composition function that reads a label on an incoming resource request and fetches its corresponding entity from the Backstage catalog.

This allows for server-side decision making that GitOps simply can't handle. For example:

  • If a service’s developmentStage in Backstage is experimental, provision a cheap CNPG Postgres cluster.
  • If it’s stable, provision an AWS RDS instance with multi-AZ and high-availability enabled.

The developer never changes their "intent" (they just ask for a Database), but the reality of what is provisioned changes based on the context provided by the platform.

Guardrails over PRs

The biggest shift here is from "Human-in-the-loop" (reviewing every PR) to "Guardrails-in-the-loop" (authoring the logic that governs the system). Platform teams assume the responsibility of building and testing the logic (Compositions and Functions), while development teams take full control over the requests (XRs).

This enables true self-service. Because the guardrails are baked into the control plane, a developer can move fast, push to production, or experiment with new services safely, knowing that the platform team’s logic is enforcing compliance and security at the API level.

Conclusion: GitOps is a tool, not a religion

GitOps is still incredibly valuable for testing and reviewing the core logic of our platforms. But for the day-to-day operation of a dynamic environment, it's often overkill. We should move away from the bottleneck of the PR and toward a future where our platforms are as dynamic as the applications they support.

We build the guardrails, and then we get out of the developer’s way.