@ahmetcantryk
Short answer: if you're running fewer than 20 microservices and don't have a dedicated platform team, you probably don't need a service mesh. A mesh gives you mTLS, fine-grained traffic policy, and rich observability — but for most teams, the operational cost of running it outweighs the real benefit.
What Does a Service Mesh Actually Give You?
A service mesh moves service-to-service (east-west) traffic management into an infrastructure layer independent of your application code. It buys you three things: automatic mTLS for encrypted, authenticated service-to-service communication; fine-grained traffic policy (canary rollouts, circuit breakers, retry rules); and centralized observability — automatic metrics, logs, and traces for every service call.
None of this requires touching your application code — the mesh injects a transparent proxy layer between services to make it happen. The catch is that transparency isn't free: every request now crosses one or more extra network hops, and each hop brings its own failure modes, upgrade cycles, and debugging complexity.
Sidecar vs Ambient: What's the Difference in 2026?
Short answer: ambient removes the per-pod resource and operational overhead sidecars carry, but it still needs an extra proxy layer (a waypoint) for L7 processing. The classic sidecar model injects a proxy container into every pod — that gives strong per-pod isolation, but memory and CPU cost scale linearly as your cluster grows.
Istio's ambient mode changes that model: a lightweight, shared L4 proxy (ztunnel) runs per node handling mTLS and TCP routing, and L7 processing (HTTP routing, retries, circuit breaking) is offloaded to separate "waypoint" proxies only for the services that need it. As of 2026, ambient mode is considered production-ready, and the Istio project moved ambient multicluster support to beta at KubeCon Europe 2026.
Model | Resource cost | Complexity | When it fits |
|---|---|---|---|
Sidecar (classic) | High, per pod | High isolation, high ops overhead | When you need strong per-pod isolation |
Ambient (ztunnel + waypoint) | Low, per node | Medium — waypoints need separate management | The default choice for most 2026 clusters |
No mesh (Gateway API only) | None | Low | Under 20 services, simple traffic needs |
Where Does This Overlap with the Gateway API?
Short answer: Gateway API manages traffic entering the cluster (north-south) with a standard vocabulary; a service mesh manages traffic between services (east-west) — they're complementary, not competing. Kubernetes' Gateway API has become the vendor-neutral standard for defining ingress traffic, and all three major meshes — Istio, Linkerd, and Cilium — support it.
The confusion starts when teams reason "we already use Gateway API, let's just add a mesh too" when all they actually need is north-south traffic control. Linkerd, for instance, is not an ingress controller — it relies on a separate edge proxy like Envoy Gateway or Traefik to bring traffic into the cluster and doesn't implement GatewayClass itself. If you already have Gateway API set up and your need is purely inbound traffic control, question whether you actually need east-west traffic management before adding a mesh on top.
# North-south traffic control only (no mesh required)
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
name: api-route
spec:
parentRefs:
- name: api-gateway
rules:
- matches:
- path:
type: PathPrefix
value: /api
backendRefs:
- name: api-service
port: 8080How Heavy Is the Complexity Tax?
Running a mesh adds three distinct costs: a learning curve, upgrade operations, and debugging difficulty. When mTLS certificate rotation fails, a waypoint proxy introduces a latency spike, or a version upgrade causes a traffic outage, that's now your platform team's problem — and if you don't have a platform team, it's nobody's problem until it becomes an outage.
That cost is a direct example of the "add complexity you don't need yet" trap we cover in our guide to common Kubernetes mistakes. Standing up a mesh today because you might need it later raises today's operational load without solving tomorrow's scaling problem.
What Can You Use Instead of a Mesh?
Each of the mesh's three core benefits has a lighter alternative. For mTLS, your cloud provider's native network encryption (in-VPC encryption, on by default in most regions on AWS, GCP, and Azure) or application-level mTLS libraries can be enough. For traffic policy, an API gateway via Gateway API covers most scenarios. For observability, application-level instrumentation with OpenTelemetry captures most of what a mesh automatically collects — we cover this in detail in our getting-started guide to OpenTelemetry.
From a platform engineering angle, this echoes the "golden path" principle we cover in our deep dive on platform engineering: give teams the specific capability they need — encryption, routing, observability — through the simplest path, instead of forcing a heavyweight infrastructure component on everyone.
Common Mistakes Teams Make in This Decision
The most common mistake is standing up a mesh today because "we'll need it eventually." A mesh brings more than a one-time setup cost — it adds an ongoing operational load: continuous version upgrades, certificate rotation monitoring, and waypoint proxy capacity planning. That load usually outweighs the benefit while your service count is still under 20.
The second common mistake is adopting a mesh purely for observability. The metrics and traces a mesh collects automatically look appealing, but instrumenting the same data at the application level with OpenTelemetry often delivers similar visibility with far less operational overhead — reaching for a mesh just for this conflates your observability need with your mTLS and traffic-policy needs, which are separate problems. The third mistake is rolling a mesh out as one big-bang migration across the whole cluster at once; piloting it in a single low-risk namespace first and measuring the real operational cost is the safer, evidence-based way to make the call.
Do You Need a Mesh: A Decision Test
If you answer "yes" to 3 or more of these, evaluate a mesh:
1. Do you run more than 20 microservices?
2. Is cross-service traffic managed by different teams?
3. Do compliance requirements mandate service-to-service encryption?
4. Is canary or A/B traffic splitting a frequent need?
5. Do you have a dedicated platform/infrastructure team?
Fewer than 3 "yes" answers: Gateway API plus application-level
instrumentation is probably enough — skip the mesh's complexity tax.Frequently Asked Questions
How do I get mTLS without a service mesh?
Your cloud provider's in-VPC network encryption (on by default in most regions on AWS, GCP, and Azure) provides a baseline; if you need stronger identity guarantees, you can integrate an identity framework like SPIFFE/SPIRE without running a full mesh.
Can a small team try Istio's ambient mode?
Technically yes, but for a small team the real question isn't "can we try it" — it's "who runs this in production." Ambient mode consumes fewer resources than sidecars, but managing waypoint proxies still requires platform expertise.
Is Gateway API alone enough?
If you're only managing traffic entering the cluster, yes — that covers most cases. If you don't need service-to-service traffic management, mTLS, or fine-grained internal traffic policy, there's no reason to go beyond Gateway API.
How hard is it to switch mesh implementations (say, Istio to Linkerd)?
Hard and risky — the two meshes use different proxy models, different CRDs, and different operational tooling. This kind of migration usually requires a gradual, cluster-by-cluster move rather than a single cutover.
