Web Server Load Balancing with NGINX Plus

Title slide for webinar of 7 April 2016, 'Connecting Your Applications with Docker and NGINX' about NGINX microservices and load balancing

This post is adapted from a webinar hosted on April 7, 2016 by Floyd Smith and Michael Hausenblas. This blog post is the first of two parts, and is focused on microservices; the second part focuses on immutable infrastructure. You can also watch a recording of the webinar.

Table of Contents

0:00 Introduction
1:48 The Way it Was
3:02 The Monolithic Architecture
3:43 Microservices Benefits
4:40 The Microservices Architecture
4:50 NGINX Plus with Monoliths
6:37 Microservices Architecture Continued
6:55 NGINX Plus and Microservices
7:56 Microservices Architecture with NGINX Plus
  Part 2

0:00 Introduction

Photos of presenters: Floyd Smith from NGINX and Michael Hausenblas of Mesosphere

Floyd: Good morning, good afternoon, and good evening to everybody signed onto this webinar around the world. I’m Floyd Smith from NGINX, and I’m here in San Francisco with Michael Hausenblas, a technical expert at Mesosphere and author of a recent book, Docker Networking and Service Discovery.

I’m going to start by talking about NGINX. We’ll be going over Docker, and then we’re going to go into some of the things that come up when you start using Docker at a production level and how container management and immutable infrastructure work together to help you manage complexity, and also create the freedom and opportunity for your apps to do really cool things.

1:48 The Way It Was

Slide reads 'The way it was...and often still is'

Let’s start with monolithic architecture. We’d love to hear in the comments if you’re running a monolithic application, if you’re moving to microservices, or already on microservices. We recently did a user survey on application development and delivery here at NGINX and we found a real mix, but probably most of what’s out there now is still monolithic, with some of it actively moving toward microservices.

Implications of the monolithic architecture: you must scale the entire monolith; all parts must be written with the same language and framework; to change one service, you must rebuild, retest, redeploy entire monolith

The major problem that comes up with monolithic architecture is scaling everything.

Since everything’s written in the same language, using the same frameworks, no language ever dies – because there’s a monolith written in that language somewhere and it’s got to be maintained.

Changing one service means rebuilding, retesting, and redeploying the whole monolith. And if there are multiple teams making multiple changes at the same time, you have a combinatorial explosion of possible bugs and a combinatorial explosion of possible communication and coordination problems among your teams. The classic book, The Mythical Man&#8209Month, talks all about this.

Finally, release cycles tend to be long and a lot of that time is spent talking to one another rather than coding, as we’re all familiar with.

3:02 The Monolithic Architecture

Diagram showing the unitary nature of a monolith, with all services combined in one build, written in one language and framework

Here you can see a monolithic architecture, and everything’s unitary. If you need to scale your monolith, you need to run multiple copies of the monolith, and you need to get those to coordinate with each other. Or otherwise they could each maintain state and run their own users, but neither of these options is really optimal, and they don’t give you the flexibility you want.

A common architecture when migrating to microservices is to have NGINX load balance instances of a monolith

A lot of you are no doubt doing this right now and NGINX is a great tool for helping you execute it, but NGINX is also great for pivoting towards the new architecture.

3:43 Microservices Benefits

Implications of a microservices architecture include: enabling continuous delivery and rapid deployment; independent scaling, build, testing of each microservice; each microservice written in the best language for it; shorter release cycles

A microservices architecture gives you continuous delivery, rapid deployment, elasticity, and I would add, flexibility. Each service can scale and be updated independently.

You can use different languages and different frameworks. My favorite example for that is with databases. You may need very different databases for different purposes within an overall app, and it’s great to have the flexibility to use them as needed on a services level.

Each service can be changed, tested, and built independently, and this is where Docker really comes in.

Release cycles can be dramatically shortened, so people are deploying many, many times a day, instead of once every several weeks or months.

4:40 The Microservices Architecture

Diagram of the microservices architecture showing clients interacting with an aggregation layer that talks to the microservices

So here’s the microservices architecture, and you can see the pieces of the services talking to each other.

