[samstave]

The biggest issue that I had with ECS is that you need to initially create EC2 instances to put into your ECS cluster, using the AMI such that they have the ECS agent on them... BUT you have to prescale that cluster manually thereafter.

In the task definition - it would be MUCH better if you could select the EC2 instance type you want, collect them in an ASG and have the task slicing scale the ASG accordingly.

Right now - you have to manually determine the slice size for each container-to-EC2 and manually scale the ASG.

Further, it was noted that ECS is actually NOT AZ aware and it will spread load over EC2 instances in the pool -- but it wont also balance the tasks across AZs....

So, its a fantastic version one... but these are some resiliency and scaling features that should have already been included.

[werner]

Nope, we have built a new scheduler for you that will allow placement over multiple AZ's, replace failed containers, allow them to connect to ELB's, etc.

[2461001642]

Thanks for responding! Can you say how you deal with the significant latencies over multiple AZs?

Also, would you mind answering my other question about whether or not I can run Marathon or Chronos against ECS since it runs Mesos under the hood?

[werner]

Can you elaborate on the intra- inter-* latencies your are seeing? for AZ independent services this should single digits.

[2461001642]

When I'm balancing a single deployment across multiple AZs (e.g. US-East -> US-West), the latencies between the containers seem far higher than just the 200-300ms predicted by speed of light. Am I doing something wrong?

[werner]

No mesos under the hood. You can bring mesos as your own scheduler.

[2461001642]

Thanks again - this is really helpful. I had talked to someone who had left Amazon but knew the internal workings who said ECS was Mesos just privately branded like Chef -> OpsWorks, but I guess I must have misunderstood.

Thanks for clarifying!

[samstave]

Thanks - All my info is from the containerization pop-up you guys held last week in SF... The presenters did not seem to know about this.

[nogox]

check out hyper.sh, this is the future of public CaaS. After all, you don't need EC2 to host your containers, if you can run them directly with a hypervisor.

[osipov]

I've been using IBM Container Service. They have Docker containers running on bare metal servers with a free tier and a trial account for 30 days. With respect to clusters, you can set up a scalable group with min/max sizes and they'll take care of routing across the containers in the group.

[nogox]

How do they handle the isolation in a multi-tenant environment?

[Pyxl101]

> Right now - you have to manually [...] scale the ASG.

You have to manually scale the AutoScalingGroup, you say? :-)

More seriously, what's the barrier to configuring the ASG to grow and shrink automatically?

[samstave]

Heh, yeah basically you can create an asg, but ecs has no trigger to scale it based on the number of task containers you attempt to launch on the cluster....

There is a workaround, apparently, which is to create a custom metric but aws says this has not been tested to their knowledge... So any asg will be "static" implicitly...

[djb_hackernews]

That is definitely inaccurate. We have asgs that scale based on cpu load and custom cloudwatch metrics.

With ecs I can imagine a metric that keeps track of the number of tasks and hosts, or ports used or something. I think asg is the perfect tool to use to auto scale ecs clusters.

[samstave]

Ah, true... you could create custom metrics to trigger on... I was mentioning from the native ECS standpoint...

Also - all my information is only from the one day container session I attended at the pop-up last week... so I am certainly not an SME on ECS.