GitOps: From Tribal Knowledge to Auditable Infrastructure

Infrastructure used to be full of stories that began with, “Ask Alex, they know how that server works.”

Someone had installed a package over SSH, changed a configuration file during an incident, added a cron job six months later, and opened a firewall port that nobody documented. The server might have been stable for years, but its real configuration existed partly on disk, partly in a ticket system, and partly in one person’s memory.

We improved this model with scripts, configuration management, Infrastructure as Code, and immutable images. GitOps takes the next step: it turns Git into the reviewed and versioned declaration of what our systems should look like, then uses software agents to continuously reconcile reality with that declaration.

That makes GitOps much more than “YAML in a repository.” It is an operating model for making infrastructure visible, reproducible, auditable, and less dependent on privileged individuals.

Vendor Lock-in: Why It Is Not Always Bad and How to Manage It Deliberately

Vendor lock-in is not about using a vendor. It is about losing room to move.

A company does not become trapped merely because it runs workloads on AWS, buys a SaaS product, uses a managed database, or adopts a proprietary development tool. Those are ordinary technology decisions. Lock-in begins when leaving becomes so expensive, risky, slow, or organizationally painful that changing direction is no longer a practical option.

That distinction matters because vendor lock-in is often discussed as if it were a moral failure. It is not. It is an architectural, operational, and business trade-off. Sometimes the dependency is dangerous. Sometimes accepting it is the fastest and most economical way to build a reliable product.

The real task is not to avoid every dependency. It is to understand which dependencies we are creating, what value they provide, and whether we could still change course if the assumptions behind them stopped being true.

What You as a Dev Should Know About Kubernetes

Silos have a bad reputation in software organizations. They are blamed for slow delivery, poor communication, and tickets being thrown from one team to another.

But silos are not automatically bad. Complexity requires specialization. A developer cannot understand Kubernetes as deeply as an SRE while also owning product logic, APIs, data models, tests, UX concerns, and business requirements.

The problem is not specialization. The problem begins when specialization becomes an excuse to stop caring at the team boundary.

Managing Multiple Kubernetes Clusters with Flux

Running one Flux-managed cluster is useful.

Running three Flux-managed clusters from the same repository is where the repository structure starts to matter.

The moment you have dev, test, and prod, you need to answer a very practical question:

Which cluster should receive which namespace, app, policy, and controller?

Installing Kyverno and Capsule with Flux

A local Flux setup becomes much more interesting once it manages more than demo applications.

In the previous article, Learning GitOps with Flux, k3d, and the Flux CLI, I used a small k3d repository to explain the basic reconciliation loop. This article builds on that idea and adds two tools that make a cluster feel more like a platform:

• Kyverno for policy enforcement
• Capsule for Kubernetes multi-tenancy