A Technology That Needs a Better Justification Story
Service mesh adoption in enterprise Kubernetes environments follows a pattern that should give architects pause. The capability generates significant enthusiasm in practitioner communities, appears in architecture reference models from cloud providers and platform vendors, and gets recommended in the context of any sufficiently complex microservices discussion. It also generates significant operational overhead, adds meaningful latency to inter-service communication, and requires expertise that most engineering teams do not have at the time they adopt it.
The organisations that have operated service meshes at production scale for two or more years have a more nuanced view than the pre-adoption enthusiasm suggests. They identify specific capabilities that the service mesh provides that they could not have achieved otherwise, and specific aspects of operational overhead that they underestimated at adoption time. The useful analysis is understanding which requirements produce the right answer of “deploy a service mesh” and which requirements produce the right answer of “solve the problem differently.”
What Service Mesh Actually Provides
Service mesh is an infrastructure layer that manages service-to-service communication in a microservices environment. It does this through a sidecar proxy pattern: a proxy container is injected alongside each service container, and all traffic in and out of the service passes through its proxy rather than going directly to and from the service. The control plane manages the configuration of all the sidecar proxies in the mesh.
This architecture provides four categories of capability that are otherwise difficult to implement in a microservices environment.
Mutual TLS (mTLS) for service-to-service communication is the most frequently cited security capability. In a default Kubernetes environment, traffic between services within the cluster is unencrypted. A service mesh with mTLS enforces encrypted, authenticated communication between all services in the mesh, ensuring that a compromised service cannot impersonate another service or eavesdrop on inter-service traffic. This is a genuine security improvement for environments where the security model requires encryption and authentication within the cluster perimeter, not just at the perimeter.
Traffic management capabilities include fine-grained control over how traffic is routed between service versions: weighted routing for canary deployments, retries and circuit breaking for resilience, and fault injection for chaos engineering. These capabilities exist in application frameworks and in Kubernetes itself in partial form; the service mesh provides them in a consistent, observable way across all services without requiring each service to implement them independently.
Observability across service-to-service traffic is the capability that is most consistently valued by organisations running service meshes at scale. The mesh proxy captures detailed metrics, traces, and logs for every inter-service call without requiring instrumentation changes to the services themselves. For a microservices environment where understanding latency distribution and error patterns across service dependencies is operationally essential, this observability capability is valuable.
Zero-trust network policy enforcement within the cluster uses the mesh identity model (where each service has a cryptographic identity tied to its service account) to enforce which services are allowed to communicate with which other services. This is a more granular and cryptographically robust network policy model than Kubernetes network policies alone provide.
When These Capabilities Justify the Overhead
The service mesh decision should be driven by which of these capabilities the organisation actually needs, not by whether the architecture feels sophisticated enough for a service mesh.
The mTLS requirement is justified by a security model that requires encryption and authentication within the cluster perimeter. Most enterprise organisations have this requirement in practice, because the Kubernetes cluster is not a trusted network boundary; workloads from different teams and different trust levels coexist in the same cluster. If this security requirement is real and explicitly stated, mTLS is difficult to achieve consistently at scale without a service mesh.
The traffic management capability is justified when the deployment model requires fine-grained traffic control that application-level solutions do not provide consistently across a polyglot microservices environment. A services environment where canary deployments are routine, where different services are owned by different teams with different technology stacks, and where consistent traffic management behaviour across all services is a reliability requirement, benefits from service mesh traffic management. An environment where traffic management is handled at the application layer consistently and well does not.
The observability capability is the hardest to justify in isolation because OpenTelemetry and distributed tracing instrumentation can provide most of the same visibility. Service mesh observability is most valuable in environments where adding instrumentation to every service is impractical: environments with many teams, many technology stacks, or a significant volume of uninstrumented legacy services.
The zero-trust network policy enforcement is justified where the security architecture requires per-service identity and cryptographic service authentication rather than IP-based network policy. This requirement is most common in regulated industries and in organisations with a formal zero-trust security programme.
When Service Mesh Is the Wrong Answer
Service mesh is the wrong answer when none of the capability requirements above are actually present, and the adoption is driven by architectural aspiration rather than specific need.
The environment with ten services, a single technology stack, OpenTelemetry instrumentation, and a security model that treats the cluster network as trusted does not have the requirements that service mesh addresses. Adding a service mesh to this environment adds operational complexity, introduces a potential point of failure, and requires expertise that the team will not develop efficiently because they do not use the capabilities regularly.
Service mesh is also the wrong answer as a first step in an immature microservices environment. The teams that try to adopt service mesh alongside Kubernetes adoption, CI/CD pipeline development, and observability instrumentation simultaneously are spreading scarce attention across too many new capabilities at once. Service mesh rewards operational maturity in its surrounding environment; it does not substitute for it.
Selling the Decision Either Way
The architecture conversation about whether to adopt a service mesh is more useful when it is framed as a requirements conversation than as a capability comparison. The specific questions that produce useful answers: does the security model require mTLS within the cluster? Does the deployment model require traffic control that application-level solutions cannot provide consistently? Is observability instrumentation of all services impractical without infrastructure-level capture? Is per-service cryptographic identity a stated security requirement?
If the answer to one or more of these questions is yes, and the organisation has the operational maturity to absorb the mesh’s operational overhead, the service mesh decision has a justification. If the answers are no, the overhead is not justified, and the specific needs should be addressed through the targeted solutions that serve them.
The architect who can have this conversation with precision, rather than defaulting to “the reference architecture recommends it,” is providing a more useful service than the one who recommends service mesh because it appears in the CNCF landscape at the right point.
Architecture decisions should be justified by requirements, not by reference models.