4:50 NGINX Plus with Monoliths

NGINX Plus can cache static and dynamic content; adds flexibility to a monolithic architecture; acts as an HTTP router and load balancer

NGINX and NGINX Plus have a lot of capabilities that are great for your existing monolithic application, but also really set you up to pivot to the microservices world. At the end of Part II we’ll be presenting some resources that can help you gradually make the transition. So, if you need more detail, there’s plenty of places to follow up.

NGINX and NGINX Plus offer you caching of static content and also microcaching of dynamic content. It makes your monolithic architecture more flexible and it helps you do load balancing across multiple instances of your monolith.

NGINX, and especially NGINX Plus, can act as an HTTP router. NGINX inspects requests and decides how to satisfy each one. So, for instance with static file caching, the app server never sees that request. It gets handled at a higher level and the app server doesn’t even have to wake up for that to get handled. But also, if you’re running SSL [and/or] HTTP/2, all of that can get decoded at the load balancer/reverse proxy server level. Not bothering your app server, simplifying your app architecture, and a step in the direction of microservices.

NGINX and NGINX Plus provide many functions including load balancing, application acceleration, SSL and HTTP/2 termination, bandwidth management, content-based routing, request manipulation, response rewriting, authentication, web serving, video delivery, mail proxy, and geolocation

Here are some of the features of NGINX, and you can see if any of the things that you’re needing to do right now or in the near future are listed. If so, that’s a great entry point for your project.

6:37 Microservices Architecture Continued

Diagram showing how in a microservices architecture, each microservice can be scaled independently and is the unit of scaling

With microservices, everything’s independent. You can scale everything separately. You can update, test, debug, fix things as you need them. So, you can make a same‑day change if there’s a problem in a service, which is incredible and entirely necessary for many apps today.

6:55 NGINX Plus and Microservices

NGINX Plus easily integrates into a microservices environment using containers and DevOps tools, can run inside or outside the environment as a load balancer, and provides a single, stable entry point as containers are deployed and destroyed

NGINX and NGINX Plus help you step up, so you can easily integrate your app with container environments and devops tools.

You can run NGINX Plus in front of your microservices environment. You can run it as an API gateway to your microservices environment. You can run it per microservice.

We’re working on a reference architecture that we’re very excited about which integrates both DCOS and NGINX together in a really exciting way. We’re thrilled about this piece of the future that we’re seeing, and you will be too as we roll it out.

NGINX Plus gives you a stable, single entry point, and containers are just appearing and disappearing behind it. It looks like chaos at first, but it’s actually kind of lovely.

7:56 Microservices Architecture with NGINX Plus

Diagram showing NGINX Plus deployed in front of each component in a microservices architecture

Here’s an example architecture with NGINX Plus in front, at the aggregation level, handling communications with the end user and then handling communications back into your probably cloud‑based microservices architecture.

This blog post is the first of two parts on connecting your applications with Docker and NGINX, and is focused on microservices. The blog post based on the second part of the talk, focused on immutable infrastructure, is coming soon.

You can watch a replay of the webinar these posts are based on here.

If you are new to microservices, we recommend reading Introduction to Microservices by Chris Richardson, and continuing on through his complete, seven‑part series on microservices.

Hero image

Learn how to deploy, configure, manage, secure, and monitor your Kubernetes Ingress controller with NGINX to deliver apps and APIs on-premises and in the cloud.

About The Author

Floyd Smith

Director of Content Marketing

Floyd Earl Smith has been involved in application development since the launch of the Macintosh and has written more than 20 books on hardware and software topics. He now writes for the NGINX blog, including contributing to blog posts and webinars about the NGINX Microservices Reference Architecture, a breakthrough microservices framework.

About F5 NGINX

F5, Inc. is the company behind NGINX, the popular open source project. We offer a suite of technologies for developing and delivering modern applications. Together with F5, our combined solution bridges the gap between NetOps and DevOps, with multi-cloud application services that span from code to customer.

Learn more at or join the conversation by following @nginx on Twitter.