Hacker News Reader

Comment by doublerebel | Hacker News Reader

Interesting that HAProxy believes it is incumbent enough to charge for directly copying a feature Consul has had for years. When I added Consul to my stack 3 years ago HAProxy was already looking behind the times... I don't think they can catch up for any new installation.

View on HN

I don't understand what you mean here. Consul is not a load balancer. It's functionality is almost entirely orthogonal to Haproxy.

If anything, a lot of people pair the two, but have so far often had to resort to cumbersome solutions for rewriting the Haproxy config to keep the set of backends in Haproxy updated.

If anything, this will make Haproxy and Consul work much better together, given that Consul serves up SRV records for the services you register with it.

To be honest it's not a matter of duplicating, catching up or anything. It's just that when a significant number of our users ask for exactly the same stuff with similar and sometimes different justifications, it becomes quite hard to avoid adding it. And if they want it there, they very likely have their own very valid reasons. Baptiste (the DNS subsystem maintainer) has a significant amount of use cases in mind and could likely much better explain than me.

We first developped DNS in HAProxy for our AWS users who wanted HAProxy to follow-up a node when it is restarted (and it's IP is changed)... That was the very first request from both community and customers. After we released this feature, the community came back with some requirements regarding the ability to use DNS resolution to resolve all the servers (or a set of servers at list) of a backend. So we had to improve a lot the first dev we did to make this possible. Support for SRV record is just the last stone we put on top of many other devs :)

We're quite proud of the result because it makes HAProxy able to scale up / down at run time without being reloaded and compatible with any service registry able to export a list of nodes delivering a same service through DNS.

HAProxy can use multiple name for the resolution, pointing to different set of DNS servers, enforcing custom "hold" timers (to bypass server's TTL or negative TTLs in case of NX, etc...) and mix all of this with "old style hardcoded" servers in the backend...

HAProxy is flexible :)

The advantage of using SRV records with consul, is that any load-balancer supporting SRV can replace any loadbalancer already in place, almost seamlessly :) This applies to any Service Registry (I tested the feature with both Kubernetes and Consul)

So yes, this feature was missing in HAProxy and we catched up because our community and some customers asked for it. So they can now use the power of HAProxy with their current consul deployments.

This was already addressed in another comment, they aren't charging for it. The preview is only available to enterprise but it will be in the 1.8 release later this year.

I think it'll become hard to explain simple things in this place. THE CODE IS FIRST DEVELOPPED INTO HAPROXY DEVELOPMENT BRANCH AND ONLY THEN BACKPORTED INTO HAPEE ONCE WE CONSIDER IT STABLE ENOUGH. ANY SINGLE HAPEE COMMIT HAS AN UPSTREAM COMMIT ID. What is difficult to understand in this statement ?

Reply on news.ycombinator.com