A service mesh is a software infrastructure layer for controlling communication between services and usually tasked with handling all the network logic required to make microservice applications work seamlessly in a cloud-native environment. It’s the perfect solution to your communications problems.
With microservices and distributed applications becoming more and more popular across the software engineering landscape, many developers are finding that the complexity of communication between all of these services has become unmanageable. When you throw Kubernetes into the mix, it complicates things further. How do we solve for communication logic, security logic, retry logic, and metrics logic in these systems?
In this article, you will learn what a service mesh is and how it works, why it’s important to use one, what options are out there, and the pros and cons of each option. Hopefully by the end, you’ll be set up to choose and deploy a service mesh of your own.
A service mesh is usually made up of two components:
When it comes to choosing your service mesh, there are many options that exist in the market today. But two stand out among the crowd as they are the most established: Istio and Linkerd.
Istio was launched in 2017 and has gone on to develop an encompassing service mesh solution for DevOps engineers. One of the major strengths of Istio is the backing of tech giants like Google, IBM, and Lyft. This backing has allowed the service mesh to gain a lot of exposure and adoption in the market. It’s one of the most popular service meshes for Kubernetes deployments today.
Like all service meshes, the Istio mesh architecture is made up of two components
In Istio mesh architecture, the proxies are Envoy proxies which is an independent open source project that Istio and other service mesh implementations also use. The control plane component called Istiod manages and injects the envoy proxies in each of the microservice pods.
In earlier versions of Istio, up until version 1.5, the control plane was made up of several components like Pilot, Galley, Citadel, Mixer. From v 1.5, all the components in the control plane were combined into one single Istiod component to make it easier for operators to configure and set up Istio mesh easily.
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.
The Istio mesh focuses on four chief areas:
It offers a rich set of traffic management controls perfect for distributing API calls. It also allows the operations team to harness the power of staged-and-canary rollouts, A/B testing, and percentage-based traffic splitting.
Istio can be set up and configured easily without modifying Kubernetes deployment and service YAML files. It uses Custom Resource Definitions (CRDs), which allow you to extend the Kubernetes API easily.
In Istio mesh, there are two main Custom Resource Definitions to configure service-service communication:
Istio also offers two types of authentication:
Compared to other service meshes, the Istio service mesh shines in platform maturity and a heightened emphasis on behavioral insights and operational control, coming with monitoring dashboards out of the box. 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 was built primarily for the Kubernetes framework. It’s open source and 100 percent community-driven. Linkerd is an “ultralight, security-first service mesh for Kubernetes,” and is a developer favorite with an incredibly easy setup.
Linkerd has a sizable Fortune 500 presence—powering microservices for Walmart, Comcast, eBay, and others. The company is quick to illuminate its grand following. Linkerd has over 3,000 Slack members and 10,000 GitHub stars.
The control plane is made up of several components that are tasked with aggregating telemetry data, providing a user-facing API, and providing control data to the data plane proxies.
The data plane is made up of several transparent proxies that are run next to each service instance. These proxies automatically handle all traffic to and from the service.
Instead of Envoy, Linkerd uses a fast and lean Rust proxy called
linkerd2-proxy. This allows Linkerd to be significantly smaller and simpler than Envoy-based service meshes. You can read more about why Linkerd doesn’t use Envoy here.
Linkerd enables mutual Transport Layer Security (mTLS) automatically for TCP traffic between meshed pods, by establishing and authenticating secure, private TLS connections between Linkerd proxies.
Monitoring and observability are also solid, especially through the Linkerd dashboard. Teams can view success rates, requests per second, and latency. This is meant to supplement your existing dashboard as opposed to replacing it.
While Istio and Linkerd are the most popular and developed service meshes, other options do exist. Some of the following might end up being more useful to your specific use case.
Consul Connect is a service mesh from HashiCorp, providing service-to-service communication and networking features through an application-level sidecar proxy. It’s a service mesh built into Consul, allowing the definition of high-level rules called Service Graphs, which allow the operator to define which service can talk to another.
Service Graphs are handy as they serve as a map for holding service communication rules on the service level and not on the IP level. This prevents having to define tons of firewall rules in the case of IP-based communication.
In Consul Connect, the proxies deployed next to each service use the Service Graph to decide which service to route the request to. For applications that have issues implementing the sidecar deployment of proxies next to each container in the mesh topology, applications can natively integrate with the Connect API to support accepting and establishing connections to other Connect services without the overhead of a proxy sidecar.
Consul also emphasizes observability, providing integration with tools to monitor data from sidecar proxies, such as Prometheus.
Kuma is a service mesh from Kong that prides itself on being a usable service mesh alternative. Kuma is a platform-agnostic open-source control plane for service mesh and microservices management, with support for Kubernetes, VM, and bare-metal environments.
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.
Due to the various challenges that come with developing and deploying a microservice architecture, service meshes are poised to solve these challenges caused by container and service sprawl by standardizing and automating communication between services.
In this article, you have learned what a service mesh is, why you’ll need one, and various options to consider in the markets when adopting a service mesh architecture. Each option comes with its set of uniqueness and how it thrives. The requirements of the organization, as well as the budget, play a major role in the choice of a service mesh as there is no one-size-fits-all solution.
Many businesses struggle to discover problems with their cloud services before they impact customers. For developers, writing tests is manual and time-intensive. Speedscale allows you to stress test your cloud services with real-world scenarios. Get confidence in your releases without testing slowing you down. If you would like more information, schedule a demo today!