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. 2018-05-17 / Vienna

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

About the speaker Nick Shadrin Sr. Product Manager with NGINX Based in San Francisco >15 years experience with web tech nick@nginx.com / @shadrin

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

Application Landscape 1/ Application Landscape

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.

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.

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.

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.

2/ NGINX Unit

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

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

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

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.

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.

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.

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.

3/ Unit Architecture

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.

"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" }

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

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.

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.

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.

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.

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.

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

Where to get Unit: Where to get help: unit.nginx.org github.com/nginx/unit docker run nginx/unit Where to get help: unit@nginx.org 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. nick@nginx.com