ra2 studio - Fotolia

Compare Linkerd vs. Istio for service mesh technology

To decide between Istio and Linkerd for a service mesh platform, consider everything from performance and ease of use to support from major public cloud providers.

A service mesh is an essential tool to deploy and manage distributed applications and services. Two of the most popular service mesh technologies are Istio and Linkerd -- and while they share some similarities, they also have unique differences IT teams need to know.

Both Istio and Linkerd use a sidecar proxy to handle communications between microservices. These proxies communicate with each other -- which forms the data plane of the service mesh -- while each microservice communicates only with its local proxy.

In terms of adoption and support for these sidecar-proxy service meshes, Istio -- a project that Google launched alongside IBM and Lyft -- is the leader. But Linkerd -- a project under the Cloud Native Computing Foundation -- has a leg up in some areas, including performance.

Architecture and networking

Both Istio and Linkerd are tied to Kubernetes, but Istio provides some support for non-container environments, such as VMs and external frameworks like Cloud Foundry and HashiCorp Consul. This advantage is minimal, however, given that containers have become the dominant way to frame applications for distributed deployment.

The Istio data plane is built on the Envoy sidecar proxy -- though it can work with other proxy tools -- which gives it a full and mature feature set for ingress and egress traffic control, as well as load balancing and custom traffic filters. Linkerd has its own proxy, which is lightweight and fast, but has minimal load-balancing capabilities and lacks ingress and egress control; teams must deliver those functions via a separate tool.

Sidecar proxy design pattern
A sidecar agent acts as a proxy for a software component.

The Linkerd community is committed to future data plane enhancements, but Istio and Envoy are also likely to advance. In terms of breadth of features, the Istio data plane wins, but Linkerd is faster. While the right host and careful cluster design in Istio can mitigate Linkerd's speed advantage, Istio's feature advantage seems insurmountable.

Virtual networking isn't an explicit part of either Istio or Linkerd; both presume that the Kubernetes environment defines the virtual network package used. As a result, the packages' virtual networking capabilities are equivalent. However, users consider many service mesh data plane features to be networking -- and, as mentioned above, Istio has the edge there. In addition, Istio provides extensions of its control plane across clusters and supports gateways between clusters.

Management, security and monitoring

Service mesh management capabilities, including monitoring and access security, are critical for most users. Both Istio and Linkerd can use a root security certificate, which enables users to control security and access to services across clusters. Both also support Transport Layer Security, so the Linkerd vs. Istio security battle remains a draw.

In installation control, Linkerd will do a pre-check on configuration changes to verify administrative access, but it isn't a full parameterization check -- only a check for access validation and feature compatibility.

Monitoring for both platforms entails an external tool for log correlation, a management console for observability and tracing work. Linkerd has an integrated management console, while Istio requires an external add-on for management and observation. Istio provides tools to trace service relationships and workflows among components -- a feature for which Linkerd needs additional tools. Istio also has significant features for policy management, including authentication and security tools. These capabilities set Istio apart from Linkerd, but users indicate that it requires effort to install these extra features, and that the combination of Istio and Kubernetes policies can be daunting. That said, the need to add external tools to Linkerd for policy management and access authentication also introduces complexity during implementation.

Performance, ease of use and cloud support

When it comes to performance and ease of use, Linkerd takes the lead.

All service mesh technologies tend to slow interprocess communications because of the sidecar-proxy structure, but Linkerd beats Istio, according to some users' tests. For some enterprises, this difference in performance might be enough to tip the scales against Istio, even with its considerable feature advantage. Some users also cite ease of use as an advantage for Linkerd. However, both performance and ease of use relate to the scope of features, and because Istio has more features, it's difficult to say how the two would compare if they had feature parity.

Breadth of applicability in hybrid and multi-cloud is the final issue to consider. Both service mesh technologies run in the cloud and local data centers. Google incorporates Istio as part of Anthos -- its new hybrid and multi-cloud platform -- and Amazon and Microsoft both support Istio in their managed Kubernetes services. Linkerd and Kubernetes can run on any cloud, but they require management.

Istio's support from major cloud providers, and encouragement from its large and active community, make it the default service mesh choice for enterprise applications today. However, as service mesh adoption ramps up, expect significant changes and improvements. Watch the on-going development of the Linkerd vs. Istio argument -- if Linkerd adds features more quickly than Istio improves performance, the balance might shift.

Next Steps

Use Dapr on Kubernetes to build microservices in production

Dig Deeper on Containers and virtualization

Software Quality
App Architecture
Cloud Computing
Data Center