Today we are thrilled to announce Envoy Gateway, a new member of the Envoy Proxy family aimed at significantly decreasing the barrier to entry when using Envoy for API Gateway (sometimes known as “north-south”) use cases.

History

Envoy was released as OSS in the fall of 2016, and much to our amazement quickly gained traction throughout the industry. Users were drawn to many different aspects of the project including its inclusive community, extensibility, API-driven configuration model, powerful observability output, and increasingly extensive feature set.

Although in its early history Envoy became synonymous with “service mesh,” its first use at Lyft was actually as an API gateway / edge proxy, providing in-depth observability output that aided Lyft’s migration from a monolithic to a microservice architecture.

Over the last 5+ years, we have seen Envoy adopted by a tremendous number of end users, both as an API gateway and as a sidecar proxy in “service mesh” roles. At the same time we have seen a large vendor ecosystem spring up around Envoy, providing a multitude of solutions both in the OSS and proprietary domains. Envoy’s vendor ecosystem has been critical to the project’s success; without funding for all of the employees that work part or full-time on Envoy the project would certainly not be what it is today.

The flip side of Envoy’s success as a component of many different architecture types and vendor solutions is that it is inherently low level; Envoy is not an easy piece of software to learn. While the project has had massive success being adopted by large engineering organizations around the world, it is only lightly adopted for smaller and simpler use cases, where nginx and HAProxy are still dominant.

The Envoy Gateway project was born out of the belief that bringing Envoy “to the masses” in the API gateway role requires two primary things:

• A simplified deployment model and API layer aimed at lighter use cases.
• Merging the existing CNCF API gateway projects (Contour and Emissary) into a common core that can provide the best possible onboarding experience, while still allowing vendors to build value-added solutions based on Envoy Proxy and Envoy Gateway.

We strongly believe that if the community converges around a single Envoy branded API gateway core, it will:

• Reduce duplicative efforts around security, control plane technical details, and other shared concerns.
• Allow vendors to focus on layering value added functionality on top of Envoy Proxy and Envoy Gateway in the form of extensions, management plane UI, etc.
• Lead to a “rising tide lifts all boats” phenomenon in which more users around the world enjoy the benefits of Envoy, whether their organization is large or small. More users feed the virtuous cycle of more potential customers, more support for the core Envoy project, and a better overall experience for all.

Project outline

At a high level, Envoy Gateway can be thought of as a wrapper around the Envoy Proxy core. It will not change the core proxy, xDS, go-control-plane, etc. in any way (other than potentially driving features, bug fixes, and general improvements!). It will provide the following functionality:

• A simplified API for the gateway use case. The API will be the Kubernetes Gateway API with some Envoy-specific extensions. This API was chosen because deployment on Kubernetes as an ingress controller is the initial focus for the project and because the API has broad industry buy-in.
• A “batteries included” experience that will enable users to get up and running as fast as possible. This includes tooling to provision controller resources, control plane resources, proxy instances, etc.
• An extensible API surface. While the project will aim to make common API gateway functionality available out of the box (e.g., rate limiting, authentication, Let’s Encrypt integration, etc.), vendors will be able to provide SaaS versions of all APIs, provide additional APIs and value added functionality such as WAF, enhanced observability, chaos engineering, etc.
• High quality documentation and getting started guides. Our primary goal with Envoy Gateway is to make the most common gateway use cases trivial to stand up for the average user.

On the topic of APIs, we believe that one area that has led to significant confusion is the effective reimplementation of Envoy’s xDS APIs in other projects when targeting advanced use cases. This pattern causes users to have to learn multiple sophisticated APIs (which ultimately translate back to xDS) in order to get their job done. As such, Envoy Gateway is committed to a “hard line in the sand” in which the Kubernetes Gateway API (and any permissible extensions within that API) is the only additional API that will be supported. More advanced use cases will be served by an “xDS mode” in which existing API resources will be automatically translated for the end user, who can then switch to utilizing the xDS APIs directly. This will lead to a crisper primary API while allowing an escape hatch for organizations that might outgrow the expressiveness of the primary API and wish to utilize the full power of Envoy via xDS.

Next steps

Today we are thankful for the initial sponsors of Envoy Gateway (Ambassador Labs, Fidelity, Tetrate, and VMware) and are excited to start on this new journey with all of you. The project is very early with the focus so far having been to agree on goals and high level design, so it’s a great time to get involved, either as an end user or as a system integrator.

We also want to make it extremely clear that existing users of Contour and Emissary will not be left behind. The project (and VMware and Ambassador Labs) is completely committed to ensuring a smooth eventual migration path for users of those projects to Envoy Gateway, either via translation and replacement or via those projects becoming wrappers around the Envoy Gateway core.

We are extremely excited about bringing Envoy to a larger group of users via the Envoy Gateway project, and we hope you will join us on our journey!