Among the most significant announcements at the recent Kubecon Europe was the introduction of Envoy Gateway – not only for what it will offer to Envoy developers, but even more for its implications for the community, in the hope it provides those dismayed by the sprawl of Kubernetes-related projects with overlapping functionality, as evidenced by the notorious CNCF Cloud Native Landscape diagram.

Envoy Gateway aims to replace existing Envoy add-on projects including the VMWare-sponsored Contour and Ambassador’s Emissary, and has the support of both.

Envoy creator Matt Klein posted: “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.”

Envoy is a proxy, and one of its key uses is to manage traffic between an application API and the outside world. Kubernetes has a native Gateway API, and the new project will implement this as well as continuing to support xDS, the Envoy API. The idea is that Envoy Gateway will be easy to use for basic use cases.

DevClass spoke to Varun Talwar, co-founder of Istio and gRPC when at Google, and now CEO of Tetrate, a company which claims to be the biggest single committer to Envoy Proxy. Although Klein posted about “merging the existing CNCF API gateway projects Contour and Emissary into a common core,” Talwar said it is actually a new project and at an early stage. “Really right now it is just an announcement of intent to do work. There isn’t much code in it yet,” he said.

“The fact that we agreed to consolidate, the fact that we agreed to make a simple mode in Envoy and standardise on the Gateway API are substantial moves for not just Envoy but the community in general.” Nevertheless, Talwar believes code will be added rapidly and that there will be functional code in time for KubeCon North America in October, and “production quality” before the end of the year.

How should we distinguish between healthy diversity and “duplicative efforts” that waste time? “It’s good to have a thriving ecosystem and choice,” said Talwar, “but when it gets to a point where choice is leading to confusion and there is very little differentiation between the choices, and they are all based on the same underpinning, in this case Envoy, it begs to ask that question. We had a large financial ask, why do I have these five different versions of ingress even though I am on Envoy?”

There are potential migration issues, but all these projects will continue to be maintained, bearing in mind too that Envoy Gateway is a long way from shipping.

Could there be more consolidation in the Kubernetes ecosystem? “It takes a few willing parties … I hope it does happen. It requires putting aside egos and some compromises,” he told us. “Hence it’s hard. Everyone knows that Envoy is a stronger choice as a proxy. But why does Kubernetes not ship with default Envoy as the ingress controller? It should. It requires willingness and energy from stakeholders. In answer to your question, yes it should happen, but will it happen? I don’t think it will happen that quickly.”