The original translation | Song Song | medium.com/solo-io/lin…

This week I started writing a post comparing Istio and Linked and told myself: I’m going to use a chart to compare the two, it’s going to be great, people are going to love it, the world is going to be happy for a few seconds. I promised myself it would be a fair comparison without any bias. While the table of comparison still exists, I shifted the end of the article: the goal is no longer which is better, but which is better for you, your application, and your organization.

At one point in my career, I worked as a pre-sales architect for a company and remember many times we were asked to fill out product comparison forms. I often need to use creativity to make sure the product looks good, avoiding the unpleasant “not supported” box on the form at almost all costs. Work with integrity in mind, but sometimes you have to.

From the evaluator’s point of view, I understand that their goal (hopefully) is to make a fair comparison, and to that extent, a table of contrasts seems like a reliable way to do it. We know that the success of a project can predict career progression, and we all love that. But here’s the thing: if the end goal of an evaluation is a product-comparison chart, rather than high-quality software that makes the organization more competitive, then the evaluation will end up being just some “chart” work.

Comparing products is not the end goal, but knowing what works best for your use case is the end goal. So let’s take a closer look at the Service Mesh through seven aspects, mainly the following:

  • Traffic management

  • security

  • Installation/Configuration

  • Supported environment

  • monitoring

  • Strategic management

  • performance

I’m going to offer my personal opinion on each of these seven areas, in the hope that my opinion will help you make a more succinct decision.

Traffic management

It is important to note that Istio and Linkerd differ in that the data plane uses two different proxy technologies.

Istio uses Envoy as its proxy. Envoy, written in C++, was originally built by Lyft to facilitate traffic management for microservices in a non-kubernetes way. Many companies have expanded Envoy to Kubernetes’ Ingress technology.

Linkerd (V2) uses a dedicated service grid proxy called Linkerd-Proxy. This agent is written in Rust, and along with this agent, many low-level agent (network client and server) functions are implemented in another project, also written by Rust, called Tower. Tower relies on Tokio, an event-driven non-blocking I/O library written by Rust. If you appreciate statistics as MUCH as I do, Rust has been stack-overflow’s most popular language for four consecutive years (2016, 2017, 2018, 2019).

Istio is built on Envoy so it has an edge in terms of traffic management, and Envoy already includes important IMHO features such as subset routing. Users can still use Linkerd for Canary/Turquoise/A-B publishing, but must rely on a separate Kubernetes service and clustered ingress technology that can distribute traffic, such as Gloo (gloo.solo.io).

The Linkerd team openly stated at a recent community meeting that they plan to implement more advanced L7 traffic management features in future releases.

security

With regard to security, I am thinking of the ability to protect communication channels. Both Istio and Linkerd provide reasonable security protection.

Both Istio and Linkerd rely on external root certificates, so both guarantee secure communication. Sounds like a good weekend project, don’t you think?

Installation and configuration

Given that Istio can be installed on many different platforms, installation instructions can vary widely. At the time of writing this article, I was impressed with some of the pre-installed functionality checks regarding Linkerd installations. There were many times when I installed some Linkerd functionality in a shared Kubernetes cluster and I wasn’t sure if I had the necessary permissions. For Linkerd, pre-check (or check-pre) checks if you have permissions to create the resources Kubernetes need during installation.

Environment support and deployment models

It’s a straightforward question of whether to install in Kubernetes or not. Linkerd2 is built in Kubernetes, at least for now, and Istio has received contributions from other companies. Expect IStio to run in a non-Kubernetes environment.

Considering multiple cluster deployments, it can be objectively tricky to interpret. Technically, services on different clusters (with different control planes) sharing the root CA certificate can communicate effectively.

Istio extends the above concept because it supports multiple clusters in different situations:

  • A single control plane can satisfy the network connection between different clusters and IP addressing between PODS.

  • Kubernetes API servers on multiple clusters can be accessed using the egress and ingress cluster boundary gateways with a single control plane.

In both cases, the cluster containing the control plane becomes a single point of failure (SPOF) for mesh management. In our world, where a single cluster can be deployed across multiple available areas under the same area, this will no longer be an issue, but it still can’t be completely ignored.

monitoring

Istio’s administrative console is arguably a missing piece. The Kiali Observability Console does address some of the administrator’s requirements for the Service Mesh.

