Distributed Systems

Separate Network Management from Application Code

In a large Kubernetes cluster with hundreds of microservices continuously sending data to one another, two gigantic questions quickly arise: *How do we guarantee that all this inter-service network traffic is encrypted (Zero Trust)?* and *How do we very subtly forward 5% of the traffic to a new test version of our service without disturbing users (Canary Deployments)?* In the past, developers had to program all this logic—retries, timeouts, encryption, and routing—into their own Java or Go code. This led to massive duplication and vulnerable applications. The modern cloud-native solution for this is a **Service Mesh**.

The Sidecar Proxy Architecture

A Service Mesh is a dedicated infrastructure layer that is placed on top of your Kubernetes cluster. It consists of two components:

• The Data Plane: This is the collection of ‘Sidecar Proxies’ (usually based on Envoy) that are automatically injected as a featherlight background process *alongside* every microservice in the same Kubernetes Pod. All incoming and outgoing network packets from the application are intercepted and processed by this proxy.
• The Control Plane: The central brain that pushes the configurations, security certificates, and routing rules to all those thousands of sidecar proxies in the cluster.
• Mutual TLS (mTLS) Out of the Box: One of the most powerful benefits of a Service Mesh is that it automatically handles **mTLS** between all your microservices. Not only is all network communication encrypted over the internal cluster network, but both services also cryptographically verify each other’s identity. Your application code does not need to do anything at all for this; it happens completely transparently at the network level.

Traffic Shifting and Canary Deployments

Because the Service Mesh manages all traffic, you can set up advanced routing rules without modifying the code. Do you want to roll out a new version of the payment service? You configure the Service Mesh control plane to route exactly 95% of the traffic to v1 to send, and 5% to v2 (**Traffic Shifting** / Canary Deployment). You monitor via distributed tracing whether v2 errors occur; if so, you immediately shut down the tap with one simple configuration change.

Istio vs. Linkerd: The Choice in the Market

The two biggest players in the Service Mesh world are **Istio** and **Linkerd**:

• Istio: The absolute giant with an unprecedented amount of features (extensive security policies, telemetry, egress gateways, WebAssembly extensions). However, it is notorious for its complexity and higher memory consumption.
• Left: Designed based on the principle of ‘Ultra-lightweight and Simplicity’. Linkerd uses written Rust proxies that consume extremely little memory and boot up super fast, without the overwhelming complexity of Istio.

Choosing the right Service Mesh depends on the size and enterprise requirements of your organization. Read more about security and infrastructure at AG Connect.

 

Next: Chaos Engineering: The Proactive Breaking of Production Environments
Knowledge base overview