Updated January 26, 2018
Created at Lyft and now used inside companies including Google, Apple, Netflix and many more, Envoy is a high-performance open source edge, middle, and service mesh proxy that makes the network transparent to applications. Written in C++ for performance reasons, the Envoy out of process architecture can be used with any application, in any language or runtime; including HTTP/2 gRPC proxying, MongoDB filtering and rate limiting. Envoy is designed to minimize memory and CPU footprint, while providing capabilities such as load balancing and deep observability of network, service, and database activity.
Lyft’s Envoy: From Monolith to Service Mesh
Figure 1 illustrates the service mesh concept at its most basic level. There are four service clusters (A-D). Each service instance is co-located with a sidecar network proxy. All network traffic (HTTP, REST, gRPC, Redis, etc.) from an individual service instance flows via its local sidecar proxy to the appropriate destination. Thus, the service instance is not aware of the network at large and only knows about its local proxy. In effect, the distributed system network has been abstracted away from the service programmer.
Value Proposition: Envoy helps ease the transition to, and operation of, cloud-native architectures by managing the interactions among microservices in order to ensure application performance.
CIOs: Envoy simplifies management of cloud-native environments by providing a scalable service mesh that handles communications among microservices and components.
The industry is rapidly moving towards a polyglot (many language) microservice architecture. Networking and observability are notoriously some of the hardest things to get right in these architectures. Advanced features such as timeouts, rate limiting, circuit breaking, load balancing, retries, stats, logging, and distributed tracing are required to handle network failures in a fault tolerant and reliable way.
Organizations can solve microsevice networking in one of two ways:
Envoy fills the industry need for an extremely high performance, well designed, robust, and extensible proxy server.
Apple, Booking.com, eBay, F5, Google, IBM, Lyft, Medium, Microsoft, Netflix, Pinterest, Salesforce, Stripe, Tencent, Twilio, Verizon, VSCO, and many more.
Almost every company with a moderately-sized service oriented architecture is having the same problems:
In summary, an operational and reliability headache. Envoy solves the above problems for the enterprise allowing them to scale.
A service mesh control plane provides policy and configuration for all of the running data planes in the mesh. It does not touch any packets/requests in the system. The control plane turns all of the data planes into a distributed system. It is composed of the following pieces:
Service mesh data plane, sometimes called the sidecar proxy, touches every packet/request in the system and is responsible for service discovery, health checking, routing, load balancing, authentication/authorization, and observability:
No. Istio was announced in May 2017. The project goals of Istio look very much like the advanced control plane. The default proxy of Istio is Envoy. Thus, Istio is the control plane and Envoy is the data plane. In a short time, Istio has garnered a lot of excitement, and other data planes have begun integrations as a replacement for Envoy (both Linkerd and NGINX have demonstrated Istio integration). The fact that it’s possible for a single control plane to use different data planes means that the control plane and data plane are not necessarily tightly coupled. An API such as Envoy’s universal data plane API can form a bridge between the two pieces of the system.
For educational, technical and case study presentations about Envoy, check out:
As a CNCF hosted project, Envoy is part of a neutral community aligned with technical interests to help companies move to cloud native deployment models and help developers deliver on the promise of microservices and cloud native applications at scale. As Envoy grows, CNCF is helping build its community, marketing and documentation efforts. For more, read “Envoy joins CNCF.”
Envoy is an incubation level project, under the CNCF Graduation Criteria v1.0. The CNCF Graduation Criteria by the TOC provides every CNCF project an associated maturity level of either inception, incubating or graduated, which allows CNCF to review projects at different maturity levels to advance the development of cloud native technology and services. As an incubating project, Envoy must have documentation that it is being used successfully in production by at least three independent end users, have a healthy number of committers, and demonstrate a substantial ongoing flow of commits and merged contributions.
The cloud native ecosystem is still nascent and quickly evolving. CNCF recognizes that many promising technologies are emerging, some better suited for certain workloads, use cases or environments. CNCF’s goal is help many rising technologies mature. In this respect, we expect to have overlapping projects in some cases.