NGINX Steps into the Service Mesh Fray Promising a Simpler Alternative
Earlier this month, NGINX introduced the NGINX Service Mesh (NSM), a free and open source service mesh that uses NGINX Plus, the company’s commercial version of its open source NGINX proxy, to power its data plane. While many service meshes are built from entirely open source components, NGINX Vice President of Marketing Rob Whiteley said that rather than putting yet another open source solution on the market, they wanted to focus on targeting NSM to the missing piece in the current market, which he sees as customers struggling with the scale and complexity of Istio.
“Istio was born in Google and designed with the sophistication to run billions of containers and thousands of services. As a result, there’s a certain amount of overhead that comes with Istio that manifests complexity. It’s also a highly opinionated development, meaning there’s other open source components baked into it. Technically, you can swap some of them out, but it wasn’t designed to be as modular,” said Whiteley. NGINX Service Mesh “is lighter weight, easier to install, and really designed for people that have just begun to outgrow an ingress controller-only traffic pattern. We wanted to strip out a lot of those components. We have some components that you’ll find in other service mesh solutions, but we didn’t necessarily need as complicated key management, tracing and observability as you would if you’re designing a solution that’s meant to handle an order of magnitude or more in terms of complexity.”
Instead of directly integrating these various components, NSM deploys sidecar proxies alongside them for integration. At launch, those supported components include Grafana, Kubernetes Ingress controllers, SPIRE, NATS, Open Tracing and Prometheus. And by using NGINX Plus as both the data plane for east-west traffic and the Ingress controller for north-south traffic, users get all of the standard NGINX Plus features while also having an easy path for onboarding, configuration, and management.
“NGINX is already the default ingress controller in the market, so really the goal of NGINX Service Mesh was to provide a next logical step, where you’re already using NGINX for ingress and egress out of the cluster, now you just need to handle some of the service traffic, east-west instead of north-south,” said Whiteley.
Among the features that NGINX Plus brings to NSM are mTLS authentication, load balancing, high availability, rate limiting, circuit breaking, blue-green and canary deployments, and access controls. NGINX Plus is included free with NSM as a binary, with some environmental restrictions that prevent it from being used separately. With NGINX Plus handling east-west and north-south traffic, Whiteley notes that NGINX’s API gateway is the final component needed to bring everything together into a single platform.
“Our vision is to bring that all together in a single platform. Our API gateway is technically separate from service mesh, even though it’s all NGINX Plus. It’s all just different states of configuration of the same basic data plane,” said Whiteley. “We think there’ll be advantages we can bring in the future to making sure that the ingress, the sidecar proxy, and the API gateway, which are all really just kind of hyper-specialized versions of a proxy, are brought together under the same operational platform, so that you don’t have as many moving parts. If you make a policy update, you should be able to make it in one place and have it be honored in the other two.”
Having NGINX at its core, said Whiteley, is really an advantage for those companies that are still looking to integrate some of its legacy deployments with a Kubernetes environment. Doing so with the Envoy-based Istio service mesh, he said, was more complicated and something still “on the Istio roadmap.” In this way, NSM is targeted as a sort of beginner’s service mesh, and Whiteley says they have a long term goal to make it a seamless transition to move from NSM to Aspen Mesh, the more advanced, Istio-based service mesh built by its now-parent company F5 Networks.
Another goal with NSM, said Whiteley, is to bring in a better management plane. Currently, the Service Mesh Interface (SMI) is supported, and the NGINX Controller management plane is expected to be added, bringing in more visualization and a GUI to what is currently primarily a command-line interface experience.
Looking beyond NSM, Whiteley said they have some hopes for NGINX Unit to “introduce something that’s a little bit different and more novel to advance the industry dialogue.”
“We think there’s an option in the future to have a sidecar-less service mesh, where you’re not injecting sidecars in each service,” said Whiteley. “Instead, you load your code, and you execute it, and the default runtime environment that’s executing your code has all the built-in proxying capabilities needed to handle east-west. It would take things down from a two container to one container kind of model.”
