As cloud-native applications have transitioned from monolith to microservices architecture, one of the biggest challenges organizations face is the rapid increase in the number of services as the organization gets larger.

This unexpected growth in the number of services leads to challenges in managing various aspects like security, encryption, authorization, routing, and load balancing between multiple services/versions.

To mitigate these challenges exacerbated by the exponential growth of several hosts. Service Mesh technologies have emerged. These solutions support container environments such as Kubernetes and provide an easy way to create a network of load balancing, authentication, and monitoring services.

A Service mesh gets implemented for microservices running on top of Kubernetes. Without a service mesh, every microservice needs manual configuration to communicate, requiring a lot of time and energy to maintain connections between services.

Instead of manually configuring the microservices, developers can create a service mesh that enables services to communicate securely and reliably.

Together Kubernetes and service mesh can allow complex containerization architecture to communicate, pass and process relevant information like service discovery, load balancing, health monitoring, and analytics reporting.

There are various service mesh implementations available that can be deployed as a layer on top of Kubernetes. This article will compare some of those implementations and their characteristics to see which one is the best.

Istio

Istio is the most widely used service mesh tool for Kubernetes. Istio was announced in May 2017 as an open-source project, followed by a stable release in July 2018. Istio is a service mesh of choice for many technology giants like Google, IBM, and Microsoft. They all implemented Istio as a default service mesh in their cloud environments. Istio is also available as a fully managed service for different deployment types.

Istio offers highly configurable traffic management features like routing rules, virtual servers, load balancing for Kubernetes clusters by splitting the functionality into control and data plane. A control plane provides a set of APIs used to manage data plane, proxy behavior, authentication policies, and metrics. At the same time, a data plane comprises a set of intelligent proxies implemented for secure communication.

Istio’s control plane consists of three major components, and they provide different functionalities. First, the Pilot is responsible for data plane configuration, distribution of authentication policies, and service discovery. Next, Mixer manages data plane authorization and access control queries, and Finally, Citadel allows key and certificate management for building zero trust security in the mesh.

Istio data plane, on the other hand, is built on top of the Envoy proxy, which mediates all the traffic between microservices while providing support for TLS encryption, subset routing, and traffic filtering. Envoy gets deployed as a sidecar proxy running inside a container within each pod to eliminate the need to make direct service calls; all the microservices make calls to their local proxy, which then routes the request appropriately.

Istio is the first service mesh to secure communication between services by integrating a template policy management framework that allows cluster admins to set different communication rules for applications. Istio also provides various monitoring, tracing, and logging features for deep insights and visibility. It integrates tightly with service mesh dashboard Kiali which produces metrics and provides advanced querying capabilities by connecting Istio to Prometheus, Grafana, and Jaeger.

Service backends like Jaeger, Zipkin, and Solarwind are compatible with Istio for tracing. Logging of policy events and network activity is possible by integrating Istio with the logging stack.

Istio support is not officially available by Google, IBM, and Lyft. However, IBM’s OpenShift offering provides paid support for OpenShift Service Mesh, an enterprise version of Istio designed for reliability and performance.

Linkerd

Created by Buoyant and sponsored by Cloud Native Computing Foundation (CNCF). Linkerd is one of the most simple open-source service mesh tools available. Linkerd 1.0 was nicely received by the Kubernetes community because it supported various container platforms, including AWS ECS and Docker.

The second and current version of Linkerd (v2.0) has an implementation similar to Istio and supports more Kubernetes based platforms and features. Linkerd 2.0 is designed and rewritten in Rust to make it ultralight for debugging and observability without requiring code changes in your distributed application.

Just like Istio, Linkerd 2.0 architecture gets divided into a control plane and a data plane. The control plane provides a set of services for gathering metrics and managing data plane proxies. Simultaneously, the data plane consists of the lightweight proxies deployed to run next to each service instance for handling the traffic.

Linkerd control plane comprises of two major components. A controller component provides an API container for a CLI, and a web component provides a web dashboard for integrating Grafana dashboards and Prometheus for collecting and storing Linkerd metrics.

Linkerd data plane proxies are deployed using a sidecar container, injected during the pod’s initialization phase. With sidecar deployment, it is easy to configure proxies for each workload, which decreases the transmission of data to other pods or spaces outside the cluster.

Linkerd is built entirely as a standalone service mesh tool, so it doesn’t rely on Envoy and third-party tools. Linkerd implementation has its service proxy, the linkerd-proxy, which provides increased performance and reduced latency compared with other service mesh solutions.

Linkerd also maintains compatibility with different ingress controllers. It can be easily integrated with any ingress controller for URL routing and exposing Kubernetes services. Linkerd v2.8 version supports multi mesh scenarios like Istio and provides good support for certificate rotation to secure communication channels between services.

Tracing and monitoring are also very easy to do as Linkerd offers out of the box support for Grafana dashboards and tracing backends that adhere to the OpenCensus standard.

