NGINX Unit Cookbook

Chapter 1. Unit Introduction and Features

This chapter will introduce you to NGINX Unit in a traditional book format before switching to the O’Reilly Cookbook format in Chapter 2. Throughout this chapter, you will learn about what makes Unit different from other middleware application servers. Before learning the how, you’ll learn the why, with a brief history of the problem Unit aims to solve. From that understanding, the architecture of NGINX Unit will be introduced, followed by the language support, and finally the API that drives the configuration.

1.1 Application Landscape and Unit Project History

The landscape of web applications has changed. In the past, applications were written from the ground up to serve specific needs, and upgrades were seldom issued compared to the present day. Today, applications are released frequently, in a piecemeal fashion, and portions are completely rewritten over time. As teams and web application offerings grow, the likelihood of the logic being diverse in both language and code base grows as well.

As web applications diversify through microservices, languages, and language versions, so does the operational complexity of managing middleware, where middleware is defined as the application server that receives requests and ushers them to the application code. Installing, configuring, tuning, and maintaining multiple types of middleware servers for different types of application languages and versions requires a lot of work, expertise, and time and affects the bottom line.

This solution, NGINX Unit, aims to reduce operational complexity by providing a single middleware server that is able to run multiple applications of different languages and versions and update on the fly without dropping a connection.

1.2 Dynamic Web Application Server

NGINX Unit is a dynamic web application server, which means that it can be dynamically reconfigured during runtime without dropping requests. The architecture of Unit is such that request handling is broken into layers. These layers comprise a controller process, a router process, and some application processes.

Each application served by Unit is run by an isolated process or set of processes. The router process receives incoming connections and asynchronously queues them for the destined application. The controller process manages the configuration of the application and router processes. The administrator, or operational automation, interacts with the controller process through an application programming interface (API). The controller process is able to reconfigure the router process and the application processes on the fly.

1.3 Polyglotism

Polyglotism is the ability to speak multiple languages. Prior to NGINX Unit, a few polyglot middleware services have served the web well—for example, the Common Gateway Interface (CGI) supports languages such as PHP, Perl, and Python; the Web Server Gateway Interface (WSGI) supports Perl, Python, and Ruby. Unit provides a single middleware server to run both compiled and scripting languages—including the aforementioned languages as well as Node.js, Go, and JSP—through a unified configuration.

With NGINX Unit, teams are able to code in the application language that makes the most sense for the service they’re providing to the end user. This technology reduces the difficulty of running complex systems to enable business value from all aspects.

1.4 API-Driven Configuration and Server Management

The NGINX Unit controller process is advertised through an API. The API can be configured to be served through a Unix or TCP socket. These two options allow the API to be tightly controlled but also enable remote configuration. This API follows RESTful paths, methods, and JSON bodies, per industry standard.

The controller process is able to start and stop application processes and to reconfigure only necessary portions of the router process’s memory. This ability to start applications and configure traffic routing accordingly is the core of the dynamic reconfiguration. These paradigms enable native integration with operational workflows found in DevOpsian organizations.

1.5 Conclusion

NGINX Unit has a unique place in system architectures, as it’s able to consolidate the number of different middleware server types needed to run a polyglot system. When system engineering teams are able to standardize, they become much more efficient. Teams that are going through migrations or technology transformations and need to write configuration management for a number of different web application middleware servers should consider using NGINX Unit.

Unit is an excellent choice for applications stuck in traditional data centers. Its API and dynamic nature provide an overlay on static infrastructure that enables software and DevOps teams to drive change from the application layer. Cloud deployments also benefit from Unit, as the industry-standard API fits directly into the ecosystem, and its lightweight resource footprint and functionality diversity allow teams to get the most out of their provisioned infrastructure.

Unit is built for serving web requests. An example of when Unit would not be a good fit would be running asynchronous worker applications that feed off of a queue or message bus.

The rest of this book is written in O’Reilly’s Cookbook format. The Cookbook format follows the cadence of problem statement, solution, and discussion.