Can I Replace a Commercial Load Balancer with HAProxy?

A networking engineer attending the Building Next-Generation Data Centers online course sent me this question:

My client will migrate their data center, so they’re not interested in upgrading existing $vendor load balancers. Would HAProxy be a good alternative?

As you might be facing a similar challenge, here’s what I told him:

TL&DR: It depends.

First things first: HAProxy, nginx and Varnish are used in some very large production environments, and I will not even try to go into “which one is better” religious wars.

Performance doesn’t seem to be an issue. I’ve seen printouts from HAProxy environment running 250K concurrent TCP sessions on a single server, and there are people claiming to run 2M concurrent SSL sessions on HAProxy.

All three products offer commercial support, so that’s not an issue either.

Now for the interesting part…

Some assembly required. Commercial load balancer (oops, application delivery controller… it sounds so much better) appliance is a black box that you can turn on and configure with high-level CLI or GUI.

Open-source products I mentioned are software packages that have to be installed on a Linux server. You need someone who can spell Linux without using Google to make it work… and please don’t try to hack your way through the Linux jungle with Google-and-Paste machete. Your business will thank you.

High-performance load balancing on Linux requires performance tuning, including kernel performance tuning. Yet again, you better have someone handy who did a similar job in the past… or you might discover the beauties of full-stack awareness.

Featuritis. Commercial load balancers are full of features that the vendors tell you to use to solve all sorts of problems caused by craplications deployed in your data center. Think crazy stickiness rules, changing TCP parameters left and right, doing all sorts of content manipulation. Not surprisingly, the more features you use, the happier the $vendors are – not only are you locking yourself into their platform, you also burn more CPU cycles on their boxes and thus need more expensive boxes.

The open-source software you plan to use might or might not have those features, so you have to:

  • Identify which features your current load balancer is using;
  • Figure out which one of these have a reasonable equivalent in the open-source software you’re considering;
  • Decide whether you can stop using the features that the open-source software doesn’t support.

Layer 7-9 reasons. A long while ago when Interop was in that brief interim phase when they really cared about education, I ran a workshop there and asked the audience where they use open source software in their application stack.

After the workshop an engineer approach me and told me that the only reason they’re not using open-source load balancers is legal: if the whole thing crashes, they want to have someone to sue, and to do that they have to buy a black box solution from a vendor. Welcome to reality.


  1. Welcome to reality describes it very well ;-) Design process usually includes the One Throat To Choke (OTTC) factor. That's one of the reasons "Buy" wins over "Build" most of the times. You can build it cheaper, free from legacy of unused features and customized to your business needs. But if it can't pass the OTTC factor it will not be chosen. Unless someone accepts the risk, of course. Usually this is a short time solution used by some managers. They save a lot in the first year budget, introducing open-source solutions and a lot of hidden operations costs and tech debt then get it's bonus for the savings and leave the company before everything burns. I've seen this happen a few times.
    1. Totally agree, I usually go with a Two Throat To Choke (TTTC) minimum for any internally supported system :-). A lot of our customers at are simply looking for a reliable commercially supported replacement for a perfectly functional internal system - that no one knows how to fix :-).
  2. If you need a vendor based load-balancing solution in modern topologies that support ECMP I'd encourage taking a look at a VM based solution with anycast. The cost function is a lot smoother.
    1. What VM based solution are you talking about?
    2. F5 is an example. Gives you a vendor for choking, while escaping the need for appliances (which tend to have awesome step functions for cost vs performance.)
  3. What can e.g. F5 do what HAProxy can't?
    What about commercial supported HAProxy solutions like VMWare NSX? Do those only use opensource HAProxy plus add a GUI?
    1. VMware NSX is just GUI/API in front of HAProxy because text configuration files are such a pain ;))... and it seems to give you a sliver of what HAProxy could do (too lazy to do feature-by-feature comparison :D)
  4. With OPNsense you can use HAProxy and Nginx as reverse proxy with a nice GUI, also offering WAF features. The only cost is time (as usual with Open Source) ...
Add comment