Introduction

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.

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 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.

The team at NGINX Inc. has observed this change in the application landscape and has worked to develop a solution from scratch, one that is built for the new age of computing. 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 to update on the fly without dropping a connection.

Dynamic Application Server

NGINX Unit is a dynamic 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 control 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 control process manages the configuration of the application and routing processes. The administrator, or operational automation, interacts with the control process through an application programming interface (API). The control process is able to reconfigure routing and application processes on the fly.

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 Java—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.

API-Driven Configuration and Server Management

The NGINX Unit control 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, as per industry standard.

The control process is able to start and stop application processes and to reconfigure only necessary portions of the routing 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.