Live data from Hacker News

AWS Application Load Balancer

aws.amazon.com

121–130 of 140 posts

Re: AWS Application Load Balancer

#121

We plan to do a blog post about this at some point, but we had the pleasure of seeing exactly how elastic the elb is when we switched Cronitor from linode to aws in February 2015. Requisite backstory: Our api traffic comes from jobs, daemons, etc, which tend to create huge hot spots at tops of each minute, quarter hour, hour and midnight of popular tz offsets like UTC, us eastern, etc. There is an emergent behavior t…

As someone who is apparently all-in on AWS, can you explain how you justify the cost? I understand the convenience of having all the pre-built services, but that is a finitely limited benefit. The vendor lock-in of the entire infrastructure and deployment processes being extremely AWS-specific means it's financially infeasible to migrate elsewhere once you are launched. Tack on the expensive-beyond-belief S3 server p…

We're paying an agility premium, that's why. My company has both colocated and AWS assets, and while we save a bunch of money with the colocated assets over their AWS equivalents, we would much rather work with the AWS assets.

We don't have to bother ourselves with managing SANs, managing bare metal, managing hardware component failures and FRUs, managing PDUs, managing DHCP and PXE boot, managing load balancers, managing networks and VLANs, and managing hypervisors and VMs. We don't have to set up NFS or object stores.

Being on a mature managed service platform like AWS means that if we want 10 or 100 VMs, I can ask for them and get them in minutes. If I want to switch to beefier hardware, I can do so in minutes. If I want a new subnet in a different region, I can have one in minutes. There's simply no way I can have that kind of agility running my own datacenters.

Nobody disputes that AWS is expensive. But we're not paying for hardware or bandwidth qua hardware or bandwidth - we're paying for value added.

Re: AWS Application Load Balancer

#122

We plan to do a blog post about this at some point, but we had the pleasure of seeing exactly how elastic the elb is when we switched Cronitor from linode to aws in February 2015. Requisite backstory: Our api traffic comes from jobs, daemons, etc, which tend to create huge hot spots at tops of each minute, quarter hour, hour and midnight of popular tz offsets like UTC, us eastern, etc. There is an emergent behavior t…

As someone who is apparently all-in on AWS, can you explain how you justify the cost? I understand the convenience of having all the pre-built services, but that is a finitely limited benefit. The vendor lock-in of the entire infrastructure and deployment processes being extremely AWS-specific means it's financially infeasible to migrate elsewhere once you are launched. Tack on the expensive-beyond-belief S3 server p…

Here's some cases that I've handled with AWS that justifies the cost:

- About a month ago, our database filled up, both in space and IOPS required. We do sizeable operations every day, and jobs were stacking up. I clicked a couple buttons and upgraded our RDS instance in-place, with no downtime.

- We were going through a security audit. We spun up an identical clone of production and ran the audit against that, so we didn't disrupt normal operations if anything crashy was found.

- Our nightly processing scaled poorly on a single box, and we turned on a bunch of new customers to find that our nightly jobs now took 30 hours. We were in the middle of a feature crunch and had no time to re-write any of the logic. We spun up a bunch of new instances with cron jobs and migrated everything that day.

100% worth it for a small business that's focused on features. Every minute I don't mess with servers is a minute I can talk to customers.

Re: AWS Application Load Balancer

#123
post #66

Earlier quoted context omitted.

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…

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"?

Re: AWS Application Load Balancer

#124

Earlier quoted context omitted.

As someone who is apparently all-in on AWS, can you explain how you justify the cost? I understand the convenience of having all the pre-built services, but that is a finitely limited benefit. The vendor lock-in of the entire infrastructure and deployment processes being extremely AWS-specific means it's financially infeasible to migrate elsewhere once you are launched. Tack on the expensive-beyond-belief S3 server p…

We're paying an agility premium, that's why. My company has both colocated and AWS assets, and while we save a bunch of money with the colocated assets over their AWS equivalents, we would much rather work with the AWS assets. We don't have to bother ourselves with managing SANs, managing bare metal, managing hardware component failures and FRUs, managing PDUs, managing DHCP and PXE boot, managing load balancers, man…

Curious, would you say this an indication that there are not enough talented/competent sysadmin/infrastructure people to employ to manage those tasks in-house? Or is it your opinion that AWS provides so much value that in-house simply can't compete in terms of the man-hours it would require to manage the equivalent? The whole "spin up in minutes" is certainly not unique to AWS; most hosting providers, especially if you are a sizeable business, is going to be at your beck and call whenever you need them.

I still think the benefits of AWS are over-emphasized within most businesses. Of the 4 companies I've worked for that used AWS, 3 of them did absolutely nothing different than you'd do anywhere else. One-time setup of a static number of servers, with none of the scaling/redundancy/failure scenarios accounted for. The 4th company tried to make use of AWS's unique possibilities, but honestly we had more downtime due to poorly arranged "magical automation" than I've ever seen with in-house. I suppose it requires a combination of the AWS stack's offerings and knowledgeable sysadmins who have experience with its unique complexities.

Disclaimer: I'm a developer rather than a sysadmin, not trying to justify my own existence. :p

Re: AWS Application Load Balancer

#125

We plan to do a blog post about this at some point, but we had the pleasure of seeing exactly how elastic the elb is when we switched Cronitor from linode to aws in February 2015. Requisite backstory: Our api traffic comes from jobs, daemons, etc, which tend to create huge hot spots at tops of each minute, quarter hour, hour and midnight of popular tz offsets like UTC, us eastern, etc. There is an emergent behavior t…

As someone who is apparently all-in on AWS, can you explain how you justify the cost? I understand the convenience of having all the pre-built services, but that is a finitely limited benefit. The vendor lock-in of the entire infrastructure and deployment processes being extremely AWS-specific means it's financially infeasible to migrate elsewhere once you are launched. Tack on the expensive-beyond-belief S3 server p…

We have finite time to improve a product. Any minutes spent racking servers (physically or otherwise) are minutes spent not working on something that adds value for our users. Driving the top line is more important than optimizing expenses that are relatively small.

We started Cronitor as a side business and we've grown by seeking out the highest leverage usage of our time. My cofounder wrote a blog post about this https://blog.cronitor.io/the-jit-startup-bb1a13381b0#.kwbpma...

Re: AWS Application Load Balancer

#126

Earlier quoted context omitted.

Curious, why would you combine this with Phoenix?

Because Phoenix has a WS abstraction (Channels) and supports it out of the box.

Yes but isn't one of Elixir's strenghts that it scales very well on a single machine? Why do we need the load balancing?

Re: AWS Application Load Balancer

#128
post #48

Earlier quoted context omitted.

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.

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.

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...

Re: AWS Application Load Balancer

#129

Earlier quoted context omitted.

Small correction to my previous answer, Elastic Beanstalk will support ALB in the very near future.

Great. I'm looking forward to the day when I can retire my hacky workarounds to facilitate websockets on Elastic Beanstalk.

Out of curiosity, what are these workarounds ?
Post reply on HN