Hacker News Reader

Comment by fasteo | Hacker News Reader

Many installations would go from haproxy->nginx to nginx->nginx. Having to support a single product will make many devops happy.

In the same tense, haproxy is adding Lua support[1], which has been available in nginx - using openresty[2] - since 2011, and nginx core is doing the same with Javascript[2].

Interesting times aroung haproxy and nginx.

[1] http://blog.haproxy.com/2015/03/12/haproxy-1-6-dev1-and-lua/

[2] http://www.openresty.org

[3] http://www.infoworld.com/article/2838008/javascript/nginx-ha...

View on HN

Not sure about that... HAproxy is a proven technology (very reliable and a joy to use at that) in this field while Nginx is a newcomer and needs to establish its credibility first. I personally wouldn't use such technology for load balancer until it is properly battle-tested. Also, I can't see much of an advantage over (proven) HAproxy - am I missing something?

As for supporting a single product, I don't see the point of that. Using Nginx for load balancing will probably be much different than using Nginx as a web server, so the learning curve is similar.

Not that I don't welcome competition, I just don't see a real need in this space.

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

EDIT 2: no it wasn't, my mistake. I was surprised by this so I checked the page and jumped a gun when I saw "April 1st" on http://www.haproxy.org/news.html. Sorry about that...

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.

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.

>>>>>> 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.

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.

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.

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...

> 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.

Not to mention the vast ecosystem of some really great nginx plugins. The one thing I have found desperately wanting in both nginx and haproxy is the support for real-time stats and filtering found in Varnish (supports HTTP only). I am absolutely hooked!

  // Query Times
  varnishncsa -F '%t %{VCL_Log:Backend}x %Dμs %bB %s %{Varnish:hitmiss}x "%r"'

  // Slow Queries
  varnishncsa -F '%t %{VCL_Log:Backend}x %Dμs %bB %s %{Varnish:hitmiss}x "%r"' -m "VCL_Log:SlowQuery"

  // Top URLs
  varnishtop -i RxURL

  // Top Referer, User-Agent, etc.
  varnishtop -i RxHeader -I Referer
  varnishtop -i RxHeader -I User-Agent

  // Cache Misses
  varnishtop -i TxURL

  // awesome dashboard
  varnishstat

I've been able to get real-time stats in nginx by adding custom counters with the lua plugin and exporting a stats handler.

http://wiki.nginx.org/HttpLuaModule#ngx.shared.DICT

You can also use collectd nginx module along with nginx stub-status module to gather some useful metrics.

Awesome news for nginx users. But why should the first reaction should be about criticizing the other option? Some HAProxy users may or may not switch to this new product in the coming years. I probably won’t. Even today there is a big overlap between what HAProxy, nginx, and some other tools do and yet everybody works with what they prefer. Adding another feature that until now HAProxy had and nginx didn’t have doesn’t mean a dramatic time for this “competition” (even if such a thing exists).

nginx lacks of many good improvements and fixes which does not accepted upstream devs, so nginx has so many 3rd party modules which most of them are invalid because of nginx version changes or requires old buggy nginx version to run

openresty well it is standalone product, it is build on top nginx with many 3rd party modules and many improvements accepted/not accepted by upstream, and of course big Lua support

Reply on news.ycombinator.com