Live data from Hacker News

Come on Amazon, give ELB some love

coderwall.com

11–15 of 15 posts

Re: Come on Amazon, give ELB some love

#13
I agree that ELBs need much more functionality.

In order to get around the lack of features, I only use the ELBs for SSL termination (well, and DNS, and autoscaling). For anything fancier, I've developed a coprocess that manages HAProxy behind the scenes. It leverages Auto Scaling notifications to keep the backend instances in sync. It has a REST API so that you can drive configuration, and it works in a master-master configuration.

It's been running in production for about 9 months now, and has proven invaluable. Having hooks at this layer is incredible. I'm able to get amazing debugging information, I can "bumper" the site at the frontend, I can do 100% zero downtime deployments with quick rollback, I can tarpit and rate limit, etc.

Once I added enough "sugar", I started to realize that maybe AWS is doing it right -- it'd be impossible to add all the features that every customer would want to the ELB. However, WebSocket support and request draining are low-hanging fruit. Same goes for the support for generic HTTP methods, which was implemented some time ago.

Re: Come on Amazon, give ELB some love

#14
post #8

I'd also love to see support for draining - and it seems like we might be in luck in the near future: https://forums.aws.amazon.com/thread.jspa?threadID=61278&sta... ^-- BenF@AWS commented on June 10th saying that amazon is now actively working on it!

Draining is easy. Your health check should be hitting a url like '/ping' anyway which responds with an OK if the box is in a reasonable state and willing to serve traffic.

I always add an additional check to see if a file called /tmp/down exists, and if it does, return a 500 for the health checks. Existing clients will continue to be served but that instance will get no new connections.

Post reply on HN