TechOps Examples

Hey — It's Govardhana MK 👋

Welcome to another technical edition.

Every Tuesday – You’ll receive a free edition with a byte-size use case, remote job opportunities, top news, tools, and articles.

Every Thursday and Saturday – You’ll receive a special edition with a deep dive use case, remote job opportunities, and articles.

Top engineers at Anthropic and OpenAI say AI now writes 100% of their code.

If you're not using AI, you're spending 40 hours doing what they do in 4.

These 100+ Claude Code hacks fix that and help you ship 10x faster.

Sign up for The Code and get:

Powered by: Jobsurface.com

Browse 671 Worldwide Jobs Here →

Looking to promote your company, product, service, or event to 49,000+ Cloud Native Professionals? Let's work together. Advertise With Us

A platform team running GitOps for a single application usually starts with one repo and one cluster, and that setup works fine right up until a second cluster gets added for staging, then a third for a new region, then five application teams each want their own release cadence.

Nobody planned the repository layout for that scale, it just grew, and now a change meant for staging occasionally slips into production because the folder structure never made the boundary clear. Repository structure is the actual mechanism that prevents or causes this, not a stylistic preference.

The simplest possible setup keeps every manifest for every cluster in a single Git repository, watched by one controller running inside the cluster.

The controller here represents tools like Argo CD or Flux, both of which work by continuously polling a Git source, or reacting to a webhook, and reconciling the live cluster state to match whatever is committed. With one repo, there is exactly one place to look when something changes, one commit history, one set of pull request reviewers who see everything. This works well for a single team managing a small number of related services, since the overhead of cross repo coordination doesn't exist yet. The tradeoff shows up as the repo grows, a monorepo eventually holds manifests for services that different teams own, and a single permission model on one repo means every team either has write access to everything or has to route changes through a shared review queue that becomes a bottleneck.

The opposite extreme splits manifests across multiple Git repositories, typically one per application or one per team, with a single controller pulling from all of them.

Each Git Repo here belongs to a separate team or application, and each can have its own access controls, its own review requirements, its own release cadence, without touching any other team's history. A payments team can require two approvals and a security scan before merge, while an internal tooling team merges on a single approval, and neither policy leaks into the other's repo. The controller itself is still centralized, watching all three sources and reconciling each into the cluster, so the operational surface for the platform team stays in one place even as ownership fragments across teams. The cost here is indirect, cross cutting changes, a shared base image bump, a cluster-wide network policy, now require coordinated pull requests across every repo rather than a single commit.

Scaling from one cluster to many changes the picture again, since now the controller has to reconcile not just multiple repos but multiple clusters as well.

One central hub cluster runs the actual controller, pulling from every application's Git repo the same way the polyrepo model does, but instead of reconciling only its own local cluster, it pushes the resulting configuration out to a fleet of spoke clusters. This is the pattern behind Argo CD's ApplicationSet controller managing dozens of remote clusters registered against one central Argo CD instance, or Flux's multi cluster mode doing the equivalent. The advantage is a single control point, one place to check the health of every deployment across every cluster, one upgrade path for the GitOps tooling itself.

The single hub is also a single point of failure for the deployment pipeline specifically, if the hub cluster goes down, no cluster in the fleet receives new configuration, though already running workloads on the spokes keep running since the hub isn't in the live traffic path.

🔴 Get my DevOps & Kubernetes ebooks! (free for Premium Club and Personal Tier newsletter subscribers)