Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

When AWS Autoscale Doesn’t

segment.com

Post reply on HN
Print view View original

11–20 of 99 posts

Re: When AWS Autoscale Doesn’t

#11

Post by eunoia »

avitzurel wrote: post #2

There are many limitations that you need to "read between the lines" with AWS auto scaling. For example, we have daemons reading messages from SQS, if you try to use auto scaling based on SQS metrics, you come to realize pretty quickly that CloudWatch is updated every 5 minutes. For most messages, this is simply too late. In a lot of cases, you are better off with updating CloudWatch yourself with your own interval u…

Out of curiosity, what’s the use case for running ECS on EC2 (instead of using Fargate) these days?

Re: When AWS Autoscale Doesn’t

#12

Post by hectormalot »

doctorpangloss wrote: post #6

An incredible amount of software and infrastructure is written precisely for analytics data gathering workloads. I'm pretty confident AWS's product for this use case would be Lambda and the new on-demand DynamoDB. Is there actually a use case in analytics that requires a server that accepts connections from multiple clients, and then has to have Because if there isn't, if your goal is to scale, why have containers at…

Im under the impression that lambda gets expensive if you have many requests. E.g. the story on ipify that showed 1000s of USD on lambda vs 100s on Heroku:

“Today the service runs for between $150/mo and $200/mo depending on burst traffic and other factors. If I factor that into my calculator (assuming a $200/mo spend), ipify is able to service each request for total cost of $0.000000007. That’s astoundingly low.

If you compare that to the expected cost of running the same service on a serverless or functions-as-a-service provider, ipify would cost thousands of dollars per month.”

Re: When AWS Autoscale Doesn’t

#13

Post by Thaxll »

Legogris wrote: post #7

Having used ECS quite a bit, I do not recommend anyone building a new stack based on it. Kubernetes solves everything ECS solves, but usually better and without sveral of the issues mentioned here. Last time I checked, AWS was still lagging behind Azure and GCP on Kubernetes, but I have a strong feeling they're prioritizing improving EKS over ECS. If you're already invested in ECS it's a different story, of course.

Kubernetes is way more complicated if you just need to run one or two services using Docker, Fargate is brand new so it has a lot of things to prove...

Re: When AWS Autoscale Doesn’t

#15

Post by taormina »

pram wrote: post #9
Legogris wrote: post #7

Having used ECS quite a bit, I do not recommend anyone building a new stack based on it. Kubernetes solves everything ECS solves, but usually better and without sveral of the issues mentioned here. Last time I checked, AWS was still lagging behind Azure and GCP on Kubernetes, but I have a strong feeling they're prioritizing improving EKS over ECS. If you're already invested in ECS it's a different story, of course.

I think that Fargate is the “improvement” for ECS. I never understood the appeal of ECS in the first place, seemed (and still does) really half baked.

Fargate is almost what the marketing team said ECS was going to be.

Re: When AWS Autoscale Doesn’t

#16

Post by DVassallo »

The way I've been happiest using EC2 Auto Scaling was to have a single cron-job continuously calculating how many instances I should be running, and it sets the desired capacity manually with the Auto Scaling API[1]. This may seem to defeat the purpose of Auto Scaling, but it's actually much more convenient than spinning up/down EC2 instances with the EC2 API. You get to precisely control how to scale, and won't be at the mercy of the Auto Scaling heuristics.

[1] https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-man...

Re: When AWS Autoscale Doesn’t

#17

Post by DanFeldman »

Legogris wrote: post #7

Having used ECS quite a bit, I do not recommend anyone building a new stack based on it. Kubernetes solves everything ECS solves, but usually better and without sveral of the issues mentioned here. Last time I checked, AWS was still lagging behind Azure and GCP on Kubernetes, but I have a strong feeling they're prioritizing improving EKS over ECS. If you're already invested in ECS it's a different story, of course.

We use a ton of ECS, for running batch processing for our data pipeline, 4ish small internal webapps/microservices, and our Jenkins testing compute.

Some of the problems we're seeing is task placement and waiting is too hard (we had to write our own jittered waiter to not overload the ecs api endpoints when asking if our tasks are ready to place). Scaling the underlining EC2 instances is slow. The task definition=>family=>container definition hierarchy is not great. Log discovery is a bitch.

Are these all solved under K8S? I've no experience with kubernetes, but if so, might need to rethink where we run our containers. ECS was just so easy, and then so hard.

Re: When AWS Autoscale Doesn’t

#19

Post by acd »

AWS needs to glue EC2 and ECS scheduling together. Today the schedulers are separate. So basically the feet does not know what the arms are doing. That leaves fixing this scaling up to the client meaning duplicate code effort solving the same thing for each AWS customer.

Re: When AWS Autoscale Doesn’t

#20

Post by cs02rm0 »

hectormalot wrote: post #12
doctorpangloss wrote: post #6

An incredible amount of software and infrastructure is written precisely for analytics data gathering workloads. I'm pretty confident AWS's product for this use case would be Lambda and the new on-demand DynamoDB. Is there actually a use case in analytics that requires a server that accepts connections from multiple clients, and then has to have Because if there isn't, if your goal is to scale, why have containers at…

Im under the impression that lambda gets expensive if you have many requests. E.g. the story on ipify that showed 1000s of USD on lambda vs 100s on Heroku: “Today the service runs for between $150/mo and $200/mo depending on burst traffic and other factors. If I factor that into my calculator (assuming a $200/mo spend), ipify is able to service each request for total cost of $0.000000007. That’s astoundingly low. If…

I'm sure that's true, but you have to be churning through quite a lot of requests to get there.

Sadly so, because I can't stand lambda!

Post reply on HN