When AWS Autoscale Doesn’t
segment.com
When AWS Autoscale Doesn’t
1–10 of 99 posts
Re: When AWS Autoscale Doesn’t
#2There 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 using lambda functions (for example) and let the rest follow the path of AWS managed auto scaling.
There is also a cascading auto scale that you need to follow. If we take ECS for example, you need to have auto scaling for the containers running (Tasks) AND after that you also need auto scaling for the EC2 resources. Both of these have different scaling speeds. Containers scale instantly while instances scale much slower. Even if you pack your own image, there is still a significant delay.
Re: When AWS Autoscale Doesn’t
#3I'm surprised I didn't see application performance monitoring mentioned here. A lot of applications are complex and in those cases adding containers is only effective until you reach the next constraint.
Having two resources (such as DB and app) scale in concert can be exceedingly difficult.
Re: When AWS Autoscale Doesn’t
#4I'm surprised I didn't see application performance monitoring mentioned here. A lot of applications are complex and in those cases adding containers is only effective until you reach the next constraint. Having two resources (such as DB and app) scale in concert can be exceedingly difficult.
(Author here) Absolutely! It's amazing how complex things get on the configuration side as you try to get smarter about autoscaling. The big downside of trying to be too clever here is that you wind up with a wildly brittle autoscaling setup that falls over as soon as the underlying assumptions around the relationship between your metrics and your scaling needs change. As in many things engineering, we've found that it's best to keep the configuration as simple as possible and use a solid foundation of reporting / alerting to give you an early heads up that you need to revisit and update your autoscaling strategy.
Re: When AWS Autoscale Doesn’t
#5Vertical autoscale is on my wish list. Some way to automatically scale instance size for those things that don't scale well horizontally.
Re: When AWS Autoscale Doesn’t
#6An 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 all?
Re: When AWS Autoscale Doesn’t
#7Having 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.
Re: When AWS Autoscale Doesn’t
#8An 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…
Batching incoming requests, for one. Kinesis only allows 5 write requests per second per shard, for example. As well, Lambda have limits regarding concurrent executions and are very slow (10s) if needing VPC connectivity (in this case the default concurrent lambda limit is 350 due to ENIs)
Re: When AWS Autoscale Doesn’t
#9Having 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.
Re: When AWS Autoscale Doesn’t
#10There 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…
From a bird's eye view, you also need to figure out what costs you more.
For example (and I know nothing about the use-case of OP, can only estimate), you might be able to buffer requests into a queue and have it scale up slower.
You might have auto scaling that needs to be close to real time and auto scaling that can happen on a span of minutes.
Every auto scaling needs to also keep in mind the storage scaling, often you are limited by the DB write capacity or others.