# Service Mesh

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

## 1. The Problem: Microservices Complexity

In a microservices architecture, you have hundreds of services talking to each other. Each service needs to handle:
*   **Reliability:** Retries, timeouts, circuit breaking.
*   **Security:** Encryption (TLS), authentication.
*   **Observability:** Logging, metrics, tracing.

If you implement this logic inside every service (e.g., using a library), you end up with code duplication and language lock-in (you need a library for Java, one for Go, one for Node.js).

## 2. The Solution: The Sidecar Pattern

A Service Mesh extracts this logic out of your application code and puts it into a lightweight network proxy (the **Sidecar**) that runs alongside your service.

*   **Data Plane:** The set of sidecar proxies (e.g., Envoy, Linkerd-proxy). They intercept all network traffic entering and leaving the service.
*   **Control Plane:** The management component (e.g., Istio, Linkerd control plane). It configures the proxies and gathers telemetry.

## 3. Key Features

### Traffic Management
Control the flow of traffic and API calls between services.
*   **Canary Rollouts:** Send 1% of traffic to v2.
*   **Circuit Breaking:** Stop sending traffic to a failing service to prevent cascading failures.
*   **Fault Injection:** Intentionally introduce delays or errors to test resilience (Chaos Engineering).

### Security (mTLS)
*   **Mutual TLS:** Automatically encrypts traffic between services.
*   **Identity:** Verifies that Service A is allowed to talk to Service B.

### Observability
Since all traffic goes through the proxies, the mesh can automatically generate:
*   **Metrics:** Success rates, latency, throughput.
*   **Distributed Tracing:** Spans for every hop.
*   **Access Logs:** Who called whom.

## 4. Common Implementations

### Istio
The most feature-rich and widely used service mesh. Uses **Envoy** as its sidecar proxy.
*   *Pros:* Extremely powerful, huge ecosystem.
*   *Cons:* Complex to set up and manage (though improving).

### Linkerd
A lighter, faster, Kubernetes-native service mesh. Uses a custom Rust-based micro-proxy.
*   *Pros:* Very fast, simple ("it just works"), low resource usage.
*   *Cons:* Fewer advanced features than Istio.

## 5. The Sidecar Pattern Explained

The Sidecar pattern is a single-node pattern made up of two containers: the application container and the sidecar container.

*   **Lifecycle:** The sidecar shares the same lifecycle as the parent application. It is created and destroyed alongside the application.
*   **Resources:** They share the same resources (network, storage) within the Pod (in Kubernetes).
*   **Transparency:** The application is often unaware of the sidecar. It simply sends traffic to `localhost` or a service name, and the sidecar intercepts it via `iptables` rules.

### Why "Sidecar"?
The name comes from the sidecar attached to a motorcycle. The motorcycle (application) is the main driver, but the sidecar (proxy) provides auxiliary features without changing the motorcycle itself.

[[programming/microservices-architecture]]
[[programming/kubernetes-basics]]
[[programming/cloud-native-concepts]]
[[programming/observability-vs-monitoring]]
[[programming/distributed-tracing]]