The Service Mesh

Basic Architecture

Every service mesh solution should have two distinct components that behave somewhat differently: a data plane and a control plane. Figure 1-1 presents the basic architecture.

Figure 1-1. Basic service mesh architecture

The data plane is the layer responsible for moving your data (e.g., service requests) through your service topology in real time. Because this layer is implemented as a series of interconnected proxies, when your applications make remote service calls, they’re typically unaware of the data plane’s existence. Generally, no changes to your application code should be required in order to use most of the features of a service mesh. These proxies are more or less transparent to your applications. The proxies can be deployed several ways (one per physical host, per group of containers, per container, etc.). But they’re commonly deployed as one per communication endpoint. Just how “transparent” the communication is depends on the specific endpoint type you choose.

A service mesh should also have a control plane. When you (as a human) interact with a service mesh, you most likely interact with the control plane. A control plane exposes new primitives you can use to alter how your services communicate. You use the new primitives to compose some form of policy: routing decisions, authorization, rate limits, and so on. When that policy ...