Nginx has supported http loadbalancing basically forever using the upstream directive along with proxy_pass. It supports leastconn, round-robin, and ip-hash (sticky). It is far from unproven. I have personally used it successfully in some huge projects. This new announcement simply makes the existing functionality work with tcp backends.

> As for supporting a single product, I don't see the point of that.

It's not about configuration; it's about security. Fewer products in your stack means fewer things to patch. Rather than updating nginx some times and haproxy other times, you just update nginx across all your machines (both web servers and load balancers), and you're done. This also gives you more time with which to vet any given nginx update.

> It's not about configuration; it's about security. Fewer products in your stack means fewer things to patch.

Kind of the reverse of the defense-in-depth principle eh? ;-)

Defense-in-depth doesn't work very well for infrastructure software packages: many projects share the same libraries with the same vulnerabilities (e.g. OpenSSL) but still have to be updated with independent package updates.

A shared-library vulnerability means both Nginx and HAProxy get broken in their own ways, which is worse, I think, than just having your whole stack rely on one or the other, and having that one break—it's more similar to having two independent vulnerabilities arise simultaneously.

You're only going to do TLS encrypt/decrypt in one place, so in that particular case... something is wrong.

However, the scenario you describe is one where you would likely NOT be doing defense in depth, because you'd be using the same library to handle a vital piece of your security infrastructure.

Regardless, when a shared library is updated for security, you don't need to apply updates to packages using the shared library. That's kind of the point. The only exception is when the flaw is in the interface to the library.

The win entirely derives from the case of having the two independent vulnerabilities. Since they are broken in their own ways it isn't sufficient to find a way to exploit one system (which would work great for attacking a system with both). You have to find a way to exploit each, and you have to find a way to connect the two so you can get all the way through.

For anyone already using nginx in their stack, I don't think these things (being a newcomer, or needing credibility) are a very big concern. Some people are already used to using nginx as a load balancer for HTTP traffic (this new feature adds load balancing for any TCP traffic) so those users won't have much gap to cover. Also this feature was in the nginx+ version, which presumably means it has already been battle-tested by their enterprise customers.

There is a world of difference between layer-3/4 style load balancers and layer-7 load balancers. If you want to do it right, you often employ both.

I think the April Fool's joke was around HAProxy being completely rewritten in Lua: http://www.haproxy.org/news.html

Oops, you are correct... the joke is on me. Thanks for correcting me.

>>>>>> EDIT: btw, the Lua thing was an April Fool's joke...

Are you sure ? The 1.6 dev repo contains Lua related code [1]

[1] http://git.haproxy.org/?p=haproxy.git;a=blob_plain;f=src/hlu...

I think, the Lua rewrite was a joke. But support for lua in haproxy is not.

HAProxy offers a better DDos mitigation configurables in comparison to nginx. Thats it.

CloudFlare is build on top of OpenResty which is basically stock nginx with ngx_lua and a bunch of other modules built in. I would argue that if you want it to be, nginx can be much better at DDoS mitigation. You can use the modules limit_conn and limit_req to control how many connection individual IPs can make to your server for basic control.

You can add various things on top of nginx... but you can use stock haproxy to limit the number of connections by source IP.

This can also be achieved in nginx fairly easy:

http://nginx.org/en/docs/http/ngx_http_limit_conn_module.htm...

nginx is definitely not quite a newcomer. Someone already mentioned it but it already proxied http for many year. Moreover it proxies websockets, which are basically long lived TCP connections.