DEV Community: Valerio Uberti

Your Microservices Are Hiding a Second Codebase (And Istio Deletes It)

Valerio Uberti — Fri, 31 Jul 2026 06:08:35 +0000

Split a monolith into 20 microservices and you don't just multiply deployables, you multiply every cross-cutting concern. TLS, retries, timeouts, trace propagation: suddenly each service carries hundreds of lines of networking code that has nothing to do with your business.

That's a shadow codebase, and it's usually the least differentiated code you own. Nobody buys your product because your retry logic is elegant.

The standard fix a shared SDK works until you have more than one language. Then it forks: a Go SDK, a Java SDK, a Node SDK, each implementing "the same" policy slightly differently, each upgrade a rolling migration across every repo.

A service mesh moves all of it into the infrastructure layer:

mTLS + workload identity — automatic certificate issuance and rotation, zero app code [web:4]
Uniform retries/timeouts — declared once in YAML, enforced everywhere
Free observability — metrics, traces, and topology with Prometheus/Jaeger integration out of the box [web:10]

The honest costs: ~60MB + 0.2 vCPU per sidecar [web:15], added latency per hop (independent benchmarks show +166% for sidecar mTLS vs +8% for ambient mode [web:6]), and a new production system to operate.

Full write-up with annotated PeerAuthentication / AuthorizationPolicy / VirtualService YAML, benchmarks, and a "when NOT to use a mesh" decision framework:

👉 Your Microservices Are Hiding a Second Codebase — full article

One-line version: a service mesh doesn't make services smarter; it stops them from pretending to be network engineers.

Are you running a mesh in production, or still maintaining networking SDKs per language? What broke first? 👇

Terraform Should Not Deploy Into EKS. ArgoCD Should.

Valerio Uberti — Wed, 29 Jul 2026 10:17:01 +0000

Many teams use Terraform to provision AWS and then keep going: Helm charts, namespaces, add-ons, even application manifests inside EKS.

That looks efficient. It is actually the fastest way to blur the boundary between infrastructure and platform.

The better model is less convenient at first:

application repo for source code and builds;
ops repo for Terraform and GitOps manifests;
Terraform limited to AWS and the EKS perimeter;
ArgoCD responsible for everything inside the cluster.

The real issue is lifecycle mismatch. VPCs, IAM roles, and node groups change slowly. Kubernetes manifests, platform add-ons, and image tags change constantly. Forcing both layers through Terraform turns infrastructure provisioning into a release engine.

That is where things break:

application deploys inherit infrastructure risk;
rollback becomes heavier than it should be;
Terraform and ArgoCD can end up fighting over the same cluster state;
CI pipelines need cluster credentials they should never have.

I wrote the full breakdown here, with repository structure, Terraform examples, ArgoCD manifests, and the exact deployment flow:

👉 Read the full article

Removing kubectl from CI Pipelines: A Slower, More Honest Deployment Model

Valerio Uberti — Mon, 27 Jul 2026 13:11:30 +0000

Most teams adopt ArgoCD to speed up Kubernetes deployments. The real value is that it slows them down. The shift from push-based CI/CD to pull-based GitOps introduces a 45–60 second reconciliation lag — and eliminates an entire category of incidents.

The full breakdown (with code, benchmarks, and the culture gap every platform team hits) is on my blog:

👉 Read the complete article here

Here is the thesis: a CI pipeline should not touch the cluster. It should touch Git. ArgoCD, running inside the cluster, should be the only component that applies manifests.

The counter-intuitive part: this adds latency. A 50-second sync lag feels like a regression. But what teams lose in speed, they gain in honesty automatic drift detection, rollbacks as git revert, and zero cluster credentials in CI.

Consider an internal platform serving ~80 engineers. Before GitOps, the platform team fields ~8 support tickets per month just answering "what is actually running?" After the move, that number drops to zero. The trade-off is correct.

If a platform team is still running kubectl apply from GitHub Actions, this is worth reading.

Tags: #kubernetes #gitops #argocd #devops #platform-engineering