Which service mesh is best for your organization? In recent years, the number of Kubernetes service meshes has rapidly increased, making that a tricky question to answer.
Here's a deep dive into nine popular open-source service meshes that will bolster your microservices development, with use-case recommendations for each.
An introduction to service mesh
What's the hype around service mesh, and why is it happening now?
Microservices are a handy development method. However, as your distributed microservices architecture multiples, you run into issues around deployment and scalability.
Containers and container orchestrators such as Kubernetes solved many of these issues by packaging services with their own runtimes, executing containers, and mapping them to machines. However, there was still a gap in the operational logic: managing interservice communication.
Enter service mesh; it adds uniform networking capabilities across your stack in a way that is decoupled from application code. Service meshes extend a cluster manager like Kubernetes to offer observability metrics, service discovery, load balancing, IT operations monitoring, and failure recovery for microservices and containers.
Overview of the service mesh landscape
Service mesh has gotten a lot of hype. As William Morgan, a founder of Linkerd, wrote: "It’s nothing more than a bunch of userspace proxies, stuck 'next' to your services." Though the idea is quite simple, "there's some real, concrete, and important value to the service mesh, if you can cut through all the noise," he added.
At the heart of many service meshes is Envoy, a general-purpose, open-source proxy used as a sidecar to intercept traffic. Other service meshes utilize a different proxy.
When it comes to service mesh adoption, Istio and Linkerd are more established. Yet many other options exist, including Consul Connect, Kuma, AWS App Mesh, and OpenShift. Below, here are the key features from nine service mesh offerings.
Istio
Istio is an extensible open-source service mesh built on Envoy, allowing teams to connect, secure, control, and observe services. Open-sourced in 2017, Istio is an ongoing collaboration between IBM and Google, which contributed the original components, as well as Lyft, which donated Envoy in 2017 to the Cloud Native Computing Foundation.
Thus, Istio has had time to mature and improve its feature set. Key Istio features include load balancing, traffic routing, policy creation, metrics, and service-to-service authentication.
Istio is split into two components: a data plane and a control plane. Istio's data plane handles traffic management, using an Envoy sidecar proxy to route traffic and calls between services. Istio's control plane is what developers use to configure routing and view metrics.
Key to Istio metrics are fine-grained attributes. They include specific data values relevant to service behavior. Here are example attributes:
request.path: xyz/abc
request.size: 234
request.time: 12:34:56.789 04/17/2017
source.ip: [192 168 0 1]
destination.service.name: example
Compared to other service meshes, Istio shines in platform maturity and a heightened emphasis on behavioral insights and operational control, coming out of the box with monitoring dashboards. However, due to its advanced features and dense configuration process, Istio may not be as usable or developer-friendly as simpler service mesh alternatives.
Linkerd
Linkerd is an "ultralight, security-first service mesh for Kubernetes," according to the website. It's a developer favorite, with incredibly easy setup (purportedly 60 seconds to install to a Kubernetes cluster). Instead of Envoy, Linkerd uses a fast and lean Rust proxy called linkerd2-proxy, which was built explicitly for Linkerd.
Linkerd is community-driven, 100% Apache-licensed open source, and it's also a Cloud Native Computing Foundation (CNCF) incubating project. It's also been around since 2016, so the maintainers have had time to work out the kinks.
Using the Linkerd service mesh, applications can add reliability, observability, and security features to their Kubernetes deployments. The added visibility could, for example, help an engineer resolve latency issues between services. Linkerd doesn't require many code changes or hours spent writing YAML configuration files. Quality features and a positive developer response make Linkerd a formidable bet.
Consul Connect
Consul Connect, the service mesh from HashiCorp, focuses on routing and segmentation, providing service-to-service networking features through an application-level sidecar proxy. Consult Connect emphasizes application security, with proxies offering mutual Transport Layer Security (TLS) connections to applications for authorization and encryption.
Something unique about Consul Connect is that you have two proxy options. Connect offers its own built-in layer proxy for testing, but also supports Envoy. Connect emphasizes observability, providing integration with tools to monitor data from sidecar proxies, such as Prometheus. Consul Connect also is flexible for developer needs. For example, it offers many options for registering services: from an orchestrator, with configuration files, via API, or via command-line interface (CLI).
Kuma
Kuma, from Kong, prides itself on being a usable service mesh alternative. Kuma is a platform-agnostic control plane built on Envoy. Kuma provides networking features to secure, observe, route, and enhance connectivity between services. Kuma supports Kubernetes in addition to virtual machines.
What's interesting about Kuma is that an enterprise can operate and control multiple isolated meshes from a unified control plane. This ability could be beneficial to high-security use cases that require segmentation and centralized control.
Kuma is relatively easy to implement, too, since it comes preloaded with bundled policies. These policies cover common needs such as routing, mutual TLS, fault injections, traffic control, security, and other cases.
Kuma is natively compatible with Kong, making this service mesh a natural candidate for organizations already using Kong API management.
Maesh
Maesh, the container-native service mesh by Containous, bills itself as lightweight and more straightforward to use than other service meshes on the market. While other meshes build on top of Envoy, Maesh adopts Traefik, an open-source reverse proxy and load balancer.
Instead of adopting a sidecar container format, Maesh uses proxy endpoints for each node. Doing so makes Maesh more non-invasive than other meshes, since it does not edit Kubernetes objects or modify traffic without opt-in. Maesh supports a couple of configuration options: annotations on user service objects as well as Service Mesh Interface (SMI) objects.
Indeed, its support for SMI, a new standard service mesh specification format, is one unique trait of Maesh. If SMI adoption increases throughout the industry, it could offer extensibility benefits and potentially reduce vendor lock-in concerns.
Maesh requires Kubernetes 1.11+ and a CoreDNS/KubeDNS installation. The quick-start guide notes how easy it is to Install Maesh using Helm v3:
helm repo add maesh https://containous.github.io/maesh/charts
helm repo update
helm install maesh maesh/maesh
ServiceComb-mesher
The Apache Software Foundation describes its ServiceComb-mesher package as "a high-performance service mesh implementation written in Go." Mesher is based on Go Chassis, a popular microservices development framework for the Go language. Thus, Mesher inherits Go Chassis features such as service discovery, load balancing, fault tolerance, route management, and distributed tracing.
Mesher adopts a sidecar design method; each service has a dedicated Mesher sidecar proxy. Developers interact with Mesher and view runtime information through an Admin API. Mesher supports HTTP and gRPC and is portable to many different infrastructure types, including Docker, Kubernetes, virtual machines, and bare-metal environments.
Network Service Mesh (NSM)
Network Service Mesh (NSM) is a service mesh explicitly built for telcos and ISPs, offering a layer for adding low-level networking capabilities to Kubernetes. NSM is a sandbox project with the Cloud Native Computing Foundation.
"Operators of multifaceted networks with advanced L2/L3 use cases currently find container networking solutions ill-suited for their next-generation architecture," according to the NSM documentation.
Thus, NSM is built with different assumptions in mind, emphasizing "exotic" protocols and heterogeneous network configurations. This makes NSM attractive for use in specific use cases such as edge computing, 5G networks, and IoT devices. NSM uses a straightforward suite of APIs to allow communication between containers and external endpoints.
NSM works at a different layer than other service meshes on this list. VMware describes it as "connection-centric." GitHub packages demonstrate its use with Envoy.
AWS App Mesh
Amazon Web Services' App Mesh provides "application-level networking for all your services." It manages all network traffic for services and uses the open-source Envoy proxy to control traffic into and out of a service's containers. AWS App Mesh supports HTTP/2 gRPC services.
AWS App Mesh could be a good service mesh option for companies already married to the AWS infrastructure for their container platforms. AWS platforms—including AWS Fargate, Amazon Elastic Container Service, Amazon Elastic Kubernetes Service (EKS), Amazon Elastic Compute Cloud (EC2), and Kubernetes on EC2—include AWS App Mesh at no additional charge.
AWS App Mesh also is compatible with monitoring tools within the AWS ecosystem, including Amazon tools such as CloudWatch and AWS X-Ray, and those from many third-party providers. Because AWS compute services support AWS Outposts, AWS App Mesh could operate with hybrid cloud and on-premises deployments.
The downside of AWS App Mesh could be being stuck within a single vendor's paradigm with less open-source or extensible tooling.
OpenShift Service Mesh by Red Hat
OpenShift is a container management platform by Red Hat that helps "connect, manage, and observe microservices-based applications." Described as a hybrid cloud enterprise Kubernetes platform, OpenShift comes preloaded with numerous abilities and boasts substantial enterprise adoption.
OpenShift Service Mesh builds on top of open-source Istio, bringing the Istio control and data plane features. OpenShift enhances Istio with tracing and visibility features powered by two open-source tools. OpenShift uses Jaeger for distributed tracing, permitting better tracking of how requests are handled between services.
OpenShift also uses Kiali for added observability into microservices configuration, traffic monitoring, and tracing analysis.
Considerations when choosing a service mesh
As you can see, there are many service mesh options on the table, and the landscape is still in flux. Of course, every service mesh has a slightly different approach, bringing nuanced implications. Considerations include how invasive you are willing for the service mesh to be, its security defaults, platform maturity, and other concerns.
Here are some other factors that could help DevOps teams determine which service mesh is best for their specific scenario:
Can you live without Envoy? Envoy has a vibrant ecosystem of community-built integrations; it's open-source and fundamental to many service meshes. Its wealth of features make it hard to pass up.
What does your use case require? Service mesh is for microservices. If you're building a monolith, you likely won't reach an ROI from service mesh. If not all your applications adopt Kubernetes, a platform-agnostic choice is best.
What are your existing container management tooling dependencies? Companies that already utilize a vendor ecosystem for container orchestration—such as AWS EKS, Red Hat's OpenShift, and Consul—will likely benefit from their native tooling, as features will extend beyond open-source packages.
What is your industry? Most service meshes are not built for a specific industry type; however, Kuma's ability to partition multiple meshes may be interesting to highly regulated financial platforms. Lower-level networking telcos and ISPs should consider Network Service Mesh.
How much visibility do you need? Observability into advanced metrics is core to service mesh. Those seeking customization and deep abilities might consider Istio or Consul.
Do you care about open standards? Working with open standards could future-proof your tech and make it extensible with other tools. It may behoove enterprises to adopt tools that support SMI, such as Maesh, or foundation-supported projects, such as Linkerd.
Do you care about the developer experience? Considering usability for ops engineers is crucial for new tooling adoption. Linkerd seems to have the best reputation among developers.
Is your team prepared for service mesh? Evaluating whether your organization has the resources and skill sets to implement service mesh technology may affect whether you approach Envoy head-on using Istio, or abstracted through a vendor-layered facade, such as OpenShift.
These considerations are not at all exhaustive. They're simply meant to ignite discussion. Hopefully, after checking out the meshes listed above and using these talking points, your organization will feel inspired to investigate new ways to operationalize the networking aspect of your microservices development.
Keep learning
Take a deep dive into the state of quality with TechBeacon's Guide. Plus: Download the free World Quality Report 2022-23.
Put performance engineering into practice with these top 10 performance engineering techniques that work.
Find to tools you need with TechBeacon's Buyer's Guide for Selecting Software Test Automation Tools.
Discover best practices for reducing software defects with TechBeacon's Guide.
- Take your testing career to the next level. TechBeacon's Careers Topic Center provides expert advice to prepare you for your next move.
