Live data from Hacker News

Under the Hood of Amazon EC2 Container Service

allthingsdistributed.com

11–20 of 36 posts

Re: Under the Hood of Amazon EC2 Container Service

#13
post #7
post #6

Earlier quoted context omitted.

What are some other examples. In general consistent vs available (or neither, that's possible too of course) is a trade-off and you'd want to pick one vs other depending on your business case.

I know I'm bound to be proved wrong here, but I think _every_ product after the original set (EC2, S3, SimpleDB) has been consistent or now has a consistency option: the major ones are RDS, EBS, EFS, DynamoDB, RedShift, Elasticache, Route53, Kinesis, SES. Some of those APIs are sort of odd, admittedly, and could be covering up eventual consistency under the covers (Route53 in particular springs to mind there!) Edit:…

DynamoDB encourages eventual consistency by charging .5 for each read capacity unit consumed on an eventually consistent read.

Re: Under the Hood of Amazon EC2 Container Service

#14
post #13
post #7

Earlier quoted context omitted.

I know I'm bound to be proved wrong here, but I think _every_ product after the original set (EC2, S3, SimpleDB) has been consistent or now has a consistency option: the major ones are RDS, EBS, EFS, DynamoDB, RedShift, Elasticache, Route53, Kinesis, SES. Some of those APIs are sort of odd, admittedly, and could be covering up eventual consistency under the covers (Route53 in particular springs to mind there!) Edit:…

DynamoDB encourages eventual consistency by charging .5 for each read capacity unit consumed on an eventually consistent read.

I consider consistency a bargain at twice the price :-)

Re: Under the Hood of Amazon EC2 Container Service

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

Re: Under the Hood of Amazon EC2 Container Service

#16

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…

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.

Re: Under the Hood of Amazon EC2 Container Service

#18
post #5
post #4

Earlier quoted context omitted.

I don't know, S3 and DynamoDB are both eventual consistent. And keeping in mind the CAP-theorem it makes sense. And I for one love SimpleDB - it's just that, simple. And great for prototyping (really cheap) and small production-loads. Often you just need a place to stick your data, scalability can be achieved to adding a caching layer.

They have actually been making S3 _more_ consistent over time: in the newer regions you get e.g. read-your-writes for object creation. DynamoDB also supports consistency, though still defaults to eventual consistency if you prefer. In my mind, there's definitely a trend towards consistency here. I'd love to see an AWS blog post about the reasons behind this!

US Standard now provides read-after-write consistency when accessed through the Northern Virginia endpoint [1].

[1] http://aws.amazon.com/s3/faqs/#What_data_consistency_model_d...

Re: Under the Hood of Amazon EC2 Container Service

#19

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…

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

Re: Under the Hood of Amazon EC2 Container Service

#20
post #19

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…

> Right now - you have to manually [...] scale the ASG. You have to manually scale the AutoScaling Group, you say? :-) More seriously, what's the barrier to configuring the ASG to grow and shrink automatically?

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

Post reply on HN