Q&A
Why would an organization need a service mesh?
Using a service mesh, which is a configurable, low-latency infrastructure layer in software, is still a fairly new approach. It was born out of the need for organizations to effectively manage the rapidly growing number of microservices they are developing as they build applications.
For example, an e-commerce application app that typically has microservices architecture, with front-end and back-end components, needs services to communicate securely to support customer transactions. Such apps can include shopping cart and shipping services.
A service mesh can bind all the services in a Kubernetes cluster together so they can communicate with each other. It enables secure, service-to-service communication by creating a Transport Layer Security (TLS)-encrypted gateway. Service mesh features include traffic management, observability, and security.
What are data planes and control planes?
A typical service mesh has two main architectural components, a data plane and a control plane.
Data plane
The data plane is responsible for tasks such as health checking, routing, authentication, and authorization. It translates, forwards, and observes all network packets flowing to and from service instances. A service mesh may include more than one data plane.
Control plane
The control plane in a service mesh provides policy and configuration for all the data planes in the service mesh. Unlike a data plane, the control plane doesn't touch any packets or requests in the system. But it can turn all the data planes into one distributed system.
The control plane of a service mesh is usually human-operated through a command-line interface (CLI), web portal, or some other kind of user interface.
What is a sidecar proxy?
A service mesh is, essentially, a mesh of network proxies. App development teams implement the service mesh using sidecar proxies, which are additional containers that proxy all connections to the containers where the services live, such as in a container orchestrator like Kubernetes, also known as K8s.
As its name suggests, a sidecar proxy in a service mesh runs alongside a service or instances, such as a Kubernetes pod. Sidecar proxies enforce policies and collect telemetry in the data plane. They can handle communications, monitoring, and security-related issues between microservices.
Sidecar benefits for developers
Sidecar proxies allow developers to focus on developing, supporting, and maintaining the application code for microservices and help operations teams stay focused on running applications and maintaining the service mesh. In short, the service mesh lets these teams decouple their work.
A container orchestration framework is used to manage all the sidecar proxies and becomes an increasingly critical tool as an application's infrastructure expands.
What are options for building a service mesh?
There are several popular offerings, which are also open-source solutions, that organizations can consider using to build a service mesh. Consul, Kuma, AWS App Mesh, and Istio are examples of well-established options in the marketplace.