Write down the required behavior
A service mesh can provide communication policy and telemetry across participating workloads. The useful comparison starts with the traffic you need to protect: protocols, identities, authorization rules, retries, routing and failure recovery.
Installing a mesh does not prove that every connection is encrypted or authorized. Unmeshed workloads, excluded ports, external endpoints and deployment modes all affect coverage.
Compare architecture before resource figures
Istio supports a sidecar model and an ambient model. In ambient mode, ztunnel provides the Layer 4 foundation, while waypoint proxies supply supported Layer 7 features such as HTTP routing and richer authorization. A ztunnel-only deployment should not be credited with every L7 capability. Istio waypoint requirements.
Linkerd provides workload proxies and policy resources. Its version 2.18 documentation explicitly supports authorization for services and HTTP routes, including workload identity conditions. The earlier claim that it lacks fine-grained authorization was incorrect. Linkerd authorization policy.
Linkerd also documents dynamic request routing; evaluate the supported route matches and Gateway API resources for the selected version instead of assuming all header-based behavior requires a separate ingress product. Dynamic request routing.
Cilium's service mesh capabilities combine its networking foundation with proxy functionality where needed. Inspect the Envoy role and the selected deployment arrangement when evaluating L7 features. “eBPF-based” does not mean all application-layer processing happens in the kernel. Cilium service mesh.
Test one representative policy
Consider an internal inventory endpoint that should accept requests from ordering but reject another workload. Build a small acceptance matrix:
| Caller or condition | Expected outcome |
|---|---|
| Authorized workload identity | Request reaches the application |
| Different workload identity | Rejected by the intended policy |
| Unmeshed caller | Explicitly allowed or rejected according to requirements |
| Health probe | Remains functional through the documented exception |
| Missing proxy or enrollment | Deployment behavior is understood |
| Certificate rotation | Traffic and identity recover as intended |
Also test application authorization. A permitted service identity does not prove a caller may access every customer's inventory reservation.
Treat retries as business behavior
A proxy retry can be useful for an eligible transient failure. It can also duplicate a mutation or amplify overload. Configure retryable operations, deadlines and budgets according to the application contract.
Avoid stacking independent retry policies in client, gateway and mesh without understanding the combined attempt count. Observe the actual dependency traffic when injecting a controlled delay in a test environment.
Measure the operating cost
Compare CPU, memory and latency under the same traffic, encryption, connections, telemetry and policy settings. Include the control plane and any waypoint or node-level components. Idle per-Pod figures from unrelated configurations are not a fair ranking.
Evaluate upgrades, troubleshooting, certificate handling, failure recovery and the team's familiarity with the system. Service count alone is not a useful adoption threshold.
The result should be a documented fit for required behavior and operating capacity. No comparative performance benchmark or client deployment is claimed in this article.
Sardar Mukhshaf
Full-Stack & DevOps Engineer
I build scalable web applications, secure backend systems, and production-ready cloud infrastructure. My engineering focus spans interface design, API architecture, deployment pipelines, and observability. Follow for more deep dives into system architecture, performance engineering, and emerging technologies.
More from the practice
Keep the useful ideas close.
Follow new articles with your preferred RSS reader.
Open the RSS feed ↗