Support for Linkerd is available by Buoyant. However, Linkerd 1.x has broader support as it can run in many environments and frameworks, including AWS ECS, DC/OS, and Docker, compared to Linkerd 2.x, which only supports Kubernetes.

Consul Connect

Developed by Hashicorp, Consul Connect is a fully featured service mesh framework that quickly connects with Envoy and various other proxy alternatives for providing service discovery capabilities.

Initially, Consul connect was used for managing services running on Hashicorp Nomad workloads, but with time it has grown to support container orchestrator platforms like Kubernetes.

Consul Connect works seamlessly in any environment, whether it’s Kubernetes or VMs, or Nomads. It offers many handy features, like TCP and gRPC support, mesh expansion, and seamless ingress controller integration.

Consul Connect control plane implements an agent running on each node as a DaemonSet, which communicates with the Envoy sidecar proxies on the data plane to handle traffic forwarding and routing.

Consul Connect data plane also has a pluggable architecture that allows different proxies to enable intelligent traffic routing, flow control, and services management through traffic splitting.

Robust monitoring features in Consul provide deep insights and visibility by allowing observability tools such as Prometheus to plug into the product for efficient issue detection and resolution.

Tracing is different from other service mesh solutions and supports various backends like Jaeger, Datadog Zipkin, Honeycomb, and OpenTracing. Logging in Consul Connect can be easily integrated with Kubernetes logging stacks like ELK to retrieve network and policy event logs.

Hashicorp further extends the service discovery provided by Consul Connect by tightly integrating with Hashicorp products like Vault to offer certificate and secret management.

AWS App Mesh

AWS App Mesh is a service mesh framework for the Kubernetes powered apps and microservices running within Amazon Web Services. AWS app mesh provides monitoring and networking capabilities, which manages services and uses the open-source Envoy service proxy to control traffic into and out of a service’s containers.

Envoy side proxy makes AWS App mesh compatible with various open-source and AWS tools like AWS X-Ray, CloudWatch, for monitoring tracking, and blue/green canary deployments for services.

In AWS App Mesh, services within the same namespace are connected through a virtual service to channel communications. The communication is secured through mutual TLS and advanced load balancing to have secure control over the traffic while transmitting the correct configuration to the different microservice proxy.

Users can utilize AWS App Mesh to control communications across microservices applications running on AWS Fargate, Amazon Elastic Container Service, Amazon Elastic Kubernetes Service (EKS), Amazon Elastic Compute Cloud (EC2), and Kubernetes on EC2. There is no cost for App Mesh other than the computing resources used with ECS/EKS/EC2.

Comparison Table

	Istio	**Linkerd **	Consul Connect	AWS App Mesh
Supported Environments	Kubernetes + VMs	Kubernetes + VMs	Kubernetes + VMs	AWS EC2 (Kubernetes), EKS, Fargate
Sidecar proxy	Yes (Envoy)	Yes	Yes (Envoy)	Yes (Envoy)
Secure Communication (mTLS)	Yes	Yes	Yes	Yes
Supported Communication Protocols	gRPC, HTTP/2, TCP, Websockets, and HTTP/1.x	gRPC, HTTP/2, TCP, Websockets, and HTTP/1.x	gRPC, HTTP/2, TCP, Websockets, and HTTP/1.x	HTTP2 and gRPC
Enterprise Support	Not available. RedHat OpenShift with Istio as a service mesh, provides enterprise support	Full enterprise- support and training available by Buoyant	Full enterprise-class support for Consul Enterprise Platform	24x7 access to Guidance, configuration, and troubleshooting of AWS services
Monitoring with third-party tools	Yes, with Prometheus, Jaeger, and Grafana	Yes, with Prometheus, Jaeger	Yes, with Prometheus, Jaeger, and Grafana	Yes, support Prometheus, Jaeger, and Grafana
Tracing Backends	Jaeger, Zipkin	All OpenCensus supported backends	Jaeger, Datadog Zipkin, Honeycomb	Zipkin, and LightStep.
Multicluster Support	Yes, with various configuration options and extension of mesh outside the clusters	Yes, As per the latest release, 2.8, multi-cluster Deployment is possible.	Yes, with various configuration options and extension of mesh outside the Kubernetes clusters possible.
Deployment	Via Helm	Via Helm	Via Helm	Via AWS CLI
Ease of Installation and use	No, can be complex for teams due to various configuration options and flexibility.	Yes, easier to adapt due to out of the box configurations.	Simple to use but some complex configurations	No, can be complex for teams due to various AWS configurations.

Which one is the best?

All the service mesh solutions mentioned above can easily fulfill basic needs. However, each solution has its advantages and disadvantages. The best one comes down to whether you want that benefit of a particular solution.

Istio provides the most flexibility and is a standard for service mesh solution, but with more flexibility comes the responsibility to operate it. Linkerd, on the other hand, provides most features of Istio while decreasing the complexity to operate and maintain.

Consul is your best bet if you want all of the Istio features and the seamless integration of Hashicorp Enterprise products. At last, AWS is best for organizations who are already connected with AWS cloud and want a service mesh framework to support their services natively.