What is a Service Mesh?

In our previous post on API Gateways we discussed how services handle external client to service (North-South) traffic.

When it comes to dealing with service to service (East-West) traffic it is common to implement a Service Mesh.

Overview

A Service Mesh is a dedicated infrastructure layer that handles service to service communication. It aims to handle all communication between your applications microservices, without the need to expose configuration details to the clients. As Tobias Kunze puts it:

[a service mesh] is a mesh of API proxies that (micro)services can plug into to completely abstract away the network.

The key here is the abstraction of the network. A core part of the service mesh is: "How can services find each other?"

In addition to your services themselves, a service mesh is comprised of two main parts: the sidecars for each service, and a control plane. Before we dive into the reasons why you may consider a service mesh, let's look at these parts.

The Sidecar

Most service meshes implement a sidecar proxy to handle all inter-service communication. Sidecars are adapters that sit alongside a service. They are like liaisons, or representatives, between departments. Rather than services communicating directly with one another, the sidecars route and translate requests to and from the service.

In a system like Kubernetes, the sidecar proxy is installed in the same pod as a sidecar container alongside the application container. Since they are both in the same pod, they can communicate easily and all traffic goes through the proxy before reaching the application. This co-location also makes the added latency of an additional hop minimal.

The collection of proxies to all our services is known as the data plane.

The Control Plane

The control plane is the management layer for the data plane. It is in charge of creating new instances of services, monitoring, managing security between services, and implementing any application-wide policies. When a change needs to be made to how any shared logic works across the mesh, the control plane sends the necessary updates to the sidecars.

Control planes are often implemented as pluggable systems where functionality can be added as needed. This means if you need to add telemetry for your service mesh, it can be added to your existing control plane configuration. Istio is a popular control plane and service mesh management solution that works in this way.

Key benefits of a service mesh

The benefits of service mesh start to become more relevant as your network of services grows. It prevents the need to rewrite the same or similar logic over and over again. Most service mesh implementations focus on:

• Security: Allowing encryption and mutual authentication and authorization between services. The mesh allows you to decouple this logic from the individual services.
• Reliability: Implements resiliency patterns like health checks, time-outs, circuit breakers, and retries.
• Observability: Handles all your telemetry data related to the microservices and their communications with one-another. This includes things like logging, monitoring, and tracing. Without a mesh, this can be difficult due to the various layers of networking (container instances, VMs, etc.) that sit between each service.
• Configurability: Since the network is abstracted from the services themselves, the mesh handles features like traffic shaping, load balancing, and A/B testing. The mesh also applies shared policies and configurations across the services.

Downsides to a service mesh

While a service mesh may remove large amounts of existing overhead and configuration, it is a new system for your team to learn. While they have been around for a few years now, the ecosystem is still evolving heavily and many are tightly linked to the distribution platform they are built on, e.g., Kubernetes. The initial complexity investment may not make sense for large, pre-existing applications or applications with few microservices.

Earlier we mentioned that the co-location of sidecars to services reduces the latency in each additional hop, but there is still an additional layer between applications and the services they rely on, even if it is a fast one.

Where do API Gateways come in?

Used together, an API gateway handles the routing of traffic into your service mesh from your clients. Any inter-service communication still occurs within the mesh. As service meshes have become more mature, they are starting to adopt many features from API gateways. As a result, some implementations now handle the external routing of client requests and all the features that go along with taking over that role.

Depending on the feature set of your chosen service mesh, combined with the requirements of your app, you may find that a service mesh can handle it's own roles along with those of the API gateway.

Is a service mesh right for you?

Up to this point we've alluded to it, but it's worth saying: service mesh is tightly coupled to the idea of "cloud native" application models. Specifically the mix of microservices, containerization, and an orchestration layer.

The management and complexity that this style of application brings increases the need for a solution like service mesh. If your application only relies on a few microservices, service mesh is overkill. It's not until you exceed the dozens of microservices level. Once these are communicating with one another, that management complexity will rise to the level that a service mesh makes sense for your business.

Wrapping up

The future of service mesh is adoption and feature expansion. Many service mesh products are beginning to absorb some of the functionality of API gateways.

Where a service mesh helps you manage server-to-service communication within your stack, we at Bearer are building a solution to help your apps and services better communicate with third-party APIs by incorporating features like logging, real-time notifications, automatic retries, and more without code changes or complex configurations. Give Bearer a try today.

📢 This post was originally written by Mark Michon on the Bearer Blog