What do Istio, Linkerd, and Cilium have in common, and why do teams keep arguing about which one to pick? They are all service meshes — infrastructure layers that handle the traffic between your services so your application code doesn’t have to. The idea sounds simple until you try to choose one. There are sidecar meshes, sidecar-less meshes, managed meshes, and meshes that quietly got archived. This guide walks through the most important service mesh examples in use today, what each one actually does, and where teams commonly trip up.
What a Service Mesh Actually Does
Before comparing names, it helps to be clear about the job. A service mesh moves concerns like mutual TLS (mTLS), retries, timeouts, traffic splitting, and telemetry out of application code and into a dedicated infrastructure layer. Most meshes do this with a data plane (proxies that sit next to or inside each workload) and a control plane (the component that configures those proxies).
That split is the reason meshes exist. Instead of every team reimplementing retry logic, the platform team configures it once. The trade-off is operational complexity, and that trade-off is exactly what separates the examples below.
Istio: The Reference Example Most People Cite
Istio is the mesh most people picture when they hear the term. It launched publicly in May 2017, built by Google, IBM, and Lyft. It reached version 1.0 in July 2018 and became a graduated project of the Cloud Native Computing Foundation (CNCF) in 2022.
Istio uses Envoy sidecar proxies and a control plane called istiod. It covers traffic management, security through automatic mTLS, and observability. The official Istio documentation explains the architecture in plain terms, and it is worth reading before you commit to any mesh.
Teams pick it because its feature set is the broadest of any open-source mesh, its surrounding tooling and integrations are extensive, and most managed offerings are built on it. Teams hesitate because the learning curve is real, and a default installation adds a proxy to every pod, so you have to plan for the memory and CPU overhead.
Linkerd: The Lightweight Alternative
Linkerd came out in 2016, which makes it one of the earliest service meshes. Version 2.x was rewritten around a Rust-based micro-proxy called linkerd2-proxy, and the project became a CNCF graduated project in July 2023.
The pitch is simplicity. Linkerd installs with fewer moving parts than Istio, ships with sensible defaults, and its proxy is deliberately small. The Linkerd overview page lays out the architecture and feature set if you want the details. (What is Istio?)
In practice, Linkerd tends to suit teams that want mTLS, retries, and golden-signal metrics without adopting a full traffic-management platform. It is a narrower tool, and that is the point.
Envoy: The Proxy Underneath Many Meshes
Envoy is not a mesh by itself, but it deserves a place in any list of service mesh examples because so many meshes are built on it. Lyft open-sourced Envoy in September 2016, and it became a CNCF graduated project in 2018.
Envoy is a high-performance L7 proxy with dynamic configuration, rich load-balancing policies, and deep observability. Istio, Consul, Kuma, and others all use it as their data plane. The official Envoy introduction is the best starting point for understanding what the proxy layer actually does.
The practical lesson: when you evaluate a mesh, you are often really evaluating two things — the proxy and the control plane wrapped around it.
Consul: Service Mesh for Mixed Environments
Consul from HashiCorp added mesh capabilities with Consul Connect, announced around 2018. Consul’s advantage is that it started as a service discovery and configuration tool, so the mesh fits into environments that already use it.
Consul supports sidecar proxies as well as agentless modes, and it works across Kubernetes, virtual machines, and bare metal. That matters for organizations that are only partway through a container migration. The Consul Connect documentation covers the model in detail.
If your estate is a mix of Kubernetes and legacy VMs, Consul is often the example that fits without forcing a full replatform.
Kuma: Envoy-Based and Multi-Platform
Kuma is an open-source mesh from Kong, first released in 2019 and now a CNCF sandbox project. It is built on Envoy and supports both Kubernetes and VM workloads.
Kuma’s distinguishing feature is that it packages the control plane as a single binary that can run in multiple modes, including a standalone mode for local testing. That lowers the barrier to trying a mesh without standing up a full cluster. The Kuma documentation walks through the deployment modes.
Cilium Service Mesh: The eBPF Approach
Cilium takes a different path. Instead of sidecar proxies, it uses eBPF in the Linux kernel to handle networking, security, and observability. Cilium became a CNCF graduated project in October 2023, and its service mesh capabilities are documented in the Cilium service mesh docs.
The appeal is performance and simplicity: no sidecar per pod means less overhead and fewer containers to manage. The catch is that eBPF requires a modern kernel and a team comfortable with a different mental model. Cilium is a strong example of where the mesh category is heading.
AWS App Mesh: A Cautionary Example
AWS App Mesh launched at re:Invent in late 2018 as a managed mesh for AWS workloads. It is worth including because it illustrates a real risk: managed services get retired.
AWS has announced end of support for App Mesh, with support ending around September 2026. Teams still running it need a migration plan, and that plan usually points to Istio-based options or to Cilium. The App Mesh user guide is the place to confirm current status before making decisions.
The broader lesson applies to every managed mesh: ask what happens if the vendor walks away.
Google Cloud Service Mesh and Open Service Mesh
Google Cloud Service Mesh, formerly Anthos Service Mesh, is a managed, Istio-based offering. Google rebranded it to Cloud Service Mesh around 2024. It gives you Istio’s capabilities with Google managing the control plane, which removes a chunk of operational work. The Cloud Service Mesh overview explains what is managed and what is not.
Open Service Mesh (OSM) is the opposite story. Microsoft led the CNCF sandbox project, announced in 2020, and later archived it in 2023 in favor of Istio-based offerings. OSM is a useful example of a project that lost its maintainer momentum, and a reminder to check a project’s activity before betting on it.
Traefik Mesh: The Lightweight Non-Sidecar Option
Traefik Mesh, formerly Maesh, comes from Traefik Labs and was first released around 2020. It is a lightweight mesh that does not use sidecars by default, relying instead on a per-node proxy model. The Traefik Mesh documentation covers the trade-offs.
It suits smaller clusters or teams already using Traefik for ingress who want basic traffic control without a heavy control plane. It is not trying to compete with Istio on features, and it doesn’t pretend to.
Side-by-Side Comparison
| Mesh | Data plane | Governance | Best fit |
|---|---|---|---|
| Istio | Envoy sidecars | CNCF graduated | Broad features, large platforms |
| Linkerd | Rust micro-proxy | CNCF graduated | Simplicity, fast adoption |
| Consul | Envoy or built-in | HashiCorp | Mixed Kubernetes and VM estates |
| Kuma | Envoy | CNCF sandbox | Multi-platform, single binary |
| Cilium | eBPF, no sidecar | CNCF graduated | Performance, kernel-level networking |
| AWS App Mesh | Envoy | AWS managed | Legacy AWS setups (end of support near) |
| Google Cloud Service Mesh | Envoy (Istio) | Google managed | GCP-native Istio without ops |
| Traefik Mesh | Per-node proxy | Traefik Labs | Small clusters, ingress-adjacent |
Common Mistakes When Choosing a Mesh
The first mistake is picking the mesh with the most features. Feature count is not the same as fit. A team of five running twelve services rarely needs Istio’s full traffic-management surface.
The second is skipping the ownership question. A mesh is infrastructure, and infrastructure needs an owner. Before a pilot, decide who runs upgrades, who debugs proxy issues at 2 a.m., and who pays for the extra compute. The question of who owns an AI service after the pilot follows the same logic, and the ownership conversation is worth having before, not after.
The third mistake is underestimating capacity. Every sidecar consumes memory and CPU, and the control plane needs headroom too. Planning capacity for a new cloud service is a good primer on the sizing math, and the same discipline applies to mesh rollouts.
The fourth is ignoring the roadmap. App Mesh and OSM both show what happens when a project’s backing changes. Check release cadence, maintainer count, and CNCF maturity before you commit.
What Works in Practice
Start with one namespace, not the whole cluster. Enable mTLS in permissive mode first and watch for breakage. Measure latency before and after — the proxy hop is not free. Keep the control plane version pinned and upgrade on a schedule. And write down why you chose the mesh, because in eighteen months someone will ask. Industry news on platform tooling moves fast, and keeping an eye on project announcements helps you spot retirements early. (News)
Conclusion
The service mesh examples above fall into three rough camps: full-featured sidecar meshes like Istio and Consul, lightweight options like Linkerd and Traefik Mesh, and kernel-level approaches like Cilium. None is universally best. The right choice depends on your platform maturity, your team’s appetite for operational work, and how much of your estate lives outside Kubernetes. Pick the smallest mesh that solves your actual problem, verify the project’s health, and plan the rollout in stages. That approach beats chasing the longest feature list every time.
Frequently Asked Questions
What is a service mesh in simple terms?
A service mesh is a layer of infrastructure that handles communication between services. It manages security, traffic routing, retries, and monitoring so individual applications don’t have to implement those features themselves.
Which service mesh is the most popular?
Istio is the most widely cited and most widely deployed open-source mesh. It has the largest feature set and the largest set of integrations, and many managed offerings are built on it. Popularity does not automatically make it the right fit for every team.
Do I need a service mesh for a small application?
Usually not. A handful of services can be managed with a good API gateway and standard libraries. A mesh starts paying off when you have many services, a need for consistent mTLS, or multiple teams that each need traffic control.
What is the difference between a sidecar mesh and a sidecar-less mesh?
A sidecar mesh runs a proxy container next to each application pod, which gives fine-grained control but adds resource overhead. A sidecar-less mesh, like Cilium’s eBPF approach, handles traffic in the kernel or at the node level, which is lighter but requires newer infrastructure.
Is AWS App Mesh being discontinued?
Yes. AWS has announced end of support for App Mesh, with support ending around September 2026. Teams using it should plan a migration to an Istio-based or eBPF-based alternative well before that date.
What should I check before adopting a service mesh?
Check the project’s release cadence, maintainer activity, and CNCF maturity level. Confirm the resource overhead on your nodes, decide who owns upgrades and debugging, and run a limited pilot in one namespace before rolling out cluster-wide.
The final question to ask is whether you need a mesh at all right now. If your services already handle retries and timeouts in code, and mTLS is covered at the ingress, a mesh may add cost without adding much. Revisit the decision when the number of services or teams grows past what shared libraries can reasonably cover. Documenting that reasoning today saves an awkward conversation later, when a new platform lead asks why the mesh exists and nobody remembers.