Kiali (κιάλι) is a Greek word meaning telescope, and it is clear from the Kiali website that it is intended to be a monitoring console, not just a Service Mesh management console.

The Linkerd console is not complete yet, but the community decided that the goal of building an administrative dashboard as well was an advantage.

Linkerd could not provide request tracking. To view the request trace span in a non-invasive manner, you must wait for Linkerd to implement this feature. Istio takes advantage of the fact that Envoy support adds tracking headers.

The user should be reminded that the application needs to be ready to forward trace Headers, and if not, the agent can generate new trace IDS, which may inadvertently split a single request into multiple request spans and lose the necessary relevance between requests. Most development frameworks have the option to forward HEADERS without requiring the user to write a lot of code.

Strategic management

Fans of Istio, rejoice! Istio’s policy management capabilities are impressive.

This project builds an extensible policy management mechanism that allows other technologies to integrate with Istio in multiple ways, see the list of “Templates” below and some of the integrated providers. You can think of “Template” as an integration.

To highlight other policy types, Istio also works with rating and Limiting and provides out-of-the-box support for principal authentication. Linkerd users rely on the cluster Ingress controller to provide rating and limiting.

For principal authentication, I’ve always thought it should be delegated to the application. Remember the #4 fallacy of distributed computing: The network is secure. Take a zero-trust policy.

Istio’s impressive policy management capabilities come at a cost. Given its breadth, managing many options adds to the already high operating costs.

The policy management component of Istio (Mixer) also adds significant performance, which we discuss in detail below.

performance

Where is the comparison chart? Fortunately, just recently, two great blogs were published comparing the performance of Istio and Linkerd, some of which I quote below:

For this combined workload, Istio’s Envoy agent uses 50% more CPU than Linkerd. Linkerd’s control plane uses a small part of Istio, especially when considering “core” components. Michael Kipper — Benchmarking Istio & Linkerd CPU (medium.com/ihcsim/lin…

The And…

In this experiment, both the Linkerd2-MEShed and istio-meshed Settings experienced higher latency and lower throughput compared to the baseline Settings. The latency generated in the istio-meshed setup is higher than that observed in the Linkerd2-meshed setup. The Linkerd2-meshed setup can handle higher HTTP and GRPC ping throughput than the IStio-meshed setup. Ivan Sim — Linkerd 2.0 and Istio Performance Benchmark (medium.com/ihcsim/lin…

Aware of the increased processing time for the Mixer, the Istio team is currently working on rewriting the Mixer component: “the Mixer will be reconfigured and embedded directly into the Envoy in c++. There will no longer be any separate Mixer services. This will improve performance and reduce operational complexity.” – Source Mixer V2 Design Document (docs.google.com/document/d/…

# # #

Yes, Istio has more features than Linkerd2.3. This is great, as more features mean an increased ability to handle more complex and edge use cases. There’s nothing magical about this, more features usually mean more configuration, potential resource utilization, and increased operating costs, so here are three tips:

  • If you don’t know what 80% of the most common workloads look like, it’s hard to choose a service grid. If you don’t know the numbers, your business may not be ready to use the service grid. If you’re just exploring, that’s a different story.

  • If you want to plan to address all possible current and future cases (often called comparison spreadsheet), you are going to have a bad time. You’re likely to overacquire, and that’s true of any software you buy.

  • Blindly choosing one technique or another can make your life miserable. The hype can be great, but remember, you’re not hyping the business (unless you’re actually hyping it).

Try Istio and Linkerd! Solo SuperGloo is the easiest way.

I use SuperGloo because it is very simple and can start up two service grids quickly with almost no effort on my part. We didn’t use it in production, but it was perfect for such a task. Each grid is actually two commands.

— Michael Kipper — Benchmarking Istio & Linkerd CPU — Shopify (medium.com/@michael_87…

At solo.io (www.solo.io/), we’d like to serve you… Solo SuperGloo Our Service Mesh Orchestrator installs and manages popular service grid technologies with intuitive and simple commands. As Michael pointed out above, installing Istio or Linkerd becomes a one-line activity. SuperGloo does more than that, providing an abstraction over different service grid technologies, allowing consistent and repeatable operations across multiple grids. SuperGloo is completely open source, you can try it right now (superglo.solo.io /).

This article was originally translated and published by Boyun Research Institute.