Gateway and service mesh

The gateway and the service mesh both route traffic, apply policies and produce telemetry. They do not handle the same axis: the gateway handles inbound traffic, between different trust domains. The mesh handles traffic between services inside one domain. Setting them against each other is a framing error, the real question is whether the second one is worth its cost.

External consumers

Partners, public

Gateway

Border: authentication, quotas, contracts

Internal mesh

Service A

mTLS, identity, telemetry

Service B

mTLS, identity, telemetry

How the roles split

The mesh gives every internal connection a service identity, mutual encryption and retry policies, without touching application code. It knows nothing of contracts or consumers: it does not replace the API platform, it equips the network that platform does not see.

What sidecarless changed

The historical cost of the mesh was the sidecar: one proxy per container, memory and latency everywhere. A second model has taken hold alongside it, without replacing it: one agent per node carrying identity and encryption at transport level, and application-level proxies deployed only where fine-grained routing is needed.

Istio has offered it in general availability since 1.24 under the name ambient mode, stating explicitly that sidecars remain fully supported. Linkerd, the other CNCF graduated mesh, keeps the sidecar model. So there is no dominant model, there is one more choice.

The gain is real and gets measured in your own environment rather than in a blog post: the same project quotes a user report of 45% fewer containers and savings beyond 90% on certain use cases, which is too wide a spread to be an argument. The real change is elsewhere: adoption stops being all or nothing. Identity and encryption everywhere first, advanced routing next, on the perimeters that need it and no others.

One clarification that heads off a disappointment. The per-node agent works at transport level and does not read HTTP: anything to do with a header, a route or a return code calls for an application proxy on top, deployed per namespace rather than per service.

At the same time, the Kubernetes Gateway API has become the common language: the same routing resources describe cluster ingress and, through the GAMMA initiative, traffic between services. Configuring ingress and the inside with the same vocabulary narrows the skill gap between the two worlds, and it has become a criterion when choosing tooling.

When the mesh is not worth its cost

The mesh stays a piece of infrastructure, with its own version upgrades and its own failure modes. Three situations where doing without it is the right call:

• few services, one team: the real need is mTLS, which can be had more simply.
• no well-run Kubernetes platform: the mesh assumes an established platform team.
• the network already carries the essentials: modern network layers encrypt traffic between nodes and produce basic telemetry with no extra layer. The caveat is that this is transport encryption, not a workload identity per application connection, and that coverage takes hold after a peer has been discovered, not before.

The reverse holds too: beyond a few dozen services, reimplementing retries, timeouts and encryption in every application costs more than the mesh that pools them.

What belongs in neither

Business logic, in both cases, for the reason set out in mediation. And fine-grained authorisation: the mesh authenticates services, the gateway authenticates applications. Whether a given user may see a given record stays in the service code, see access.