What Is Envoy Proxy?
I keep on seeing Envoy around the Web so decided to read more, and write about it. It’s of great interest out there, and gaining traction. Seems quite a good investment for Lyft.
Envoy in a nutshell…
From their website:
Envoy is an open source edge and service proxy, designed for cloud-native applications
Or, in greater detail…
Envoy is a … proxy designed for single services and applications, as well as a communication bus and “universal data plane” designed for large microservice “service mesh” architectures … Envoy runs alongside every application and abstracts the network by providing common features in a platform-agnostic manner. When all service traffic in an infrastructure flows via an Envoy mesh, it becomes easy to visualise problem areas via consistent observability, tune overall performance, and add substrate features in a single place.
Envoy Proxy is an open-source edge and service proxy developed by Lyft, specifically designed to address the operational challenges that organizations face when adopting microservices architecture, particularly in the context of cloud-native applications.
Why was Envoy created?
Matt Klein created Envoy at Lyft to solve the problems they were facing with their service-oriented architecture (SOA). In his 2017 talk, Matt talks about the motivation behind Envoy.
Lyft had a monolithic architecture and then transitioned to SOA, with its associated issues. The main one? Observability. When the system went down, it was tough to diagnose where the problem was. Was it in the application, the network, the hardware load balancers, or the cloud load balancers?
The network should be transparent to the applications. When network and application problems do occur, it should be easy to determine the source of the problem.
Envoy was created to solve the observability problem at Lyft. But it also offloaded the common network-related features from the service to the proxy. So, developers no longer needed to implement these in the service.
What does Envoy do exactly?
The Envoy proxy is supposed to be co-located with every service. All the requests and responses to and from the service are routed via the proxy. This is commonly called a sidecar proxy pattern. Now the proxy can capture all the traffic from all the services in the deployment. This makes it easy to capture observability stats helping to easily visualise problem areas.
Also, since the service-to-service communication now happens via the sidecar proxy, it is called a service mesh architecture.
Envoy as a service mesh sidecar proxy for services [Source: Envoy docs]
Many organizations use microservices to improve customer service through cloud and container technologies. However, they encounter issues like service discovery, load balancing, and security when managing these microservices. To address these challenges, Lyft developed Envoy proxy, which manages network traffic and ensures security for microservice architectures.
Envoy is an open-source edge and service proxy for cloud-native applications, written in C++. It operates as a sidecar alongside each service, separating network management from business logic. Envoy provides load balancing, resiliency features, and observability. It can also function as a network API gateway, known as discovery services or xDS. Additionally, Envoy offers features like retries, circuit breakers, and rate limiting, while collecting valuable traffic metrics for tools like Grafana. Alternatives to Envoy include Rust Proxy, NGINX Proxy, and HAProxy.
Use Cases for Envoy Proxy
Envoy proxy has two main uses: as a service proxy (sidecar) and as a gateway.
As a sidecar, Envoy enables communication between services by acting as an application proxy that follows the lifecycle of the parent application. It allows for the integration of different technology stacks, including legacy ones. Envoy has ingress listeners that receive requests from other services and forward them to the application, while egress listeners handle requests from the application going to other services.
As an API gateway, Envoy serves as a front proxy that accepts and directs client requests within a service mesh. It manages inbound traffic, performing functions like traffic routing, load balancing, authentication, and monitoring. The Envoy Gateway project simplifies its use as an API Gateway, especially for Kubernetes ingress.
The benefits of using Envoy include abstracting the network from applications, defining traffic controls centrally, managing both east-west (within data centers) and north-south (between data centers) traffic, monitoring traffic for optimal performance, and ensuring security through defined authentication and authorization rules. This makes Envoy particularly valuable for platform and network teams looking to manage cloud-native applications effectively.
Key reasons for its popularity
- Cloud-Native Foundation: Designed for containerized environments (like Kubernetes), it fits perfectly into modern architectures, separating networking concerns from application code.
- Service Mesh Data Plane: It’s the core engine for many service mesh solutions, managing inter-service communication (sidecar proxy).
- Observability: Offers rich statistics, access logging.
- Traffic Management: Handles advanced routing, load balancing, retries, and fault injection.
- Security: Acts as a gatekeeper for authentication and authorization, enabling zero-trust security models.
- Dynamic & Extensible: Can be configured dynamically via APIs and extended with technologies like WebAssembly, making it highly adaptable.
