1. Why Build Another Application Server
Nick Shadrin
Sr. Product Manager, NGINX
NGINX Unit is a dynamic web and application server that can simultaneously run different apps written in different languages. It sits in the backend part of your infrastructure, it launches and runs your application code.
Unit was built from scratch by the same team that built NGINX. You should expect the same stability, usability, and performance from Unit as you do with NGINX.
Let's take a look at the reasons why we created it.
/ Vienna

2. About NGINX Open source web server since 2004
38% of all websites, 64% of top10k (w3techs)
Now >200 people, worldwide operations
We make software for web serving, load balancing, CDN, API gateways

3. About the speaker Nick Shadrin Sr. Product Manager with NGINX
Based in San Francisco
>15 years experience with web tech

4. Application landscape today Unit features Unit architecture Demo
Agenda
Application landscape today
Unit features
Unit architecture
Demo

5. Application Landscape1/
Application Landscape

6. Infrastructure is changing
Infrastructure today enables frequent changes
DevOps tools perform changes remotely
Uptime is critical
Applications today are deployed in new environments and infrastructures. These environments enable you to deliver new and updated applications constantly and immediately. Your containers, orchestration platforms, CI/CD (Continuous Integration / Continuous Delivery) pipelines, and software-defined networking require your apps to change as quickly as possible.
Modern management tools work remotely, updating, restarting, and reconfiguring different apps. These tools require a consistent interface to your applications to work well. More and more organizations use automation and management software.
Uptime is critical for applications. When you update your app, dropping the users when you restart is not permitted. Having blacked-out "maintenance windows" is the opposite of continuous delivery.

7. We use many languages Modern languages are designed for modern tasks
Legacy software has to coexist with the new apps
Different tasks require different stacks
We asked users which language they use in their applications. The answer is almost never "just one".
Most of our users and customers are using several languages and application stacks at the same time. There are reasons for that, which include:
Some languages are better for handling specific tasks; for instance, PHP is extremely easy for simple web pages, while Python is better for machine learning
Companies buy apps from, or merge with other organizations, and different stacks from the different organizations must now be supported
Sometimes, it's just fashion. Go is fashionable today, Perl is not, even where either may do a given job well.
Every time you add a language to your stack, you add new kinds of configuration files and new deployment software that you need to support.
Every new language and version makes the automation and management more complex.
Issues and bugs can be very hard to find.

8. Microservices trends New apps are more distributed
Legacy apps are modernized
Connectivity is more important
Any application framework or code can have security flaws. More application frameworks = more potential security vulnerabilities.
When many apps run on the same machine, you must have isolation between them. This is often resolved by the use of virtualization or containers.
Different apps require different restrictions. We don't want an unimportant app to take all the resources and keep a more important one from running.
Restrictions and security should be easy to manage.
When your app is more complex and distributed, providing full security and encryption between its services more significantly degrades performance, than in the case of a more simple or a monolithic app.

9. Security is now different
Applications tend to be isolated
Applications should be restricted
With complicated request flow, performance impact grows
Any application framework or code can have security flaws. More application frameworks = more potential security vulnerabilities.
When many apps run on the same machine, you must have isolation between them. This is often resolved by the use of virtualization or containers.
Different apps require different restrictions. We don't want an unimportant app to take all the resources and keep a more important one from running.
Restrictions and security should be easy to manage.
When your app is more complex and distributed, providing full security and encryption between its services more significantly degrades performance, than in the case of a more simple or a monolithic app.

10. 2/
NGINX Unit

11. A server built from scratch
Dynamic, multilingual server designed for modern apps
Same development culture as nginx
Focused on performance and optimization
Open source

12. Unit is dynamic by design
Unit applies changes instantly
Unit does not reload or restart
Does not use extra resources on changes
What do we mean by "dynamic"?
When operators want to make a change, with old servers they had to edit the config file, then reload the service.
Sometimes they added agents and sidecar software to assist with reloading.
A truly dynamic server, Unit, does it differently:
It accepts API calls by itself, not with the help of agents
It performs changes in memory
It does not reload the processes unless required

13. Unit is dynamic by design
Unit applies changes instantly
Unit does not reload or restart
Does not use extra resources on changes
Same slide, animation stopped.
What do we mean by "dynamic"?
When operators want to make a change, with old servers they had to edit the config file, then reload the service.
Sometimes they added agents and sidecar software to assist with reloading.
A truly dynamic server, Unit, does it differently:
It accepts API calls by itself, not with the help of agents
It performs changes in memory
It does not reload the processes unless required

14. Unit is API-controlled
Unit does not have a config file
You learn one easy REST interface
Standard JSON payload that you already know how to work with
Unit is configured via an API, so you don't need to edit a config file on the server.
This interface is called "REST API", and it's standards based. You send a JSON payload to the API, and Unit reconfigures itself without reloading.
Each call to start an app will use the same server software; Unit configures itself to launch the app correctly.

15. Unit is multilingual
Unit launches your code in: PHP, Python, Perl, Ruby, or Go
All apps have the same config approach
All apps can run on the same server
Unit can launch apps in many languages.
In addition, it can launch them with different versions of the same language.
This means, NO different stacks for operators and automation tools to manage.
Each app will start the same server software, and - depending on the API calls - it configures itself to have the required apps running correctly
No more learning five types of config files; just learn one API approach
You can have various versions of the app at the same time
- OR -
You can try different versions of a language,with the same apps.

