As service architectures have transitioned from the monolith to microservices, one of the tougher problems that organizations have had to solve is service discovery and load balancing. The advent of service mesh technologies seeks to solve these and other problems exacerbated by the number of hosts that has grown exponentially.
In this article, we’re going to explore what a service mesh is. Then we’re going to take a much closer look at two of the front-runners in the service mesh space – Istio and Linkerd – which have achieved broad adoption, especially in the Kubernetes environment. We’ll talk about the characteristics of each, and then compare how they measure up against each other.
Anatomy of a Service Mesh Solution
Within an environment, such as a Kubernetes cluster, services need a way to find each other so that they can communicate, pass and process relevant information. A service mesh is an infrastructure component that facilitates this communication and ensures that it is fast, safe, and reliable. The service mesh is responsible for:
- Service Discovery
- Communication and Routing
- Load Balancing and Health Monitoring
- Authentication, Authorization, and Encryption
- Protection and Self-healing (Such as Circuit breakers and Automatic Failover)
- Analytics Reporting
The most common method of service mesh implementation uses the sidecar design pattern. With the sidecar pattern, a proxy runs alongside each service within the cluster – the service delegates all communication and network tasks to the proxy. The network of proxies within the cluster makes up the service mesh.
Service Mesh Candidate 1: Istio
Istio is a popular service mesh that grew out of a partnership between teams from Google, IBM, and the Envoy team from Lyft. Lyft’s Envoy Proxy is the foundation of Istio. Istio is the default service mesh within hosted Kubernetes solutions at Google, IBM, and Microsoft.
Having the Envoy Proxy as the foundation for Istio provides several advantages out-of-the-box. By using Envoy’s tracing headers, Istio natively supports distributed tracing. Envoy also enables subset routing and enhanced traffic filtering.
Istio offers a feature set, which has far greater depth than Linkerd. These features are configurable through enhanced policy management and include:
A more in-depth service mesh pedigree – at least as it relates to Kubernetes – and more advanced feature sets do come with a cost. In simulations that pitted the performance of Istio against that of Linkerd, Istio consumed marginally more processing power and experienced higher levels of latency.
If you’re looking for a service mesh for your Kubernetes cluster, then Istio is worth considering. Unfortunately, it exclusively supports Kubernetes; which means that if you need a service mesh for a system other than Kubernetes, you can cross Istio off your list, at least for now.
Service Mesh Candidate 2: Linkerd
Linkerd is the creation of Bouyant, and it is currently a sponsored project of the Cloud Native Computing Foundation (CNCF). One of the original design principles for the development of Linkerd was simplicity over flexibility.
The first version of Linkerd supported multiple container platforms, including AWS ECS and Docker. Linkerd 1.x is deployed as a service within each host, rather than as a sidecar. This approach enables the broader range of environments it can support, but also makes it more vulnerable to failure. The second and current version of Linkerd has an implementation very similar to that of Istio and, like Istio, only supports Kubernetes environments.
In performance benchmarks conducted at the end of 2018, A Linkerd implementation was found to consume less processing power and have lower latency than an Istio implementation with similar workloads. Some of this increased performance is likely because Linkerd uses linkrd2-proxy, which is a proxy explicitly built as a service mesh sidecar.
Recent developments within Linkerd 2.x also support Blue/Green deployments and better traffic routing than was previously available.
When we consider essential features, distributed tracing is one critical feature that isn’t part of the default Linkerd configuration. That’s not to say that you can’t configure your implementation to enable tracing. Instead, it requires changes to both the code and the configuration at present.
How to Choose Between The Options
Several challenges arise when comparing and recommending technologies that are still emerging and currently under development. The first is that what might initially be a deficiency in one product, might be implemented at a later time. The additional experience and research might result in it becoming a significant strength.
The other problem is that the ability of a solution to address all the needs of your organization is sometimes a long shot. Generally, there is a trade-off between features and attributes depending on an organization’s priorities.
Both Linkerd and Istio are open-source projects, licensed under Apache 2.0. Because they’re open-source, there isn’t a cost associated with experimentation, other than time and effort. Experimenting with test workloads that are typical of those your systems handle is the best way to decide whether a service mesh is right for your organization and, if so, whether Istio or Linkerd, best meets your requirements.
Complete visibility for DevSecOps
Reduce downtime and move from reactive to proactive monitoring.
