service-mesh

Service Mesh

A service mesh moves cross-cutting network concerns — mTLS, retries, timeouts, traffic splitting, request-level observability — out of application code and into a shared sidecar proxy layer. That's a genuine architectural win once you have enough services that reimplementing retry logic in five languages is more expensive than running a mesh. It is also real infrastructure with its own control plane, its own failure modes, and a latency cost on every single request.

The mesh is worth it when the alternative is duplicating the same networking logic across many services; it's not worth it just because it's available. Adopt a mesh to solve a problem you already have, not one you're anticipating.

1. Justify the mesh against what NetworkPolicy and Ingress already give you

Plain Kubernetes already provides L3/L4 segmentation (NetworkPolicy) and L7 HTTP routing at the edge (Ingress). A mesh's value is specifically service-to-service L7: per-request retries, mTLS between every pod pair without app changes, and fine-grained traffic splitting for internal calls — if the actual need is "block namespace A from reaching namespace B," that's kubernetes-networking, not a mesh-sized solution.

• Small service counts (a handful of services) rarely justify the operational overhead — the same retry/timeout logic in a shared library is often less total complexity.
• Real triggers for a mesh: many services in multiple languages needing consistent retry/timeout/circuit-breaking behavior, a compliance requirement for mTLS everywhere, or fine-grained internal traffic shifting for progressive delivery.
• Write down the specific problem the mesh is meant to solve before adopting one — "observability" alone is rarely enough justification since most of it is achievable via distributed-tracing and metrics-and-monitoring without a mesh.

Done when: the decision to adopt (or not adopt) a mesh is backed by a named problem it solves that the existing stack can't.