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

81–90 of 99 posts

Re: When AWS Autoscale Doesn’t

#81

Post by samstave »

AmericanChopper wrote: post #78
samstave wrote: post #33

Earlier quoted context omitted.

So we had this cause a spectacular outage a few years ago. We were doing exactly this - but we had a flaw: we didnt handle the case when the AWS API was actually down. So we were constantly monitoring for how many running instances we had - but when the API went down, just as we were ramping up for our peak traffic - the system thought that none were running because the API was down - so it just kept continually laun…

Another thing to keep in mind is that AWS local capacity can run incredibly close to the wire at times. You might be surprised if you knew how much capacity for your instance type was actually available under the hood. I’ve personally seen insufficient capacity errors.

I've always kept a mental capacity tracker in my head...

Would love to hear what others are also tracking.

Goes to show what their business numbers are....

Re: When AWS Autoscale Doesn’t

#82

Post by Buge »

>So, if you’re targeting 95% CPU utilization in a web service, the maximum amount that the service scales out after each cooldown period is 11%: 100 / 90 = 1.1

How many errors are in that sentence? The 95% -> 90 mysterious conversion. 100/90 is actually 1.111(repeating of course), not 1.1. And if it did equal 1.1 it would be 10%, not 11%.

Re: When AWS Autoscale Doesn’t

#83

Post by ihorman »

etaioinshrdlu wrote: post #53
tyingq wrote: post #5

Vertical autoscale is on my wish list. Some way to automatically scale instance size for those things that don't scale well horizontally.

Jelastic claims to do this, and the marketing made it sound so cool. https://jelastic.com/ But when I tried it, it turns out the docker support requires very specific base images. Not really docker then is it?!?

Jelastic can run docker in two separate ways: 1) the way when the image is running as a plain VZ container (advantage: many extra features become available, disadvantage: compatibility with native docker is not 100%) 2) run via Native docker engine, but instead of VM (like everyone does) elastic VZ container is used as a host machine for running embedded containers. Compatibility with classical docker is 100% + vertical scaling as an extra feature, because of VZ layer on top. Basically both ways of running docker images allows to have flexible and managed resource management so vertical scaling is indeed available for both of them. BTW, Kubernetes in Jelastic is using the same approach that makes Jelastic only available platform for K8S on the market with "pay as you use" billing model, where you can pay only for consumed resources and not for the limits as everyone does.

Re: When AWS Autoscale Doesn’t

#84

Post by RuslanS »

etaioinshrdlu wrote: post #53
tyingq wrote: post #5

Vertical autoscale is on my wish list. Some way to automatically scale instance size for those things that don't scale well horizontally.

Jelastic claims to do this, and the marketing made it sound so cool. https://jelastic.com/ But when I tried it, it turns out the docker support requires very specific base images. Not really docker then is it?!?

Hi, Jelastic founder is here. Thank you for mentioning our product. Vertical scaling is not a marketing :), it's reality. Jelastic public cloud providers offer automatic vertical scaling with pay-as-you-use billing model (please do not confuse with pay-as-you-go). Except this our team helps related technologies to become more elastic, for example Java https://jelastic.com/blog/elastic-jvm-vertical-scaling/

Regarding the docker support, there are two flavors inside Jelastic: 1) Native Docker Engine - you can create a dedicated container engine for your project in the same way as you do on any IaaS today, for example “How to run Docker Swarm” https://jelastic.com/blog/docker-swarm-auto-clustering-and-s.... An advantage here is the vertical scaling feature. In Jelastic unused resources will not be considered as paid while at any other cloud provider you will have to pay for the VM resource limits.

2) Enhanced System Containers based on Dockerfile - there is no need to provision a dedicated docker engine or swarm. This solution provides even better density, elasticity, multi-tenancy and security, more advanced integration with UI and PaaS features set compared to #1. It supports multiple processes inside a single container, you can get an SSH access and use all standard tools for app deployment, write to local filesystem, use multicast and so on. It supports traditional or legacy apps while images can be prepared in the same familiar Dockefile format. Unfortunately it's not fully compatible with Native Docker Engine due to specifics limitations/requirements of docker technology itself. Thank you for pointing out this issue. In the upcoming release we will clarify the difference between two and provide more tips which one is better to use in various cases.

Re: When AWS Autoscale Doesn’t

#85

Post by RuslanSJ »

etaioinshrdlu wrote: post #53
tyingq wrote: post #5

Vertical autoscale is on my wish list. Some way to automatically scale instance size for those things that don't scale well horizontally.

Jelastic claims to do this, and the marketing made it sound so cool. https://jelastic.com/ But when I tried it, it turns out the docker support requires very specific base images. Not really docker then is it?!?

