NGINX Commits to Open Source and Kubernetes Ingress
At this year’s NGINX Sprint 2.0 virtual conference, NGINX, the arm of F5 behind the popular open source web server/load balancer and reverse proxy of the same name, made several declarations as to its intentions concerning open source software, undefined upcoming open source releases and its participation in the Kubernetes Ingress project.
The first point, NGINX’s commitment to open source, comes partly as a defense against any perceived or feared changes after NGINX’s 2019 acquisition by F5. In a blog post and during his keynote at Sprint 2.0, Rob Whiteley, general manager of the NGINX Product Group at F5, discussed how the company wants to clearly define its approach to open source software moving forward, as well as commit further to open source participation in the months ahead.
“When F5 acquired NGINX, I think the fear was that we were going to abandon our open source roots, and that anything we did in open source would just be for a revenue benefit. The experience we’re having as part of F5 is the opposite. F5 has additional resources and capability that we couldn’t afford as a standalone NGINX,” said Whiteley in an interview. “And F5 gets that, like most modern, larger enterprises, if you don’t have an open source strategy, you will not remain relevant in the modern application landscape. Part of what I want to just assure folks is we don’t have a secret agenda. This is not about getting a Trojan horse for commercial F5 or NGINX software. It is, candidly, us remaining relevant in the application landscape and making sure that now that we have the capability to invest more, we do that.”
Regarding NGINX’s open source software moving forward, Whiteley said the company’s executives have committed to a model where open source will be meant for use in production and nothing less. Whiteley even said that, if they were able to go back in time, certain features currently available only in NGINX Plus would be available in the open source version.
“One model is ‘open source’ equals ‘test/dev, ‘ ‘commercial’ equals ‘production,’ so the second you trip over into production, you kind of trip over a right-to-use issue, where you then have to start licensing the technology. We do not want to go that route because it penalizes developers for getting their applications in production,” said Whiteley. “What we want to do is focus on, as the application scales — it’s serving more traffic, it’s generating more revenue, whatever its goal is as an app — that the investment is done in lockstep with the success and growth of that.”
This first point, NGINX’s stated commitment to open source, serves partly as background for the last point mentioned above, wherein NGINX says it will devote additional resources to the Kubernetes community, a move partly driven by the fact that Alejandro de Brito Fonte, the founder of the ingress-nginx project, has decided to step aside. These resources will come in the form of a full‑time employee to help manage the community Ingress project and several more employees devoted to the Kubernetes Gateway API special interest group (SIG) to help advance Kubernetes ingress and egress functionality.
As further background, Whiteley explained that around five years ago, the NGINX open source was adapted to be a formally included ingress controller for the default Kubernetes deployment. This adaptation required a lot of additional functionality on top of the standard open source NGINX, which was built using Lua modules. Following that, NGINX saw interest from customers in a form of NGINX that didn’t require Lua, and so they built yet another open source NGINX ingress controller. Finally, they released an additional commercial version that had features based on NGINX Plus. All of this has led to confusion among users, and their devotion of resources is partly in hopes of clearing up that confusion, Whiteley said.
“We saw it as an opportunity to donate people to the project, first and foremost, to make sure that we’re continuing to project-manage it, continuing to make sure that it’s alive and well and accepting contributions,” he said. “What we want to do is work with the community to also see if there is an opportunity to improve the Kubernetes Ingress, rewrite some of those Lua modules, maybe port them. We want to go through the effort of starting to rewrite and merge so that we don’t have two open source ingress controllers that are doing the same thing. Now, we have to be careful, because we don’t want to show up in the community and feel like we’re muscling our way in and creating any kind of agenda.”
While the consolidation of any ingress controllers is certainly pending the decision of the larger community, Whiteley said there were also other realms that they hoped to bring their expertise to, such as with participation in SIG Network, where they will be working on the Gateway API. The Gateway API, Whiteley explained, is “essentially a new project being spun up to look at how do we evolve the ingress controller to be able to do both ingress and egress?” He further explained that NGINX had worked to extend its open source ingress controller using custom resource definitions (CRDs) instead of the annotations used by the default ingress-nginx, and that the Gateway API team was interested in using this approach.
“[They] approached us early on and said, ‘Hey, we like what you did with CRDs; we’d like to essentially create a next-generation gateway device with that level of extensibility built in natively,’ so we’ve been consulting on the project,” Whiteley said. “We will natively support a version of the Gateway API when it comes out on NGINX. Our hope is to eliminate the confusion we created in Ingress, which is, there is a community version and a separate version supported by NGINX. We’ll just make sure from day one that we’re one of several vendors that support the standard, and it will be just one open source version of it, so we can eliminate some of that confusion.”
