The Many Facets of NGINX

You may be familiar with the NGINX webserver, but did you know that NGINX makes a bunch of other products as well?

NGINX has overtaken the venerable Apache webserver to become the most popular webserver for Internet facing websites, according to W3Techs. NGINX claimed in its recent Cloud Field Day 11 appearance that 73% of the top 1000 websites in the world are powered by NGINX.

In the interests of full disclosure, I personally use the open-source version of NGINX for all my sites (including this one) having moved across to it from Apache many years ago. I don’t do anything particularly complicated with it, and it works just fine. However, we do use Traefik as the ingress and service discovery layer in PivotNine’s production container environment in conjunction with NGINX but not for any particularly good reason other than “it works”.

NGINX has a variety of flavours that sit at other points in an application, as part of its paid NGINX+ product suite. You can deploy NGINX+ as a per-app layer-7 load-balancer, as a per-app web application firewall, as an API gateway, as an ingress controller, or as a service mesh.

This is partly down to the broad success of web applications using REST APIs and similar methods. This web-API approach has taken over as the main way to design new applications, and older applications are adapted to use them, which provides a broad set of use-cases for NGINX to be useful. As new front-end protocols like QUIC or HTTP3 are added to the ways applications communicate, NGINX adds them to its capabilities to stay relevant. It’s been working well so far.

Of course, doing a lot of this creates new problems: how do you manage this collection of varied components, particularly when you have a lot of them? NGINX is mostly concerned with routing traffic around your application data plane. NGINX has added an NGINX Controller and NGINX Instance Manager to help automate and manage a fleet of NGINX deployments.

NGINX says its management tools are ‘opinionated’ which generally means the company has identified ways customers use their products that tend to work better than others, and so these become the sensible defaults that the product wants you to use. After getting purchased by F5 in 2019, NGINX is also keen for you to use F5 products alongside the NGINX+ suite to provide network security.

The way NGINX has developed mirrors the broader industry approach to things: REST APIs proved to be good enough at a broad range of things—and superior enough to alternatives—that they became widely used. But they have their problems, not least security which has been an afterthought for large swathes of the IT industry for far too long. Layering on solutions to these problems creates new problems, and complexity is the largest one I see.

NGINX is in a great position to capture a large portion of the market here if it can figure out how to provide good enough management of this complexity.

NGINX has a lot of pieces of the puzzle, and if it can progress the integration with the F5 suite of software, it will have even more. A solid orchestration and management mechanism that deals with the most common challenges with good, sensible, and above all easy-to-use features could make the whole NGINX suite the fastest and easiest way to get to good enough for a lot of customers.

With all the focus on security these days, just getting a reputation as the easiest way to quickly get a reasonably-secure modern app stack stood up could be the key to market dominance. The bar for security is set so low, and the challenge so tricky, that there’s a lot of value in just doing a pretty decent job for most people out of the box. There’s no need to be the best because no one really know what best best even means in this complex, confusing, and fast moving area. In fact, inter-operating with all the well-known and well-respected brands for all the different parts of the stack could be a great way for NGINX to become the de-facto standard for the glue that holds modern apps together.

NGINX was successful early on because Apache became too complex and difficult to use. NGINX, by comparison, was simpler and faster. It was the nimble startup to the lumbering enterprise behemoth that Apache had become, and NGINX must now guard against falling victim to the same fate.

Every large and successful company faces this challenge. We’ll just have to wait and see if NGINX can find a way to balance the load.