One of the last citadels of legacy architecture is hardware load balancers. They are the gatekeepers to your application access and in turn, determines success or failure of your business. Enterprises are spending huge efforts in modernizing IT at every level – application, database, infrastructure, security, everything that you can think about. But most of the time, we found that they overlook the fact that, access to their applications and hence consumer’s experience of their business depends on the gatekeeper i.e. the load balancer that is sitting at the entry point. If you are not able to modernize and make this piece you would never be able to create a dynamism that you are looking to deliver to your customers.
Many customers have acknowledged the need for replacing their existing hardware load balancers like F5, NetScaler etc. but have not been able to get around actually doing it. It is a critical component of your infrastructure and it needs to be handled carefully.
The good news is that there is a world class software load balancer alternative available to you in NGINX Plus. Very large enterprises have actually got rid of their entire legacy hardware load balancer by leveraging versatility of NGINX Plus.
In this article, I would like to share how you can adopt NGNIX Plus as your software load balancer. You can check out Nginx’s other features and capabilities here.
NGINX Plus is a software package which can be installed – on bare metal, a virtual machine, container or on the cloud. NGINX Plus and BIG-IP LTM both act as a full reverse proxy and load balancer so that the client sees the load balancer as the application and the backend servers see the load balancer as the client.
In a typical hardware load balancer setup, load balancers are deployed at the edge of the network that acts as an entry point for all application traffic. Whereas in the case of typical software reverse proxy setup, as in NGINX Plus, most commonly it is deployed closer to the application which can manage all traffic specific to each application type.
Customers who are nearing the end of support for their existing F5 BIG-IP or Citrix NetScaler are seriously exploring moving to NGINX Plus, either by putting NGINX Plus behind their existing application delivery platforms (ADC) as a starter (as in diagram 1 below) or are completely replacing their hardware ADC (as in diagram 2 below).

(Using the hand-drawn illustrations which were used for one of our customer meetings )

As mentioned earlier, and as shown in the above Diagram 1, NGINX Plus can run behind an existing Hardware Load Balancer and can handle application traffic for each application type. One can take this as a phased approach to move to NGINX Plus.

In the above Diagram 2, NGINX Plus replaces Legacy hardware Load Balancer to handle all incoming traffic.
While discussing the solutions with customers, the question mostly we get is “How do we smoothly move to NGINX Plus?” and “How do we handle the custom written rules?”
In case of F5, commands and concepts do not always directly translate to NGINX Plus. Instead, it needs an understanding of differences in terminology or the different ways of implementation. Below are some of the key aspects which would help you in migrating from F5 BIG-IP to NGINX Plus.
NGINX Plus concepts and terminologies:
[bctt tweet=”Few key concepts of Hardware Load Balancer which can be easily mapped to NGINX Plus are Self-IP address, Management IP address: Port pairs, Virtual servers, Pool and node list.”]
In addition to these, two very important categories to consider while migration is “iRules” and “High Availability”.
iRules is specifically used by BIG-IP LTM as event-driven content switching and traffic-manipulation engine to control application traffic network. Whereas, NGINX Plus handles content switching and HTTP session manipulation natively. Most of the iRules can be translated to the “server” and “location” blocks. Some policies which are complex to implement directly with NGINX configuration can be handled by dynamic modules that enable scripting in “Lua”, “Perl” and “JavaScript”.
Use cases of migrating Layer 7 iRules of F5 to NGINX Plus configurations:
Request Routing (Content-based routing or content switching) gives end users an impression of a single unified application but in fact, hosts many different applications. NGINX Plus sends each request to the upstream server based on the header or the URI.
NGINX Plus implements request routing with location directive.

1. NGINX Plus Configuration for “Request Routing based on URI”

location /Jeep {
    proxy_pass https://Jeep_models;
}
In the above example, if the URI starts with /Jeep, the request is routed to Jeep_models upstream group.

2. NGINX Plus Configuration for “Request Routing based on User-Agent Header”

map $http_user_agent $upstream_choice {
  ~(iPhone|iPad|iPod) ios_backend;
  ~Android android_backend;
}
server {
  listen 80;
  location / {
    proxy_pass https://$upstream_choice;
  }
}
In above example request routing is performed based on the User-Agent header in the client request. Request from iOS and Android are directed to separate upstream application servers.

3. NGINX Plus Configuration for “Request Redirect to HTTPS”

location / {
    return 301 https://$host$request_uri;
}
Here the client plain HTTP request is redirected to HTTPS to secure the session.

4. NGINX Plus Configuration for “Request Rewrite Links from Response”

location / {
    sub_filter ‘/Fiat/’ ‘/Jeep/’;
    proxy_pass https://Jeep_models;
}
Rewriting the response body is often done along with request routing, to change links in the response body to reflect the new URI structure created by the request routing.
To rewrite HTTP responses with NGINX Plus, use the sub_filter directive. It takes two parameters: the string for NGINX Plus to search for and replace, and the replacement string.
In the above example links containing /Fiat/ directory element is replaced by /Jeep/
NGINX Plus covers many scripting use cases, embedded languages like Lua, Perl, and JavaScript help in migrating any complex customized use case, along with powerful toolset which helps to migrate from hardware-based ADC to NGINX Plus in a straightforward manner.
And today, NGINX Plus is the preferred choice for many enterprises globally. Time to make it work for your business too. If you need more information, you can get in touch with us at success@ashnik.com