In the world of Kubernetes Ingress controllers, NGINX has had a very successful run. NGINX Ingress Controller is widely deployed for commercial Kubernetes production use cases while also being developed and maintained as an open source version. So, you might think that when a big improvement came to Kubernetes networking – the Gateway API – we’d keep a good thing going and implement it in our existing Ingress products.
Instead, we chose a different path. Looking at the new Gateway API’s amazing possibilities and our chance to completely reimagine how to handle connectivity in Kubernetes, we realized that shoehorning a Gateway API implementation into our existing Ingress products would limit this boundless future.
This is why we decided to launch our own Gateway API project – NGINX Gateway Fabric. The project is open source and will be operated transparently and collaboratively. We’re excited to work with outside contributors and to share this journey with others, as we hope to create something that is special and unique.
How We Arrived at Our Gateway API Decision
While the decision to create an entirely new project around the Gateway API comes from optimism and excitement, it’s grounded in sound business and product strategy logic.
Longtime Kubernetes followers likely already know about NGINX Ingress Controller’s open source and commercial versions. Both deploy the same battle-tested NGINX data plane that runs in the NGINX Open Source and NGINX Plus reverse proxies. Before Kubernetes, NGINX’s data plane already worked great for load balancing and reverse proxying. In Kubernetes, our Ingress controllers achieve the same types of critical request routing and application delivery tasks.
NGINX prides itself on building products that are lightweight, high-performance, well-tested, and ready for demanding environments. So, the product strategy for Kubernetes Ingress control mirrored our product strategy for reverse proxies – make a robust open source product for simpler use cases and a commercial product with additional features and capabilities for production Ingress control in business-critical application environments. That strategy worked in the world of Ingress control, partially because Ingress control lacked standardization and required significant custom resource definitions (CRDs) to deliver advanced capabilities like load balancing and reverse proxy, which developers and architects enjoyed in networking products outside of Kubernetes.
Our users rely on and trust NGINX Ingress Controller, and the commercial version already has many of the key advanced capabilities that the Gateway API was designed to address. Additionally, NGINX has been participating in the Gateway API project since early on, and we recognized that it was going to take a few years for the Gateway API ecosystem to fully mature. (In fact, many of the Gateway API’s specifications continue to evolve, such as the GAMMA specification to make it better able to integrate with service meshes.)
But we decided that shoehorning in beta-level Gateway API specifications to NGINX Ingress Controller would inject unnecessary uncertainty and complexity into a mature, enterprise-class Ingress controller. Anything we sell commercially must be stable, reliable, and 100% production ready. Gateway API solutions will get there too, but the process is still only at its beginning.
Our Goals with NGINX Gateway Fabric
With NGINX Gateway Fabric, our primary goal is to create a product that stands the test of time, in the way that NGINX Open Source and NGINX Plus have. To reach the point where we felt comfortable labeling our Gateway API project “future-proof,” we realized we’d need to experiment with architectural choices for its data and control planes. For example, we might need to look at different ways to manage Layer 4 and Layer 7 connectivity or minimize external dependencies. Such experimentation is best performed on a blank slate, free of historical precedents and requirements. While we’re using the tried and tested NGINX data plane as a foundational component of the NGINX Gateway Fabric, we’re open to new ideas beyond that.
We also wanted to deliver comprehensive, vendor-agnostic configuration interoperability for Gateway API resources. One of the Gateway API’s biggest improvements over the existing Kubernetes Ingress paradigm is that it standardizes many elements of service networking. This standardization should, in theory, lead to a better future where many Gateway API resources can easily interact and connect.
However, a key to building this future is to leave behind the world of vendor-specific CRDs (which can result in vendor lock-in). That can get very challenging in blended products that must support CRDs designed for the world of Ingress control. And it’s easier in an open source project that focuses on interoperability as a first-order concern. To ditch the tightly linked CRDs, we needed to build something that solely focuses on the new surfaces exposed by the Gateway API and its constituent APIs.
Join Us on the Gateway API Journey
We’re still in the very early days. Only a handful of projects and products have implemented the Gateway API specification, and most of them have elected to embed it within existing projects and products.
That means it’s a time of great opportunity – the best time to start a new project. We’re running the NGINX Gateway Fabric project completely in the open, with transparent decision-making and project governance. Because the project is written in Go, we invite the massive Gopher community to make suggestions, start filing PRs, and or reach out to us with ideas.
It’s possible the Gateway API will shift the whole Kubernetes landscape. Entire classes of products may no longer be necessary, and new products might pop up. The Gateway API offers such a rich set of possibilities that we honestly don’t know where this will end up – but we’re really looking forward to the ride. Come along for the journey, it’s going to be fun!
You can start by:
- Joining the project as a contributor
- Trying the implementation in your lab
- Testing and providing feedback
To join the project, visit NGINX Gateway Fabric on GitHub.
If you want to chat live with our experts on this and other NGINX projects, stop by the NGINX booth at KubeCon North America 2023. NGINX is proud to be a Platinum sponsor of KubeCon NA this year, and we hope to see you there!