Hacker News new | ask | show | jobs
by bgentry 3603 days ago
I was coming here to ask whether pre-warming is still an issue with the ALB service. Maybe jeffbarr can comment on whether that's changed?

GCE's load balancer does not use independent VM instances for each load balancer, instead balancing at the network level. So you can instantly scale from 0 to 1M req/s with no issues at all.

4 comments

You can request pre-warming for additional ELB capacity, when you know far enough in advance that you will have a spike. AWS customer service responds by asking 10 clarifying questions via email. The thing is, we can't look under the hood to see currently provisioned and utilized ELB capacity, so we just have to trust that AWS engineers will properly allocate resources according to the answers to those questions. IMO, it's a rather cumbersome process that would be better implemented as a form.
It is weird that given how much in the way of tools and self-help that AWS gives you, that prewarming involves this manual process involving a dozen questions, some of which are unanswerable, and there's no 'pre-warming' form to fill out - the service rep gives them to you in free text.
its cumbersome, and not remotely useful in this specific situation from OP anyway.
It's not clear why it's not useful? The OP said hot spots at tops of each minute, quarter hour, hour and midnight of popular tz offsets like UTC, us eastern, etc., so wouldn't he just tell Amazon "Hey, we get xx requests/second at our peak, so we'd like the ELB ready scaled to handle that load"?
Yes, Google's load balancer is the best one available today. The lack of native websockets support is probably the only disadvantage but made up for with the scaling abilities and cross-region support.

ALB pricing is strange too, classic AWS style complexity.

The Google load balancer supports proxy websockets over SSL (wss://) with the SSL Proxy mode: https://cloud.google.com/compute/docs/load-balancing/tcp-ssl...
Yes, it's always possible by dropping down to the lower network level but it would be nice to have it as a natively supported protocol as part of an existing HTTPS LB.
AWS Support has confirmed: while ALB should be faster, it could still require pre-warming depending on the exact use case.
bgentry, what do you mean with not needing VM instances? I believe that regardless of the layer at which you load balance (network or application) you still need compute instances to run the LB logic, host the connection tables, etc.
I think the general difference is, in AWS you provision your own "private" little loadbalancer instance, and they have logic on how little or big (in terms of compute, bandwith etc) this specific loadbalancer needs to be, and resize it constantly for you.

Google runs a single gigantic distributed loadbalancer, and simply adds some rules for your specific traffic to it. All of the compute and bandwith behind this loadbalancer is able to help serving your traffic spike.

Google's load balancer is a SDN (software defined networking) setup that basically runs as software on their normal computing clusters that power the rest of their services. They have plenty of capacity already handling all the other traffic so there's no real difference in handling a few more requests, unlike AWS which manages custom instances and resizing just for your ELB.

GCP LB design details: https://cloudplatform.googleblog.com/2016/03/Google-shares-s...