Skip to main content
When exploring service mesh architectures, Envoy frequently appears as the recommended proxy. This article explains what Envoy does, why teams adopt it, and common deployment patterns — with a focus on how Envoy offloads cross-cutting networking concerns so applications can concentrate on business logic. What is a proxy? A proxy sits between clients and an application and handles cross-cutting concerns such as TLS termination, authentication, retries, and observability. Offloading these responsibilities to a proxy removes the need to embed the same logic in every service. Typical request flow:
  • A user sends a request to the proxy.
  • The proxy applies TLS/mTLS, authentication, retries, and other policies.
  • The proxy forwards the request to the application.
A diagram titled "Proxy" showing a user icon sending requests to a proxy component that lists TLS, Auth, and Retry. The proxy forwards the requests to an application box containing the business logic.
What is Envoy? Envoy is an open-source high-performance L7 (application-layer) proxy originally developed at Lyft to address challenges in large microservice environments. It also supports L4 traffic and provides a flexible, performant data plane suitable for edge and in-cluster proxying. Key capabilities include: Envoy graduated into the cloud-native ecosystem and is part of the CNCF. Because of its performance and extensibility, many service meshes use Envoy as the data plane and control it through a control plane using xDS. Why use Envoy?
  • Centralizes networking and security concerns outside application code.
  • Provides production-grade observability (metrics, traces, logs) out of the box.
  • Supports modern protocols (HTTP/2, gRPC) and advanced L7 routing features.
  • Is highly extensible via filters and dynamic configuration.
Envoy as a sidecar A common deployment pattern for Envoy in Kubernetes is the sidecar model: Envoy runs in a separate container inside the same Pod as your application. In this configuration, Envoy intercepts inbound and outbound traffic, applying routing, security, and telemetry policies without modifying application code. Typical sidecar responsibilities:
  • Inbound: Apply mTLS, routing rules, and health checks before delivering traffic to the app.
  • Outbound: Perform retries, circuit-breaking, and route requests to other services.
  • Observability: Emit metrics and traces for platform telemetry pipelines.
A simple diagram showing the Envoy logo on the left and a Kubernetes pod on the right with a magenta Envoy sidecar proxy inside it alongside the main container. Arrows indicate Envoy routing incoming and outgoing traffic between the pod and external requests.
Deploying Envoy as a sidecar enables platform teams to centralize networking, security, and observability concerns while letting application developers focus on business logic. Most service meshes use Envoy as their data plane and control it via a control plane using the xDS APIs.
Further reading and references

Watch Video