Web Server Load Balancing with NGINX Plus

Most of the talk we hear about new architectures for application environments focuses on breaking monolithic applications into smaller, discrete services that make up a distributed application – an approach often referred to as microservices. A parallel architectural shift is underway, and while it’s not enjoying the same hype as microservices, I predict it will be just as significant. I’m referring to the collapse of the tiers that handle ingress and egress traffic for applications into a single, cloud‑agnostic software layer.

As my colleague, Owen Garrett, discussed in a recent blog post, typical ingress‑egress traffic pipelines are complex. It’s not uncommon to see five separate tiers  – one each for reverse proxy, web application firewall (WAF), web cache, API gateway, and load balancer – frontending an enterprise’s mission‑critical applications. And that might not be all! At a recent meeting I had in London, a large gaming company lamented, “I wish our architecture were that simple.”

Typical application pipeline with complex chain of tiers

The problem with this typical approach is that traffic has to hop through numerous functional tiers before it finally reaches the applications that actually generate the result the user is requesting. Each tier represents a possible point of failure and brings with it expense, management overhead, and – most importantly – latency. Even if you’re a fan of using discrete service components in your application delivery stack, it’s often not worth the performance penalty.

Many of our customers have told us they’re implementing a better approach: one that preserves the functionality of the ingress‑egress tiers, but in a simplified architecture with fewer hops and less overhead. We call it a dynamic application gateway.

Using NGINX to Architect A Dynamic Application Gateway

The NGINX Application Platform is a suite of application development and delivery technologies designed to help with both application frontend and backend architectures. Recent enhancements in NGINX Plus R16 introduced a new paradigm for ingress‑egress traffic where there is a single frontend tier that combines the functions of authentication, firewall, caching, and load balancing. And with clustering capabilities you can scale out this tier in a dynamic manner, which enables maximum performance and utilization. The reduction in hops improves performance dramatically, removes the multiple points of failure, and eliminates the costs of supporting tools from multiple vendors.

NGINX Plus simplifies the app delivery pipeline with a single, dynamic application frontend

What Is a Dynamic Application Gateway?

If you were at NGINX Conf 2018 you heard about the concept of a dynamic application gateway. But let’s set context and provide a simple definition:

A dynamic application gateway combines application delivery technologies – including proxying, SSL termination, WAF, caching, API gateway, and load balancing – into a single, dynamic tier for north‑south traffic in and out of any application and across any cloud.

This means a dynamic application gateway:

  • Acts as an intelligent control point for optimizing traffic delivery for apps and APIs
  • Shares a single configuration and key‑value store across a tier of multiple instances acting as one distributed, elastic gateway
  • Combines app delivery controller (ADC), API gateway, and WAF functionality
  • Handles all north‑south traffic flowing in and out of your apps
  • Is implemented by infrastructure teams, but designed for app and DevOps needs
  • Differs from:
    • Existing software load balancers because it integrates API gateway functionality
    • Existing API gateway solutions because it integrates load balancing and WAF

Five Reasons You Need a Dynamic Application Gateway

What’s inspired this new approach to delivering applications? Five things:

  1. Shifting of infrastructure closer to apps – Thanks to Infrastructure as Code, app and DevOps teams can provision (and often program) their own infrastructure. Now application teams can shift ingress‑egress functions into the developer’s application stack.
  2. Changing user requirements – Customers expect their websites and mobile apps to just work. Yet, businesses – particularly retailers – face fluctuating traffic. Dynamically scaling ingress‑egress functions guarantees a consistent, compelling user experience.
  3. Evolving cloud capabilities – Public clouds require a different approach to handling ingress‑egress traffic. You can’t take your hardware with you to the cloud. Also, elastic computing resources in the cloud make it possible to scale based on fluctuating traffic.
  4. Maturing software‑defined networks – Software‑defined networking has focused on the routing and switching layers. But in the cloud these functions are mostly abstracted. Now, the focal point is Layer 4–7 networking software with fine‑grained traffic control.
  5. Emerging security threats – New attack vectors like DDoS require more “cushion” on the frontend. Web app firewalls have evolved to detect threats, but mitigation needs to occur dynamically at the ingress‑egress tier to respond to the ever‑changing threatscape.

Given all these trends, now is the time to review the architecture for your ingress‑egress traffic pipeline. Building a dynamic application gateway that combines delivery technologies like proxying, WAF, caching, API gateway, and load balancing ensures you can respond to changing needs, simplify your architecture, and pave a path to more dynamic backend application architectures like microservices.

Get started with a free 30-day trial of NGINX Plus today or contact us to discuss your use cases. The trial experience combines NGINX Plus with the NGINX WAF to provide a single, dynamic application ingress‑egress solution.

Hero image
将 NGINX 部署为 API 网关

这本免费电子书更新于 2022 年,您将通过这本书了解到如何将 NGINX 部署为 API 网关


Headshot Gus Robertson CEO NGINX

Gus Robertson

Senior Vice President and General Manager of NGINX

Gus Robertson is Senior Vice President and General Manager of NGINX at F5.

Previously, he served as CEO of NGINX, Inc., which was acquired by F5 in 2019. Robertson joined NGINX as CEO in 2012 when the company had no commercial offerings or revenue and a staff of 8. Over the next 6 years, he grew NGINX to more than 250 employees and raised over $100 million in venture capital from such investors as Goldman Sachs and NEA.

Prior to joining NGINX, he worked at Red Hat for 10 years, first as Vice President of the Asia Pacific region and then leading Global Business Development from the US. Before joining Red Hat, Robertson ran the Asia Pacific region for Visio, prior to its acquisition by Microsoft in 2000.

Robertson studied Marketing at Charles Sturt University in Australia and completed the Advanced Management Program at Duke University’s Fuqua School of Business.


F5, Inc. 是备受欢迎的开源软件 NGINX 背后的商业公司。我们为现代应用的开发和交付提供一整套技术。我们的联合解决方案弥合了 NetOps 和 DevOps 之间的横沟,提供从代码到用户的多云应用服务。访问 了解更多相关信息。