Technology

NGINX Plus Moves to a Plug-in Model for Third Party Extensions

12 Apr 2016 11:14am, by

With the newly launched Release 9,  NGINX Plus, the commercial version of the open source NGINX Web server software, is moving to a plug-in system, where extended functionality — for instance, programming languages, including Lua, JavaScript, and Clojure — can be attached on demand.

“We are creating a repository of modules that we have tested, that we certify to work correctly inside NGINX Plus,” said Owen Garrett, NGINX Inc.’s head of products, “and we’ll maintain that repository going forwards.  That means, anyone who takes our supported product will then be able to rely on a repository of third-party extensions that we’ve tested, and we will provide best-effort support for as well.”

Organic Growth vs. Grafting

Up until now, the company’s preferred method for supplying customers with add-ons was by creating pre-configured bundles, with a half-dozen selected items and NGINX pre-compiled with those bundles attached, for what the company called “NGINX Plus Extras.” Web application firewalls are among the most common add-ons currently welded, if you will, onto NGINX Plus up.

“But it became unsustainable,” the product chief admitted. “If you tried to compile too many modules in, there was a risk that the binary would become too big and potentially unstable because they weren’t always designed to work together.”

This new approach gives users the option to pick and choose the modules that they want to include.

With extensions now being treated as extensions, Garrett told us, his company is now in the position of opening up its repository to support commercial extensions, hopefully within the next few months. If that works out, NGINX can finally go beyond “platform” and start referring to a legitimate “ecosystem.”

“If there’s customer demand, or if there’s an opportunity to work with a partner to help promote their solutions, then we can very easily add their module into our repository, and users will be able to pick and choose which modules they use,” Garrett said.

Does this mean that updates to support modules can be implemented in the NGINX repository immediately? Almost, responded Garrett. NGINX will be using a repo system, very similar to Ubuntu’s Apt or Red Hat’s Yum, he told us. Whenever NGINX receives an update to a module, it will rebuild the entire module, and offer the product as an upgrade through the repository. Rather than a patch for an installed module, users will download the completely rebuilt module.

Bloat Avoidance

Garrett acknowledged there could be issues down the road with “bloated binaries” — NGINX nodes that become loaded with add-ons.  This should be less of an issue for service operators, he said, as organizations design their services around NGINX as a single point of contact, rather than multiple points, as well as by giving users the means to be judicious about their choices. With the “Extras” system up to now, there were probably already too many bloated deployments.

“We’re tightening down the APIs that people use, to make it much harder for modules to interfere with each other,” said Garrett, “so they run more securely and more reliably. We’re investing in a developer relations team; we’re building out documentation for the API, and are working with third-party and commercial module developers in order to help them port to the new dynamic module interface, and to understand the best ways to architect the modules that they’re building.”

By “tightening down,” Garrett clarified that the existing API documentation was pretty shabby, especially when it came to distinguishing internal API functions from public functions. For forthcoming documentation, he said, we should expect much greater consistency and clarity.

Now with UDP

Release 9 also now adds the capability to process UDP (User Datagram Protocol) traffic, in addition to TCP and HTTP.  UDP protocol is most predominantly used by the DNS service, as well as the NTP time protocol, and a growing number of Internet of Things devices that need lighter-weight protocols than those required by full-scale Web servers.

“The more protocols a load balancer can handle, the more effective it can be at being that [single] point of entry,” explained Garrett.  “That gives you operational efficiencies; it reduces your costs; it makes it easier to diagnose, do performance tuning, and apply security rules.  By adding UDP load balancing into NGINX and NGINX Plus, we help organizations consolidate their different load balancing layers.”

Feature Image: San Francisco, Scott M. Fulton III

A newsletter digest of the week’s most important stories & analyses.

View / Add Comments

Please stay on topic and be respectful of others. Review our Terms of Use.