Hi, Jelastic founder is here. Thank you for mentioning our product. Vertical scaling is not a marketing :), it's reality.

Jelastic public cloud providers offer automatic vertical scaling with pay-as-you-use billing model (please do not confuse with pay-as-you-go). Except this our team helps related technologies to become more elastic, for example Java https://jelastic.com/blog/elastic-jvm-vertical-scaling/

Regarding the docker support, there are two flavors inside Jelastic: 1) Native Docker Engine - you can create a dedicated container engine for your project in the same way as you do on any IaaS today, for example “How to run Docker Swarm” https://jelastic.com/blog/docker-swarm-auto-clustering-and-s.... An advantage here is the vertical scaling feature. In Jelastic unused resources will not be considered as paid while at any other cloud provider you will have to pay for the VM resource limits.

2) Enhanced System Containers based on Dockerfile - there is no need to provision a dedicated docker engine or swarm. This solution provides even better density, elasticity, multi-tenancy and security, more advanced integration with UI and PaaS features set compared to #1. It supports multiple processes inside a single container, you can get an SSH access and use all standard tools for app deployment, write to local filesystem, use multicast and so on. It supports traditional or legacy apps while images can be prepared in the same familiar Dockefile format. Unfortunately it's not fully compatible with Native Docker Engine due to specifics limitations/requirements of docker technology itself.

Thank you for pointing out this issue. In the upcoming release we will clarify the difference between two and provide more tips which one is better to use in various cases.

Re: When AWS Autoscale Doesn’t

#86

Post by icelancer »

zepolen wrote: post #79
icelancer wrote: post #64

Earlier quoted context omitted.

> That's not the right way to do it. The poster is aware of this, which is why they talked specifically what they did wrong.

While the poster was aware of it, he did not provide a solution whereas DVassallo provided a valuable step by step on how to do it properly. Which may help others in the future. Think long and hard why you felt it necessary to make your comment and what value it actually provided.

> Think long and hard why you felt it necessary to make your comment and what value it actually provided.

Yeah, that's what I was telling the other poster in a nicer way. Same goes to you. You can provide advice without repeating criticism for no reason when the person specifically said they did something wrong.

And save me the lecturing on "long and hard." My comment has 15 upvotes, so it's pretty unlikely I'm the one off the mark in this conversation.

Re: When AWS Autoscale Doesn’t

#87

Post by risaacs99 »

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.

Disagree. We've been running on ECS for years and it's a very economical and reliable way to run containers on AWS. The service itself is free, the agent over time has become very reliable, and the integrations with AWS services like ELB, and CloudMap are seamless.

It's significantly more complex to host kubernetes infrastructure, and EKS is significantly more expensive.

ECS would be a first choice, with EKS a second choice if my needs dictated it (perhaps a hybrid or milticloud scenario).

Re: When AWS Autoscale Doesn’t

#88

Post by mnutt »

The biggest challenges I’ve had with auto scaling have been slow scaling time and default metrics not being a good proxy for scaling needs. One thing I was mildly curious about: if you’re going to build your own metrics and scaler, what would be some of the downsides of having it scale down by just putting instances in the Stopped state, then scale up by starting them? In my experience starting takes seconds while launching new instances takes minutes.

Having to deploy updates to stopped instances would be complicated and you’d have to pay EBS costs for stopped instances, but I’m curious if there are other issues. Launching an instance from an AMI, even after the instance comes up the disk tends to be very slow for some time as if it’s lazily loading the filesystem over the network.

Re: When AWS Autoscale Doesn’t

#89

Post by takeda »

eunoia wrote: post #11
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?

Fargate is orthogonal to ECS and can be used together. The difference is that instead spinning VMs as hosts and configuring them for ECS and worrying about spinning just right amount of them, you select fargate, which does all of that behind the scenes (kind of like lambda), but the VM instances provided by fargate are a bit more expensive.

Re: When AWS Autoscale Doesn’t

#90

Post by etaioinshrdlu »

RuslanSJ wrote: post #85
etaioinshrdlu wrote: post #53

Earlier quoted context omitted.

Jelastic claims to do this, and the marketing made it sound so cool. https://jelastic.com/ But when I tried it, it turns out the docker support requires very specific base images. Not really docker then is it?!?

Hi, Jelastic founder is here. Thank you for mentioning our product. Vertical scaling is not a marketing :), it's reality. Jelastic public cloud providers offer automatic vertical scaling with pay-as-you-use billing model (please do not confuse with pay-as-you-go). Except this our team helps related technologies to become more elastic, for example Java https://jelastic.com/blog/elastic-jvm-vertical-scaling/ Regarding…

Regarding 1: Any easy set up guide for native mode?

Regarding 2: Is there any fundamental reason why full compatibility will never work?

Post reply on HN