Intro

Service Meshes are often confused with API gateways. While there is an overlap in some of their functionality they are overall very different.

The creator of Linkerd has this to say on the matter:

API gateways handle ingress concerns, not intra-cluster concerns, and often deal with a certain amount of business logic, e.g. “user X is only allowed to make 30 requests a day

The most important thing to unpack from the quote above is intra-cluster. Service meshes were originally designed for use in container-orchestration systems and are a relatively new development in the world of cloud computing. In present-day Kubernetes, is by far the most widely adopted technology in the container-orchestration landscape, and service meshes such as Linkerd have dropped support for alternate solutions.

In one sentence, what are service meshes about?

If you google it, you’ll find different variations of the same sentence.

While I could just copy and paste one of these definitions I will write my own.

A service mesh is an additional layer you can add to your Kubernetes cluster to manage common cross-cutting concerns involved with inter-service communication and networking.

In response you may be thinking: “Didn’t you say above that service-meshes can be applied to any container-orchestration technology?”

While the answer is yes ~~If you use mesosphere or some other bullshit get the fuck off my blog. This is 2022, not 2014.~~

How it works

Service meshes are powered by proxies and a control plane.

In a service mesh, each pod in your cluster will be deployed with a proxy side-car container. Each call to your application container in your pod will be intercepted by this proxy. This proxy will communicate with the control plane which will coordinate the behavior of the proxies. These proxies act as reverse and forward proxies and implement a feature set that focuses on communication between these services.

The control plane is a set of components that provides whatever functionality the data plane needs to act in a coordinated fashion. This includes service discovery, TLS certificate issuing, metrics aggregation, and so on. The data plane informs the control of its behavior. The control plane in turn provides an API to modify and inspect the behavior of the data plane as a whole.

Benefits

Service meshes offer a rich layer 7 feature set that can be divided into three classes:

Reliability features. Request retries, timeouts, canaries (traffic splitting/shifting), etc.
Observability features. Aggregation of success rates, latencies, and request volumes for each service, or individual routes, tracing, drawing of service topology maps etc
Security features. Mutual TLS, access control, auth policies

This common functionality can be configured at the service mesh level and be applied to all applications running in a mesh. This saves us time on having to implement and configure these features as code at an application level.

Conclusion

If you are a software developer developing applications in Kubernetes, knowledge of service meshes and what they do will help you configure your services in such a way that they are additionally secure and reliant. They may save you the effort of implementing useful features in code, and save you the burden of configuring your Kubernetes networking behavior in fine-grained detail.

Sources

https://buoyant.io/service-mesh-manifesto (diagram from)

https://istio.io/latest/about/service-mesh/

https://www.redhat.com/en/topics/microservices/what-is-a-service-mesh