Cloud Field Day – NGINX

I will be a delegate for Cloud Field Day 5 on April 10-12. During the event we will be attending presentations from several vendors, which will be livestreamed. Before I leave on this grand adventure, I wanted to familiarize myself with each of the presenters and consider how their product/solution integrates with cloud computing. I’m also interested to hear from you about what questions you might have for each vendor, or topics you’d like me to bring up. As a delegate, I am meant to represent the larger IT community, so I want to know what you think! In this post I am going to consider NGINX and where it fits in the cloudy, cloudy world.

I am most familiar with NGINX as a product that I use for demos and examples instead of Apache. When I need to give an example of how to spin up a new server with Terraform or deploy code through a CI/CD pipeline with Azure DevOps, I am probably going to install NGINX and run a simple website. It’s a super easy to do, and very lightweight. But that is not how I think most of the world uses NGINX. Looking at their website they have several products:

  • NGINX Plus: Basically the open-source version of NGINX with additional features. It is meant to replace your hardware load balancers.
  • NGINX Controller: The controller component appears to be the centralized management plane for multiple NGINX Plus instances.
  • NGINX Unit: Unit is an application server that sits behind your NGINX Plus load balancer and helps run your application written in Python, Go, Ruby, etc.
  • NGINX WAF: WAF stands for Web Application Firewall
  • NGINX Amplify: The monitoring solution for NGINX Plus including application and OS layer

NGINX fits neatly into the world for application hosting and load balancing. All their other ancillary services appear to be expanding on that basic notion. If you have an application you want to run on the web, then NGINX can help you with the front end portion of that application. Most of what I read leads me to believe that NGINX is for more traditional style application deployment and management. You deploy a VM with an OS, install NGINX, and lay down your application. Then you join it to the NGINX Controller and monitor it with Amplify. That’s not exactly a unique proposition, but I appreciate that it removes the need for a physical load balancer.

On March 11th, NGINX announced that it was being purchased by F5. I’d heard that NGINX was shopping around for an acquisition prior to this announcement, so it wasn’t terribly surprising. It does raise some questions for me. F5 is very much a traditional load balancing company. The bulk of their portfolio is all about selling enterprise grade load balancers, and then keeping customers on the hook for software and support after the fact. The idea of big honking, hardware load balancers sitting in front of your applications doesn’t translate well for cloud native applications. The way in which applications are structured and presented is moving to micro-services with service discovery and service mesh. Purchasing NGINX is a way for F5 to modernize their portfolio and stay relevant for the next five years. With that perspective, I have some questions I’d like to ask NGINX at CFD 5.

  • What is the future of your open-source version of the product in lieu of the F5 acquisition?
  • What are you doing to embrace and integrate with micro-services and Kubernetes based deployments?
  • How do you plan to keep a culture of innovation after the merger with F5?

Do you have questions for NGINX? If so, hit me up on Twitter or drop a comment below and I will make sure to include it during the session!

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.