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.