Imagine a situation where you have to test a new version of your application in a microservices architecture, using canary deployment, or where you have to secure traffic between two services or have to set up a failover strategy in case one of the services is unresponsive. In these circumstances, the traditional network layer of most container orchestration engines is woefully unequipped. Wherever the network layer of these engines has to be augmented, tools such as Service Meshes come into the picture.

What is a service mesh?

A service mesh is a “dedicated infrastructure layer for facilitating service-to-service communications between services or microservices, using a proxy.”

Let us look more closely at this definition to understand it better. 

“A service mesh is a dedicated infrastructure layer…” – A service mesh is dedicated, which means that unlike built-in network layers which only support core orchestration functionality with basic features, its main purpose is selective and focused. What is its purpose?

“…for facilitating service-to-service communications between services or microservices”. This is fairly self explanatory. But how does it do this?

“…using a proxy.” A proxy is an entity that handles a specific task on behalf of another. In our case, it refers to the data plane of the service that proxies call to and from the service itself.

Having understood what a service mesh is, let’s delve more deeply into why we need it.

Why do we need it?

From the previous section, we understand that service mesh is an infrastructure layer that primarily caters to the microservice architecture pattern, though it is not restricted to that.

Some of the most common problems faced in microservice networks are:

1. It’s difficult to manage the vast number of microservices, their versions and so on, in and across environments.
2. The complicated and large networks provide a larger attack vector for cybersecurity threats.
3. There is a lack of fine-grained control over inter-service networks.
4. It’s challenging to manage complicated firewall rules and port mappings.

As more people adopt microservices, the above problems are only compounded. This is where the service mesh steps in, to solve these problems.

Features of a service mesh

1. Service discovery

Using a container management framework, service discovery maintains a list of instances that are ready to be discovered by other services. This helps create and maintain a topological map of the network in real-time. Enabling segregation of services into categories leads to better organization and management. Other important features related to service discovery include health checks, load balancing and failover implementation. By keeping track of healthy instances and recording the unhealthy ones, we can configure service meshes to re-route requests to healthy instances of the same application.

2. Zero Trust Security Model

With growing adoption of tools such as Kubernetes, Nomad and others, manual configuration of networks is no longer possible. This complexity is increased especially in Kubernetes and public cloud infrastructure, where IP addresses and DNS names change unpredictably. Service mesh allows for the encryption of communication between services using mTLS and also the verification of identity. The service mesh components use proxies to control communication between local service instances and other services in the network. They also ensure that the TLS connections are verified and encrypted.

3. Fine-grained network control

Proxies attached to services allow us to control traffic and enforce security, but they also allow us to define policies that allow more control over which service is allowed to communicate to whom. This can be done through a simple allow/deny policy. This simplifies the problem mentioned above, regarding complex firewall rules and IP address management.

Comparison between some popular service meshes in the market

	Istio	LinkerD	Consul
Supported workloads	Kubernetes and VMs	Kubernetes only	Kubernetes and VMs
Single point of failure	No	No	No, but managing the High Availability version is complex
Sidecar proxy	Yes	Yes	Yes
Per node agent	No	No	Yes
mTLS	Yes	Yes	Yes
Certificate management	Yes	Yes	Yes
Authentication and Authorization	Yes	Yes	Yes
Communication protocols supported	HTTP/1.x, HTTP/2, gRPC, TCP	HTTP/1.x, HTTP/2, gRPC, TCP	HTTP/1.x, HTTP/2, gRPC, TCP
Blue Green Deployments (Canary deployments)	Yes	Yes	Yes
Circuit breaking	Yes	No	Yes
Rate Limiting	Yes	Yes	Yes
Fault injection	Yes	No	Yes
Monitoring	Prometheus	Prometheus	Prometheus
Multi cluster	Yes	No	Yes
Complexity	High	Low	Medium

When you’re working with microservices architecture and technologies like Kubernetes, it’s important to use all the tools at your disposal to simplify the process. A service mesh is an important part of this process.