16. Unit secures and isolates
Unit launches apps with different user credentials
Apps are now independent
Unit can secure your apps by using different Unix user credentials.
We will be adding support for Linux control groups, for even better app isolation, in future.
Your apps are not just independent, as they are still manageable. You now don't need various copies of the server software to run multiple apps.

17. Unit secures and isolates
Failure of one app does not kill others
The server is still uniformly configurable
Another aspect of isolation is the ability to better handle app failures.
When one app fails, others are not killed, nor restarted.
This provides the resiliency that any production environment needs.
And, you still have control and management interfaces available directly.

18. 3/
Unit Architecture

22. Unit API Methods: GET, PUT, DELETE{
"listeners": {
"*:8081": { "application": "myblog" } },
"applications": {
"myblog": {
"type": "php",
"processes": {
"max": 10,
"spare": 2
"root": "/srv/demo/php",
"user": "www-php",
"group": "www-php",
"index": "index.php",
"limits": {
"timeout": 10,
"requests": 100 }
Unit API
Methods: GET, PUT, DELETE
Unix socket by default, --control option for IP:port
Encrypt and authenticate with NGINX
Control with any tool you like. It's HTTP / JSON.

23. "phpapp": {
"processes": {
"max": 10,
"spare": 2 },
"user": "www-user",
"group": "www-user",
"limits": {
"timeout": 10,
"requests": 100
"type": "php",
"index": "index.php",
"root": "/srv/demo/php" }
"pyapp": {
"processes": {
"max": 10,
"spare": 2 },
"user": "www-user",
"group": "www-user",
"limits": {
"timeout": 10,
"requests": 100
"type": "python 3",
"module": "wsgi",
"path": "/py/venv/s",
"home": "/py/venv" }
"ruapp": {
"processes": {
"max": 10,
"spare": 2 },
"user": "www-user",
"group": "www-user",
"limits": {
"timeout": 10,
"requests": 100
"type": "ruby",
"script": "/srv/app.ru" }

25. Keep uptime on changes No downtime on infrastructure changes
No waste of resources
Fewer servers to run
This is provided by the dynamic nature of Unit
100% uptime is critical for many applications.
What unit gives you:
No service interruption, no connection loss, no request loss; true 100% uptime is achievable
Less software to manage (no agents)
Faster response to changes
No extra memory use on reloading

26. Easy automation APIs are easy to use
Scripts and controllers are native to APIs
Integrates with tools that you already know
You can install Unit in any kind of deployment, and use the tools you already know.
Every automation tool works great with APIs, and the Unit API is a standards based.
It's easy to learn one interface for all of your apps.

27. Simple upgrade/test Easy to try and deploy new apps
Make sure your application works correctly
Change between various languages and platforms, instantly
When your new application or new code is ready, try it without disrupting the network.
Make sure the application is working as designed, by running some traffic through it. Don't need to kill an old app, they both can run together.
Need to roll back? Instantly call an API and have the old applications ready to process traffic.

28. Consistency Same configuration API for all apps
Same HTTP operation for all apps
Same software in all deployments
Running the same HTTP processor is critical for consistent operation.
All apps now have the same kind of parameters; all apps now have the same interface for changes.
It's also great to have that consistent application layer regardless of the deployment: containers / VMs / hardware - anything.

29. Flexibility Deploy in hardware, in a VM, or in a container
Create modules only for your own language version
Configure locally or remotely
You can install Unit in hardware, in a VM, or container. On premise or in the cloud. It operates the same way.
You can download the prebuilt package. You can launch a container that we maintain. Or you can compile it from source.
You can take any of the language modules that we prepared, or build your own.
You can mix and match any of the supported languages and versions.
Overall, Unit gives you full flexibility to launch apps the ways you want.

30. Our plans (1/2) Hardening and maturity Scalability and security
Near term:
Hardening and maturity
Scalability and security
Grow the language support (Java, node.js)
Hardening and HTTP maturity:
improve the performance and resilience of HTTP processing
add SSL/TLS and HTTP/2
add static content serving
Scalability and security: additional control over the resources used by each application, how it scales in response to load, and isolation features for the apps
Growing language support: NGINX Unit currently supports Python, PHP, Go, Perl and Ruby. JavaScript (Node.js) and specific Java frameworks are in the research phase, and other languages may be added based on community demand.

31. Our plans (2/2) Service-to-service communication
Longer term:
Service-to-service communication
Troubleshooting and tracing
Instrumentation and monitoring
These are longer term roadmap topics, which are subject to change:
Proxying for Egress Application Traffic: the ability for NGINX Unit to manage egress (outgoing traffic), along with a discovery protocol to locate other NGINX Unit instances, will form the basis of a self-managing service mesh that will enable NGINX Unit instances to network together and act as sidecar proxies to service instances
Instrumentation and Monitoring: NGINX Unit will gain APIs and capabilities to monitor performance and trace application traffic through multiple services in a distributed application

32. Where to get Unit: Where to get help: unit.nginx.org
github.com/nginx/unit
docker run nginx/unit
Where to get help:
github.com/nginx/unit/issues
NGINX booth here, #1.141
Read the documentation on unit.nginx.org
Get the source code on GitHub
Run a Unit container; this takes one command
Ask questions on GitHub or subscribe to the mailing list
NGINX Plus users who own at least 4 instances with premium support levels get basic Unit installation and initial configuration support included as part of their subscription.