When it comes to dealing with service to service (East-West) traffic it is common to implement a Service Mesh.
[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.
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.
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.
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?
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.
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.