中文
As personal computers became ubiquitous in the early 1990s, there was a growing appetite to consume applications. At the time, it took on average three years to develop an app from initial conception to deployment in production. This has changed dramatically – Amazon deploys a new or updated application every 11.7 seconds and Nordstrom, a 120-year-old American luxury retailer, has increased its deployment frequency from twice per year to monthly.
Bringing apps to market faster enables enterprises to stay ahead of the competition, achieve scale quickly, and increase revenues through digital channels. Developers take center stage in this new world but they are under pressure to develop and deploy new apps at a frightening velocity. That, in turn, puts pressure on infrastructure and operations (I&O) teams to provide a flexible, multi‑language environment in support of developer productivity.
NGINX plays a crucial role in delivering blazingly fast apps. Well known as a web server, reverse proxy, software load balancer, API gateway, and content cache, NGINX Open Source and NGINX Plus have a pervasive footprint and widespread adoption among application developers and DevOps teams. A more recent addition to the NGINX Application Platform is NGINX Unit, a dynamic application server (which for brevity we’ll refer to simply as an app server).
You might be wondering: don’t we already have enough app servers? Why introduce another one?
App Servers – Keeping the Lights on for Your Apps
First, let’s look at what an app server is. An app server’s fundamental job is to provide clients with access to what is commonly called business logic, which is the code that dynamically generates responses to client requests, transforming data to provide the specialized functionality offered by a business, service, or application. App servers sit between clients and the backend tier to handle transaction processing, resource/connection pooling, load balancing, and redundancy. They free the application developer to focus on just the business logic.
App servers provide the framework for creating apps as well as running them. Just as load balancers are key to I&O and DevOps teams, app servers are key to developers.
Frequent Changes to App Server Config Changes Lead to Downtime and High Operational Costs
Developers often need to change the configuration of app servers to scale or support new app functionality. App servers have to interact with various components and aspects of the backend, such as databases, networking functions, and applications written in different languages or different versions of the same language. For instance, multiple versions of an app may need to be supported because the app itself is using different versions of PHP or Python. App servers also must support multiple deployment environments, such as VMs and containers.
Given the complexity of the functionality an app server provides and the ecosystem it runs in, changes to its configuration usually require a restart. That implies app downtime, which must be either carefully planned or avoided through complicated networking – leading to service disruption and operational complexity! Restarts are especially painful when the configuration change is for just one of the multiple applications run by your app server, but the restart affects all of them. It’s enough to make you hesitate about updates. Your feature velocity takes a hit, and so does developer morale. Your app server becomes the bottleneck to innovation and speedy time to market.
Different App Servers for Different Languages Explode Infrastructure Complexity
As enterprises adopt a more agile, flexible approach to app development, developers are often empowered to pick the language that best suits the functional needs of their application. That boosts their productivity and morale. According to a report from the Cloud Foundry Foundation, an open source Platform-as-a-service project, a “multilingual strategy improves business velocity; enables flexibility, portability, and interoperability; and attracts the best developers”.
While you definitely want to provide freedom of choice to your developers, supporting many languages carries an operational burden. The Cloud Foundry Foundation report lists more than 20 languages used in enterprise development, 6 of them heavily: Java, JavaScript, C++, C#, Python, and PHP. Traditional app servers support only one language (or even a single version of a language), so every language you use means another app server for your I&O team to install, configure, and maintain, not to mention dealing with its idiosyncrasies as it runs in production. That can add up to a significant drain on resources. You also must maintain separate hosts for each language used in your enterprise – a direct hit to both capex and opex.
Traditional App Servers Are Not Designed for Modern, Microservices‑Based Apps
The microservices approach to software architecture builds a large, complex application from multiple small components that each perform a single function, such as authentication or notification. With this approach, apps can scale easily because each microservice is elastic and resilient – if one microservice instance fails, the others will continue to function. Microservices‑based applications are lightweight, flexible, portable, and typically deployed on containers.
Enterprises are increasingly modernizing their apps using microservices. According to the Global Microservices Trend report by LightStep, a startup that provides application performance management for microservices, 86% of enterprises expect microservices to be their default architecture within 5 years. Microservices themselves are lightweight, flexible and portable – they are typically deployed on containers.
Traditional app servers were designed for three‑tier monolithic applications consisting of a presentation tier, a data tier, and an application tier which contains the business logic. Like the applications they serve, legacy app servers have a large footprint that makes them unsuited for microservices environments, where light weight and portability are key. With traditional app servers, it’s difficult to spin up new instances quickly on a container or across multiple clouds. And a restart due to a config change usually takes a long time – in some cases longer than the operational duration (runtime) of a microservice – which defeats the purpose of microservices.
How Does NGINX Unit Address These Challenges?
We developed NGINX Unit to address the mismatch between traditional app servers and modern application environments. NGINX Unit is an open source dynamic application server, suitable for both stand‑alone applications and distributed, microservices application architectures.
Dynamic API for Consistent, Zero‑Downtime Configuration
NGINX Unit provides a RESTful API interface that simplifies configuration. The interface provides a consistent mechanism for applying configuration changes to different types of applications written in different languages. All updates are made in a seamless fashion without causing any downtime. I&O teams do not have to plan any downtime – saving them time and effort – and your customers don’t need to suffer any service disruptions. Performing config updates using APIs has the added benefit of allowing DevOps to automate this process using config management tools and to integrate easily with existing CI/CD pipelines.
Polyglot Support for Reduced Operational Complexity
NGINX Unit dramatically reduces the burden of managing multiple app servers. It currently supports seven languages – Go, Node.js, Perl, PHP, Python, Ruby, and Java Servlet Containers (the last as an experimental module). You can run applications written in different languages on the same server. Furthermore, app versions written in different versions of a language (PHP 5 and PHP 7, Python 2.7 and Python 3) run side by side on the same server. That’s right – you don’t have to maintain different app servers for different languages and versions, or run them on separate hosts.You save on hardware costs, as well as the associated costs of managing, maintaining, securing all those servers. Your I&O team now has the time to focus on value‑generating IT initiatives instead of mundane, day-to-day operations.
Lightweight, Flexible Architecture for Optimized Microservices Support
NGINX Unit is a software package that can be deployed anywhere – bare‑metal, VMs, containers, public clouds, and private clouds. Developed by the same team that created NGINX Open Source and NGINX Plus, NGINX Unit also has the same ‘core values’ as NGINX. NGINX Unit is lightweight: less than 1 MB in size. Memory and CPU utilization are very low. These traits make NGINX Unit ideal for modern apps based on microservices – which are themselves lightweight and typically run on containers – but are equally beneficial for monolithic apps running in traditional environments.
NGINX Unit is a Critical Component in a Platform that Spans from Code to Customer
NGINX has a very rich history of fulfilling the app delivery needs of the developer community – whether deployed as a load balancer, for API management, or in microservices‑based architectures. NGINX solutions are flexible, lightweight, and portable. NGINX integrates seamlessly into your application stack resulting in high performance and reliability. Staying true to our heritage of being intimately tied to application code, we have developed yet another central infrastructure component – an app server – which is usually the first infrastructure touchpoint for a developer. NGINX Unit fulfills the app server requirements for modern apps.
NGINX Unit is part of our broader vision where NGINX and F5 provide an end-to-end application infrastructure – one that spans from code to customer – to deliver apps across a multi‑cloud environment. To learn more, register for our webinar series that elaborates on how NGINX and F5 can solve your application delivery challenges.
