Scaling Down Gracefully with AWS Lambda and HAProxy
contentful.com
contentful.com
I can't imagine deploying our own HAProxy infrastructure. Sure, it's relatively simple, but the set-it-and-forget-it comfort provided by ELB (not to mention free SSL) is hard to beat.
Running your own HAProxy infrastructure isn't terribly time consuming, but I do devops/infrastructure all day long; I'm biased. If you can and do avoid it, I can understand why.
Also, because you have control over it, you have more options for service discovery (i.e. write a Python script that periodically queries a Kubernetes cluster).
And virtual hosts... And SNI... And about a thousand other features.
Honestly, ELBs are pretty crappy.
I love that I can specify existing IAM SSL certs to an ELB; I don't have to provide access to the actual certs/keys to folks who want to provision their own ELBs in our environment, they simply need to pass through the IAM resource in the config. Its a small thing, but still important.
EDIT: Something to note though, from my trails of broken glass I've walked; the process limits haproxy displays in the web interface don't always match the process limits the process actually has (as determined via /proc/<process_id>/limits). Don't get burned like I did (too few file descriptors despite haproxy indicating the contrary, epic connection failures).
I implemented something similar with puppet/mcollective/SQS years back. Poor man's service discovery. Here are some other options that, if you can handle the complexity of running Zookeper (or similar), are probably a bit cleaner:
http://jasonwilder.com/blog/2014/02/04/service-discovery-in-...
If you restart, however, everything's dropped.
The DNS resolution work that is going into 1.6 releases may lead to a workable approach where you over allocate servers in a backend and then update them to have the right host/port. Last I checked, however, you still couldn't set the port dynamically.