A sidecar process separates a microservice’s business logic from reusable integration and infrastructure responsibilities. The service runs in one container, while an auxiliary sidecar handles concerns such as encryption, retries, load balancing, auditing, and observability. section 7.1.1
A service mesh uses the sidecar as a proxy:
- Routes network traffic through the sidecar before it reaches the business-logic container. section 7.1.1
- Keeps cross-cutting integration logic out of application code. section 7.1.1
- Uses configurable, reusable components, often supplied as off-the-shelf proxies. section 7.1.1
Microservice with a service-mesh sidecar
A microservice is deployed as two containers: one implements business functionality, and the other provides the proxy and system-level communication behavior. A control plane centrally configures the sidecar containers. section 7.1.1
Figure 7.3 An example of a service mesh architecture. Business logic and integration logic are separated into different containers. All network traffic flows through the sidecar component, which acts as a proxy to the component’s pure business logic.
Shows business logic and integration logic separated into containers, with traffic flowing through the sidecar proxy. section 7.1.1
Figure 7.4 Configuring sidecar containers through the control plane
Shows centralized configuration of sidecar containers through a service-mesh control plane. section 7.1.1
