ra2 studio - Fotolia

Evaluate Weigh the pros and cons of technologies, products and projects you are considering.

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.

Dig Deeper on Deploying Microservices

Join the conversation

2 comments

Send me notifications when other members comment.

Please create a username to comment.

What features are the most important to you in a service mesh?
Cancel
A good comparison, but unfortunately falls into the trap of "more features means it must be better". Why should a service mesh include, for example, ingress, when there are so many full-fledged ingress solutions out there? This layer of the stack is in desperate need of less complexity, and more modularity, rather than the other way around.

I would much rather see a comparison focused on which tool solves actual problems instead of the "marketing feature checklist comparison". Which service mesh allows you, the user, to solve your problems in as immediate and concrete a way as possible? Which tool imposes the smallest cognitive burden, and introduces the least complexity to the system? When viewed through that lens, I think you'll find it clear where the real value of any of these projects lies.

Finally, a couple factual corrections:
  • Linkerd's load balancing is more sophisticated than Istio's, not less, and automatically takes into account the latency of each destination. (https://linkerd.io/2/features/load-balancing/)
  • Istio's dramatically worse performance is not related to "the scope of features". Even in an apples-to-apples comparison with just telemetry enabled, Linkerd is orders of magnitude faster and smaller. (https://kinvolk.io/blog/2019/05/performance-benchmark-analysis-of-istio-and-linkerd/)
  • Linkerd provides plenty of tools to "tools to trace service relationships and workflows among components", none of which require application modification in the way that distributed tracing does. (https://linkerd.io/2/features/distributed-tracing/)
Nonetheless, kudos on putting a much better comparison than most of what I read out there. Linkerd is a rapidly-moving project with an ever-increasing community, so things are moving fast. I look forward to the next article!


Cancel

-ADS BY GOOGLE

SearchSoftwareQuality

SearchAppArchitecture

SearchCloudComputing

SearchAWS

TheServerSide.com

SearchDataCenter

SearchServerVirtualization

Close