3 ms·

HAProxy is a great fit for most microservices, but I'm not sure it has the feature set for most organizations that are deep into microservices - at least in the

by exelius 11y ago

HAProxy is a great fit for most microservices, but I'm not sure it has the feature set for most organizations that are deep into microservices - at least in the way the author describes it. The problem is more business-driven than technical; so let me explain why (and feel free to correct me if you think I'm wrong!) Most companies don't need microservices, so I'm making an assumption that any company using microservices has both the volume and complexity of business partners that make a microservices approach a good business idea (this assumption is assuredly false, but still useful). And if you've gone this route, the next step is generally organizing your business around an SOA where business units can be represented by an API (microservices are useful from a business perspective because you have many stakeholders within a company that want to make small changes frequently but independently). Once you've done that, you start wanting to encapsulate your relationship with your customers in an API as well, and the eventual destination (if your company survives long enough and is successful) is that you just operate a set of APIs that power your customer-facing UX product in addition to the API-based services you provide to your high-volume clients. My point is this: the end state of a microservices architecture is an API gateway. API gateways provide essential services such as authentication, access control, and connection throttling. You still need something like HAProxy to provide you with load balancing, health checks, etc. across many nodes - but you're going to have a very simple instance of HAproxy for each microservice and rely on your API gateway to organize everything under a single domain. With microservices, your configurations can get incredibly complex very quickly, so it's often better to maintain independent components with very simple configurations (that can be easily updated dynamically) than to try to have a single component in the middle of your stack upon which many other components are dependent.

imdsm 11y ago
I think that HAProxy can work, but it needs assistance. As it doesn't allow you to use resolvable hostnames, you can't rely on DNS load balancing for microservices. As I said in my comment on the article, Consul + Consul-template works well for this.
- exelius 11y ago
  Yeah, you need an orchestration layer to really handle microservices at scale (yet another reason they're a pain in the ass!) Not just for HAproxy, but there are countless other situations where you need to use referential data to build configurations on the fly -- which is what an orchestration layer does.
- vidarh 11y ago
  As of 1.6 it does allow resolvable hostnames [1]. This is the example given in the release announcement: resolvers docker nameserver dnsmasq 127.0.0.1:53 defaults mode http log global option httplog frontend f_myapp bind :80 default_backend b_myapp backend b_myapp server s1 nginx1:80 check resolvers docker resolve-prefer ipv4 [1] http://blog.haproxy.com/2015/10/14/whats-new-in-haproxy-1-6/ http://blog.haproxy.com/2015/10/14/whats-new-in-haproxy-1-6/
  - imdsm 11y ago
    Oh, cool, that's interesting! Thanks for the heads up. Missed that one!
  - exelius 11y ago
    That's pretty new; but still doesn't remove the need for an orchestration layer (though it does make it a lot easier since I often rely on DNS with short TTLs for global routing).
jy2947 11y ago
+1
deleted 11y ago
[deleted]

by exelius 11y ago

imdsm 11y ago

I think that HAProxy can work, but it needs assistance. As it doesn't allow you to use resolvable hostnames, you can't rely on DNS load balancing for microservices. As I said in my comment on the article, Consul + Consul-template works well for this.

exelius 11y ago
Yeah, you need an orchestration layer to really handle microservices at scale (yet another reason they're a pain in the ass!) Not just for HAproxy, but there are countless other situations where you need to use referential data to build configurations on the fly -- which is what an orchestration layer does.
vidarh 11y ago
As of 1.6 it does allow resolvable hostnames [1]. This is the example given in the release announcement: resolvers docker nameserver dnsmasq 127.0.0.1:53 defaults mode http log global option httplog frontend f_myapp bind :80 default_backend b_myapp backend b_myapp server s1 nginx1:80 check resolvers docker resolve-prefer ipv4 [1] http://blog.haproxy.com/2015/10/14/whats-new-in-haproxy-1-6/ http://blog.haproxy.com/2015/10/14/whats-new-in-haproxy-1-6/
- imdsm 11y ago
  Oh, cool, that's interesting! Thanks for the heads up. Missed that one!
- exelius 11y ago
  That's pretty new; but still doesn't remove the need for an orchestration layer (though it does make it a lot easier since I often rely on DNS with short TTLs for global routing).

jy2947 11y ago

deleted 11y ago

[deleted]