| disclaimer: I work at HAProxy Technologies More control/flexibility (i.e. cloud provider usually gives you a limited number of "checkboxes" that they want you to be able to modify), generally better observability (HAProxy timing metrics [1] and session state at disconnection codes [2] are very helpful for debugging), and granular control over timeouts [3]. You also get builtin rate limiting [4], which from what I have seen with most cloud load balancers usually requires an up-charge through their "WAF" product. Better health checking, circuit breaking, and layer4/layer7 retries [5]. Another consideration is whether you have spiky traffic patterns. For AWS load balancers at least, they need time to "warm up" to larger traffic levels. If you manage your own load balancing tier you can scale on demand. [1] https://www.haproxy.com/documentation/hapee/latest/onepage/#... [2] https://www.haproxy.com/documentation/hapee/latest/onepage/#... [3] https://www.haproxy.com/documentation/hapee/latest/onepage/#... [4] https://www.haproxy.com/blog/four-examples-of-haproxy-rate-l... [5] https://www.haproxy.com/blog/haproxy-layer-7-retries-and-cha... |
Question about the suitability for a dynamic backend case. I have a system where clients are assigned to backends exclusively for the duration of a session. At the moment I have a pool of backends and each client is explicitly told which backend to use so they can route to it. Ideally I’d make this transparent so it was easier to reassign on the fly. Is this case reasonably supported with HAProxy and which features should I be looking at to get a sense of it?
I’m working under the assumption that I’ll need to build the machinery to maintain the pool and registry of where clients should be routed to.