Learn Envoy Proxy - History, Background & Why You Need Envoy

#Introduction

Before understanding how Envoy works, you need to know where it came from and what problem it solves. Episode 1 opens the series with Envoy's history and background: why Lyft built its own proxy in 2016, how Envoy evolved into the standard data plane for microservices, and why it's used as the foundation of Istio and many modern service meshes.

You'll also see how Envoy is positioned compared to tools you may already know: NGINX, HAProxy, and service mesh data planes. This matters because tool selection affects your architecture. After this episode, you'll have a solid reason why learning Envoy is worth 23 episodes.

#Envoy's Evolution as a Modern Layer-7 Proxy

#Birth at Lyft

In 2015, Lyft's team faced the classic microservices architecture problem: hundreds of services talking to each other, and every service needing to handle discovery, retry, timeout, TLS, and observability over and over. The solution they chose wasn't a per-language library, but a separate proxy attached to each service.

The result was Envoy, written in C++ by Matt Klein, and released as open source in September 2016. Less than a year later, in November 2017, Envoy was donated to the CNCF and became one of the fastest-adopted projects. Today Envoy is the foundation of Istio, Gloo, AWS App Mesh, and many service mesh platforms.

#Design Focused on Modern Networking

Envoy was designed not to replace web servers, but to be a highly flexible data plane proxy:

• Excellent support for HTTP/1.1, HTTP/2, and HTTP/3.
• Dynamic configuration via the xDS protocol without restarts.
• Rich observability: metrics, tracing, and built-in access logging.
• An extensible filter architecture for HTTP, TCP, and now WASM.

envoy --version
curl -s localhost:9901/server_info

The envoy --version command shows the binary version, while server_info from the admin interface displays runtime information. Both are useful for confirming that the image you're using is the right version.

#Envoy vs NGINX vs HAProxy

#Three Generations of Proxies

To be fair, let's compare with two popular proxies:

• NGINX is a web server and reverse proxy that's very efficient for HTTP, with a mature configuration ecosystem. It suits edge and content serving well.
• HAProxy is a legendary TCP/HTTP load balancer with high performance and solid security features.
• Envoy focuses on dynamic configuration, deep observability, and extensibility, making it better suited as a data plane in fast-changing microservices architectures.

The key difference is in how configuration works: NGINX and HAProxy generally reload on change, whereas Envoy can accept listener, cluster, and route changes live via xDS without restarting.

#Why Modern Teams Choose Envoy

There are several technical reasons Envoy wins in many architectures:

• Built-in observability: every request can be logged with full metadata, plus per-listener and per-cluster metrics.
• Advanced load balancing: support for ring hash, maglev, least request, and consistency hashing.
• Resilience: circuit breaking, retry, timeout, and outlier detection natively.
• Extensibility: a filter chain that can be plugged in for HTTP, TCP, and now WASM.
• Ecosystem maturity: used by Istio, Gloo, and many platforms as their data plane engine.

This ecosystem isn't just a list of names: Istio, Gloo, and AWS App Mesh all inherit the same Envoy foundation — the xDS protocol, filter chains, TLS context, and the listener-cluster-route model. That's why the skills you learn in this series carry over directly to any service mesh platform without starting from scratch. This is the biggest value of learning Envoy: one engine, many platforms built on it.

That value is also why the community and vendors keep investing: rich documentation, an ever-growing set of filters, and WASM support for extending capabilities without changing Envoy's core. By learning Envoy, you're buying a skill that doesn't go stale quickly, because the protocol foundation and configuration model stay stable even as surrounding tooling changes.

#Control Plane, Data Plane, and Service Mesh

#Envoy's Position in a Service Mesh

A service mesh usually separates two components: a control plane that decides policy, and a data plane that enforces that policy against traffic. Envoy sits on the data plane side: it's the one that actually receives requests, does routing, authentication, and records telemetry.

Istio, for example, uses Envoy as a sidecar in every pod, while its control plane (istiod) pushes configuration to Envoy through the xDS protocol. The same pattern is used by Gloo and Linkerd (with their own variations). By understanding Envoy, you're really understanding the engine behind the most popular service meshes.

#Do You Need Envoy Directly?

If your architecture is still simple, NGINX or HAProxy may be enough. Envoy only starts to shine when:

• Many services need dynamic routing and discovery.
• You need consistent observability across all services.
• You need mTLS encryption between services.
• Traffic needs to be canaried, mirrored, or fault-injected.

docker image inspect envoyproxy/envoy:v1.31.0 --format '{{.Config.Env}}'

The docker image inspect command reads image metadata, including the built-in environment variables used by Envoy's default configuration. It's a small example of how much information the same image can expose.

#Envoy's Core Strengths We'll Learn About

#The Four Main Pillars

Throughout this series, these four capabilities will keep coming up:

• Observability: Prometheus metrics, distributed tracing, and rich access logs.
• Advanced load balancing: round robin, least request, ring hash, and maglev.
• Circuit breaking: protecting backends from request surges.
• Configurability: static or dynamic via xDS, plus freely composable filters.
• Extensibility: native C++ filters or WASM that can be written without compiling Envoy.

We'll dissect these pillars one by one from episode 3 to 22. No other proxy offers this complete combination in quite the same way. Remember these pillars well, because every episode in this series revisits one of them from a different angle.

#Closing

Episode 1 placed Envoy in historical and ecosystem context: born from Lyft's needs, becoming the CNCF data plane standard, and now powering the largest service meshes in the world. You also understand Envoy's position compared to NGINX and HAProxy.

Key takeaways:

• Envoy was born at Lyft in 2016 and became a CNCF project in 2017.
• Envoy is a layer-7 data plane proxy for microservices, not a web server.
• NGINX and HAProxy remain great, but Envoy excels at dynamic config and observability.
• Service meshes separate control plane and data plane; Envoy is the data plane.
• Envoy's four pillars: observability, load balancing, circuit breaking, configurability.
• The official Envoy image can be run via docker run without any build.

In the next episode, episode 2, we'll discuss Envoy's core concepts and main architecture — listeners, clusters, routes, filter chains, and endpoints, plus the bootstrap configuration model and the role of control plane versus data plane and the xDS protocol. This is the mental foundation you'll use throughout all the remaining episodes.