NGINX Unit, Three Months In: Progress and Next Steps
Three months ago, we released the first beta version of NGINX Unit, a new dynamic server for web applications. See our initial description of Unit, the announcement blog post, the in-depth demo, and our Unit webinar.
The announcement of Unit became the top story on Hacker News. The code continues to receive attention on GitHub, and Unit’s features and architecture spawned numerous discussion threads on Facebook, Twitter, and other networks. We invite you to download Unit packages or compile it yourself, to try it, and to join the discussion.
To share our progress since the initial beta release, in this blog post, I’ll summarize the last three months of engineering work, then describe our plans for future features and for production readiness.
Vision
We at NGINX have known for many years how to connect to the application. Now, with Unit, we help you run it. Modern applications are frequently changing, and they consist of multiple parts. Various services that comprise a distributed application are written in different languages by separate teams. All parts of this mess have to work together for the benefit of end users.
Unit is designed with some key points about modern applications in mind:
Instances of web and app server: In most environments, we see the use of NGINX web server and reverse proxy in front of every application instance. Operations teams choose to implement a web server as an additional layer for consistency, security, and ease of configuration. Now, with Unit, the web server features will be tightly coupled with the application execution runtime. In addition to consistent operation, you’ll see improved performance of the application, with fewer moving parts.
Frequent changes: Today’s infrastructure gives you the ability to make changes easily. You can run cloud virtual machines, containers, and lightweight server workloads, and scale them independently and frequently. Unit has a fresh architecture, it doesn’t reload on changes, and it gives you an easy, dynamic operation model for the application infrastructure. It provides you with the ability to make changes in architecture and in running code as frequently as you need to. All changes are performed without loss of connection or interruption in service.
Multiple stacks: Many application languages and infrastructure stacks create complexity and inconsistency in the operation of a large application. With the ability of Unit to run many application stacks and application versions at the same time, you get operational consistency, stability, and performance across the range of supported languages and language versions. In addition, Unit isolates applications from one another, providing an aspect of security that every production deployment needs.
Service-to-service connectivity: Distributed applications, including microservices applications, inevitably require reliable connectivity across their infrastructure. NGINX has a lot of experience in connecting users to applications, and services to services, within large, distributed environments. One of our goals for future releases is to build the service-to-service proxy features into Unit in order to simplify the operation of your service mesh.
Architectural Approach
Unit is new software, built from scratch. We didn’t reuse any major part of the existing architecture of NGINX while designing and developing Unit.
In Unit, we decided not to have configuration code compatibility with NGINX for the following reasons:
- When NGINX was originally designed, 15 years ago, many features of today’s systems were not available, or were not stable enough for widespread deployment. Examples include threads and cgroups. We can utilize them now in the core of Unit.
- Placing Unit as the server for backend operation in distributed applications focuses on features that are different from a front-end web server and reverse proxy, such as NGINX.
- Creating a new code base allows us to focus more strongly on the performance and security of your application. Now we treat application code as an essential part of the web operation, and not as a black box behind a reverse proxy.
- With this fresh start, we were able to design Unit so it can be configured and reconfigure “live,” during runtime, with no separate configuration file. So if we wanted to achieve configuration code compatibility with NGINX, we would have had to add an otherwise unneeded configuration file, and much other scaffolding, to Unit, complicating the software.
However, although they’re distinct, Unit and NGINX are parts of the same application platform, and you can use them together, playing different roles within your application environment.
Unit Source Code
Unit is free. The source code is available at http://hg.nginx.org/unit and https://github.com/nginx/unit. It’s open, available under the Apache 2.0 license. You can compile Unit yourself on most popular Linux and Unix systems.
The code repository gives you the most recent view on the progress of the software and provides you with the latest features and updates. However, you should expect frequent changes if you choose to use the latest source for your project. In addition to the raw code, we regularly make versioned packages for most popular operating systems.
Here’s a quick overview of the last three months of development.
Three-month Development Recap
Unit 0.1
The initial beta version of Unit was released on September 7th, 2017, at our annual event, nginx.conf 2017. With the 0.1 version, you can:
- Dynamically configure any of the listener and application parameters with the RESTful API.
- Launch apps in Python and PHP without modifying the code.
- Build and run Go apps using the Unit package.
- Securely isolate the apps with Unix users and groups.
- Save and restore configuration.
Unit 0.1 was intended for initial experimentation, and our most active members of the community took advantage of that. We send thanks to everyone who tried Unit early on and posted questions, bug reports, feature requests, and code modifications in our GitHub repository.
Our initial users tried running Unit with various applications and frameworks, including WordPress, Django, and Grafana, using PHP 5 and PHP 7, Python 2 and Python 3, and Go. It became possible to take existing legacy apps, start them, and configure them in real time.
Watch the in-depth demo of Unit 0.1, featuring system configuration, startup, application loading, and real-time reconfiguration.
Unit 0.2
Version 0.2 was released on October 20, 2017. This second beta version added a number of new features and bug fixes:
- Configuration persistence. Starting with version 0.2, Unit is able to save the configuration state and restore it in case of a service restart or a server reboot. (The configuration state file should not be the place where you perform changes. Instead, make a change directly to the unit API, and it will save the current system state to the file system.)
- Improved error messages. Unit can now display the full text details of an error in case of a misconfiguration via API. In addition to the text, Unit now can display the location of the error in the original request.
- Application timeouts. Every application can now be configured with a specific timeout setting, which ensures that application workers will be restarted in case of an unexpected delay in application execution.
- New repository for documentation. The new repository is available at https://hg.nginx.org/unit-docs/ and https://github.com/nginx/unit-docs.
- New scripts. There’s a new set of packaging scripts for package maintainers.
- Bug fixes. Various bug fixes to address application crashes, a memory leak, router crashes, and abnormal request handling.
Watch the on-demand webinar for unit 0.2 here.
Unit 0.3
The Unit 0.3 beta is scheduled for release in the middle of December. The major changes and new features will include:
- Improvements in HTTP handling.
- Improvements in the Go package.
- The addition of Python Virtual Environments.
- Code refactoring and bug fixes.
Roadmap
We want you to know our plans. It’s an open project, and we share our roadmaps early. Here’s what’s coming in the upcoming release, scheduled to appear in the beginning of 2018:
- Full HTTP/1.1 support
- SSL/TLS support
- First stage of application process management features: prefork model, memory management, CPU management, timeouts, etc.
- Improvements in error reporting and logging
In the second quarter of 2018 we will fork Unit code into two branches:
- Still branch will be recommended for production use. The still branch will have infrequent feature updates, while maintaining security fixes and bug fixes for extended periods of time. We’ll ensure consistent API operation within versions of the still branch.
- Fresh branch will contain actively developed code. New features will be implemented first in the fresh branch. We’ll encourage the use of fresh branch for projects that require new functionality on a frequent basis.
We’ll release new packages from the fresh branch every few weeks. These packages will be available for the most popular operating systems, and all installation instructions will be posted at unit.nginx.org.
This versioning system will allow us to focus on the development of new functionality while maintaining high quality code in both branches. This is similar to the versioning used by NGINX.
Later in 2018, we will continue development in the following areas:
- New languages: Unit will add the ability to run additional languages, potentially including JavaScript/Node.js, Java, .NET Core, and Ruby.
- Service-to-service communication: proxying HTTP, load balancing, and service discovery.
- Support for additional protocols: HTTP/2, proxying TCP.
Join the development effort on GitHub, contribute to the documentation, and send us feedback about your experiences.
If you wish to make unit a part of your career and your full-time job, join our team: NGINX is hiring C/Unix developers. Check out this page for details: https://www.nginx.com/jobs/
The post NGINX Unit, Three Months In: Progress and Next Steps appeared first on NGINX.
Source: NGINX Unit, Three Months In: Progress and Next Steps
