Today I had a pleasure to participate in AWS Summit 2015 in Berlin. Because of the ongoing hype with regards to Docker and not-so-long-ago-announced ECS service I was considering talking with AWS Architects about those two as one of my main objectives. There was also a session about automation of docker deployments inside a ECS which gave me quite nice overview of capabilities. So….

My thoughts after the event are:

In general ECS is nice, it gives you quite decent flexibility of fleet management, fits well with deploy/upgrade pipeline, has a quite broad autoscaling capabilities and everything would be perfect except theres’s one small detail which destroys this nice picture.

Currently you need to define fixed ports which are exposed on docker and host. Thinking about docker upgrade on one instance, either you use different ports for publishing exposed ones or you shutdown old container and start a new one in place of old. When you use ELB this leads to a situation where 0 downtime deployments are not available, because in the first scenario there will be downtime between ELB discovering the node and deciding on it’s health after changing ports, and in the second scenario there’s a downtime caused by lack of any container running. Of course I’ve a manually triggered deployment in mind.

ECS is using the second option to roll deployments. This means that service will stop the old container and in that place will start a new one.

So at least for now, until ELB does not support dynamic port allocation in ECS (hopefully it will change soon enough) it’s better to go with a 1 docker : 1 ec2  instance workflow with standard ELB connected autoscaling groups.