Envoy Proxy Unveils Envoy Gateway For North-South Traffic
The team behind Envoy Proxy has announced Envoy Gateway, new open source software aiming to improve accessibility for using Envoy for north-south traffic use cases. If accepted as a standard, Envoy Gateway could become a foundation for API gateway and management platforms that want to be compatible with cloud-native technologies such as service mesh and Kubernetes.
I recently met with Varun Talwar, co-creator of Istio and gRPC and co-founder of Tetrate. According to Talwar, Envoy Gateway delivers the ability to apply consistent policies around cloud-native traffic. Below, we’ll explore what Envoy Gateway is and how it works. We’ll also consider how the introduction of Envoy Gateway might affect the Envoy ecosystem and related fields.
What is Envoy?
First off, for those unfamiliar, Envoy Proxy is an open source cloud-native proxy. It was initially designed at Lyft and was then released as OSS in 2016. Envoy has been instrumental to the proliferation of service mesh; it’s the sidecar proxy at the heart of Istio and other service meshes.
A service mesh provides a standard networking layer for uniting an otherwise disparate internal microservices architecture. But Envoy isn’t relegated to only service mesh—it’s been used as a front proxy, sidecar proxy and middle proxy. Lyft, in fact, first used it as an API gateway.
What Envoy Lacked
With so many Envoy-based solutions on the market, some proponents argue for using Envoy as a standard mechanism to externalize internal microservices to the outside world, also known as north-south traffic. Yet so far, there hasn’t been a streamlined, standardized cloud-native approach to accomplishing this.
“What was missing was a simple mode for developers so they can use it as a front API gateway or ingress into Kubernetes,” explained Talwar. “Many simple things, such as API limiting, authentication and OAuth integration should be in Envoy out of the box.”
K8s provides some of this functionality natively, but according to Talwar, it comes with too many bells and whistles, which are unnecessary for simple, more lightweight use cases. Furthermore, The Kubernetes Gateway API doesn’t have all the extensions it requires to function as a true API gateway, Talwar explains. (The two terms are similar, but the semantic nuances make all the difference!).
Introducing: Envoy Gateway
Thus, recent efforts have been focused on standardizing Envoy as a more cloud-native, fully-functional API gateway to securely expose microservices. Envoy Gateway brings Envoy Proxy to the masses in the API gateway role, says Talwar, with a lighter standardized API for Kubernetes ingress.
The Envoy Gateway project will expose a simple and expressive API. “[The] API will be the Kubernetes-native Gateway API, plus Envoy-specific extensions and extension points,” according to the documentation. While Envoy Gateway is not wholly dependent upon K8s, it was designed to be Kubernetes-native. “The Kubernetes community already agrees on Kubernetes Gateway API, so we might as well build on top of that,” says Talwar.
Once traffic connectivity is abstracted with Envoy, components like security and networking become unshackled. “That’s why strategically, it’s very powerful,” Talwar explains. Envoy Gateway could decrease the barrier to quickly assigning standard policies for off-cluster communication at a time when many public-facing APIs are coming to the market.
The Impact of Envoy Gateway
Envoy Gateway isn’t the only project looking to bring north-south functionality to Envoy. Other CNCF API gateway projects, such as Contour and Emissary, are attempting something similar. According to Talwar, the Envoy ecosystem would benefit from merging these pre-existing projects to decrease duplicative efforts, and he is convinced there will be a migration path. “It doesn’t make sense for ten companies to do the exact same thing on Envoy,” says Talwar.
Reducing choice in open source packages could reduce confusion for users, too. This sentiment is echoed by Matt Klein, an engineer at Lyft and co-creator of Envoy, who, in a blog post, advocated “merging the existing CNCF API gateway projects (Contour and Emissary) into a common core.” As a result, we may soon see the core of API runtime begin to be standardized.
In the future, Talwar predicts, vendors will likely differentiate themselves on top of such a standardized runtime by offering specialized functionality, such as enhanced observability with AI/ML, WAF functionality or chaos engineering. And commercial API management will likely continue to provide the outward-facing developer portal and documentation generation. “That’s the level where we should have vendor differentiation, not on this layer,” says Talwar. “The API runtime layer is just too low to remain un-standardized between vendors.”
Final Thoughts: An Architectural Shift
The software infrastructure backend is inherently shifting and becoming more dynamic over time. This is especially true in the world of Kubernetes, which offers dynamic scalability suited for distributed microservices environments. And now, Talwar foresees another major shift on the horizon. “Standardization on the runtime architectural patterns is one of those shifts,” he says. “This will have an impact on the market.”
Of course, the Envoy Gateway project is still in its nascent stage. But it appears to be progressing rapidly—the goal is to first complete common functional tasks such as routing, authentication and JWT validation, says Talwar. A next step will be using WebAssembly to enable easier customizations, he adds.
“The goal is to power the world’s application traffic, no matter whether that’s north, south, east, or west traffic. If we can have standardized traffic based on Envoy, then we are getting closer to fulfilling that mission.”
For more information, you can follow the Envoy Gateway project on GitHub, join the Envoy Proxy Slack channel or drop in on the weekly Envoy Gateway meeting.