The Gateway API Is in the Firing Line of the Service Mesh Wars
It appears that the leading service mesh vendors are leaning towards the Kubernetes Gateway API, replacing Ingress with a single API that can be shared for the management of Kubernetes nodes and clusters through service mesh. While the Gateway API is designed to — like service mesh — for other uses for infrastructure management in addition to Kubernetes, it has been configured for Kubernetes specifically, created by Kubernetes creator Google.
“In general, if implementing the Gateway API for Kubernetes solves any operational friction that exists today between infrastructure providers, platform admins, and developers and can ease any friction developers experience in how they deploy North-South APIs and services, I think it makes sense to assess what that change will look like,” Nick Rago, field CTO for Salt Security, told The New Stack. This will put organizations in a good position down the road as the Gateway API specification matures and the gateway controller providers support more of the specs, reducing the need for vendor or platform-specific annotation knowledge and usage.
The Controversy
In that sense, this helps to explain to some degree why projects such as Linkerd, Istio and especially Google are offering this as a standard API relying on that. Although the push to incite organizations to Gateway APIs is not without controversy.
To wit, Linkerd’s August release of Linkerd 2.12 is what Buoyant CEO William Morgan describes as “a first step towards adopting the Gateway API as a core configuration mechanism.” However, Morgan is cautious and wary of standards in general and the risk of leading to vendor lock-in and other issues (as he vociferously expresses below).
Wariness of standards is not unreasonable given that they may or may not be appropriate for certain use cases, often depending on the maturity of the project.
“Standards can be a gift and a curse depending on the lifecycle stage of the underlying domain/products. They can be an enabler to allow higher-order innovation, or they can be overly constraining,” Daniel Bryant, head of developer relations at Ambassador Labs, told The New Stack. “I believe that Kubernetes ingress and networking is a well enough explored and understood domain for standards to add a lot of value to support additional innovation. This is why we’re seeing not only Ingress projects like Emissary-ingress and Contour adopt the Gateway API spec, but also service mesh products like Linkerd and Istio.”
Needless to say, Google obviously supports the Gateway API as far as standards go. In an emailed response, Louis Ryan, principal engineer, Google Cloud, offered this when prompted to explain why projects such as Linkerd, Istio and especially Google are supporting the Gateway API:
“Kubernetes has proven itself an effective hub for standardizing APIs with broad cross-industry engagement and support. The Gateway API has benefitted from this and, as a result, is a very well-designed solution for a wide variety of traffic management use cases; ingress, egress, and intra-cluster,” Ryan wrote. “Applying the Gateway API to mesh traffic management is a very natural next step and should benefit users by creating a standard that is thorough, community-driven and durable.”
The Istio Steering Committee’s decision to offer its service mesh project as an incubating project with the Cloud Native Computing Foundation (CNCF) in part to improve Istio’s integration with Kubernetes through the Gateway API (as well as with gRPC with proxyless mesh and Envoy). The Gateway API is also seen as a viable Ingress replacement.
“Donating the project to the CNCF offered reassurance that Istio is in good shape and that it’s not a Google project but a community project,” Idit Levine, founder and CEO of solo.io — the leading provider of tools for Istio — told The New Stack.
Istio’s move followed concerns by IBM — one of the original creators with Google and car-sharing provider Lyft — and other community members over the project’s governance, specifically Google’s advocacy of the creation of the Open Usage Commons (OUC) for the project in 2020.
In Linkerd’s case, Linkerd 2.12 provides a first step towards supporting the Kubernetes Gateway API, Linkerd CEO William Morgan said. While the Gateway API was originally designed as a richer and more flexible alternative to the long-standing Ingress resource in Kubernetes, it “provides a great foundation for describing service mesh traffic and allows Linkerd to keep its added configuration machinery to a minimum,” Morgan wrote in a blog post.
“The value of the Gateway API for Linkerd is that it’s already on users’ clusters because it’s a part of Kubernetes. So to the extent that Linkerd can build on top of the Gateway API, that reduces the amount of novel configuration machinery we need to introduce,” Morgan told The New Stack “Reducing configuration is part and parcel of our mission to deliver all the benefits of the service mesh without the complexity of other projects in the space.”
The portability promised by the Gateway API spec “is attractive to operators and platform engineers,” Bryant said. “Although many of them will chose a service mesh for the long haul, using the Gateway API does enable the ability to both standardize configuration across all service meshes deployed within an organization and also open to door to swapping out an implementation if the need arises (although, I’m sure this wouldn’t be an easy task),” Bryant said.
However, Linkerd also only provides a partial implementation of parts of the Gateway API (e.g. CRDs such as HTTPRoute) to configure Linkerd’s route-based policies. This approach allows Linkerd to start using Gateway API types without implementing the portions of the spec “that don’t make sense for Linkerd,” Morgan wrote in a blog post. As the Gateway API evolves to better fit Linkerd’s needs, Linkerd’s intention is to switch to the source types in a way that minimizes friction to our users.
“I think the biggest concern is that the Gateway API gets co-opted by one particular project or company and stops serving the needs of the community as a whole. While the Gateway API today is reasonably complete and stable for the ingress use case, making it amenable to service meshes is still an ongoing effort (the “GAMMA initiative”) and there’s plenty of room for that process to go south,” Morgan told The New Stack. “In particular, many of the participants in the Gateway API today are from Google and work on Istio; if the GW API develops in an Istio-specific way then it doesn’t actually help the end user because we’ll end up with projects (like Linkerd) just developing their own APIs rather than conforming to something that doesn’t make sense to them. (We saw this a little bit with SMI.)”
The Way to Go
Meanwhile, Linkerd is only providing parts of the Gateway API to remain in line with the service mesh provider’s vision to keep the service mesh experience “light and simple,” Torsten Volk, an analyst for Enterprise Management Associates (EMA), told The New Stack, “They will not want to adopt anything that creates admin overhead for their user base or could potentially introduce network latency that would take away from their high-performance claim,” Volk said. “They even advertise on their website, ‘as little YAML and as few CRDs as possible,’ meaning that they will want to critically evaluate any advanced features they might need to offer to fully support Gateway API. This would dilute simplicity and performance as Linkerd’s key differentiators against Istio.”
Istio and Linkerd, of course, represent competing service mesh alternatives. For some service mesh users, Istio is GKE’s service mesh of choice and therefore, if GKE support is critical, Istio “might be the way to go,” Volk said. “However, most other vendors of proxies, ingress controllers and service mesh platforms have also indicated their support of Gateway API, at some point in the future,” Volk said. “Therefore, it might be wisest to trust your vendor of choice to ultimately support the critical elements of the Gateway API standard.”
HashiCorp, Kong, Ambassador and others are supporting the API Gateway, Bryant noted. Already, “the majority of Kubernetes API Gateway providers offer some level of support for the Gateway API spec,” Bryant said. “Both Emissary-ingress and Ambassador Edge Stack have offered this type of support for quite some time, and this will continue to evolve in the future.“
Ambassador Labs is also working with other founding contributors on the Envoy Gateway project, which will be the reference implementation of the Kubernetes Gateway API spec, Bryant said. They include Tetrate, VMware, Fidelity and others. “Our goal here is to collaborate on a standardized K8s API Gateway implementation that we can all build upon and innovate on top of,” Bryant said.
