DevOpsDreams

Monorepo vs Multirepo for GitOps Manifests: A Practical Guide for Flux and Argo CD GitOps repository structure is not a style choice anymore. The right answer depends on how you split ownership, reconcile paths, and scale teams, controllers, and environments. TL;DR Monorepo versus multirepo is no longer a simple Git preference debate. GitOps tools care about ownership boundaries, reconciliation scope, and how quickly changes should move through the system. Flux can structure monorepos, repo-per-team, and repo-per-app setups, while source decomposition can split a single repository into smaller deployable artifacts with independent lifecycles. Argo CD uses Application paths, automated sync, health assessment, and sync waves to control how Git state becomes cluster state. The best design is the one that keeps ownership explicit, keeps blast radius small, and matches how your platform team actually operates. The Real Debate Is Not Monorepo Versus Multirepo GitOps has changed the quest...

Argo CD Auto-Sync and Health Checks: An Operator's Guide to Safe GitOps Reconciliation Auto-sync and health are not the same thing in Argo CD. This guide shows how reconciliation, pruning, self-healing, retries, health checks, hooks, and sync waves fit together in real clusters. TL;DR Argo CD auto-sync and health checks solve different problems. Auto-sync decides when the controller reconciles Git with the cluster, while health checks decide whether the resulting resources are ready, degraded, or suspended. In practice, you need both: automated sync with prune and self-heal keeps desired state converged, retry refresh helps failed syncs recover on new revisions, and health checks plus custom Lua logic make readiness visible to operators. Sync waves and hooks add ordering when resources depend on each other. The control loop most teams misunderstand Argo CD has two separate jobs that often get blurred together in day-to-day platform talk. The first is reconciliation. Should Arg...

Platform Engineering on AWS with EKS Blueprints and GitOps Platform engineering on AWS gets much clearer when Terraform owns day-0 infrastructure and Argo CD owns day-2 reconciliation. This guide shows how EKS Blueprints and the GitOps Bridge pattern create that boundary. TL;DR Platform engineering on AWS is easier to reason about when you separate responsibilities: Terraform provisions the EKS cluster, networking, IAM, and add-on metadata, while Argo CD continuously reconciles in-cluster applications and platform add-ons from Git. EKS Blueprints and the GitOps Bridge pattern make that handoff explicit by passing cluster context into Argo CD instead of letting Terraform and GitOps compete for the same resources. The result is a cleaner bootstrap flow, fewer ownership collisions, and a platform model that scales better across teams and environments. Platform Engineering Starts With Ownership, Not Tools The most common mistake in platform engineering is treating Terraform, EKS Bluepr...

AWS VPC Lattice: The Missing Service Layer Between VPC Connectivity and Application Routing AWS VPC Lattice is easiest to misunderstand when you treat it like another load balancer. The real value is a service-layer boundary for discovery, auth, routing, and observability across VPCs, accounts, and even on-prem entry paths. TL;DR AWS VPC Lattice is most useful when your problem is not raw network connectivity but service-to-service access control and routing across many boundaries. It gives you a service network abstraction, per-service listeners and target groups, IAM-backed auth policies, and request-level observability without forcing every team to hand-build PrivateLink, Route 53, and load balancer patterns from scratch. The important caveat is that it does not replace your VPC underlay, and some protocol choices, especially TLS passthrough, gRPC, and health checks, carry sharp constraints that you need to design for early. VPC Lattice works best when you treat it as a service a...

Gateway API vs Ingress: Why Modern Kubernetes Traffic Management Uses Attachment, Not Annotations Ingress is still valid, but it stopped evolving. Gateway API gives Kubernetes teams a cleaner resource model for shared edge infrastructure, richer routing, and safer multi-namespace ownership. TL;DR Gateway API is the practical successor to Kubernetes Ingress for teams that need more than host and path routing. Instead of collapsing infrastructure, TLS, and application routing into one resource plus controller-specific annotations, it separates concerns across GatewayClass, Gateway, and HTTPRoute. That gives platform teams explicit entry points, application teams structured routing rules, and both sides a safer attachment model for shared gateways. The result is better portability, clearer ownership, richer HTTP routing, and a migration path that does not require an all-at-once cutover. Gateway API separates infrastructure ownership from routing ownership, replacing annotation-heavy in...