Schedule a chat

Elastic Beanstalk vs. ECS vs. Kubernetes: Part 2

Mar 23, 2017

This is Part 2 of Elastic Beanstalk vs. ECS vs. Kubernetes, see Part 1

ECS (Elastic Container Service)

ECS is Amazon’s answer to container orchestration. It’s a bit rough around the edges and definitely a leap from Elastic Beanstalk, but it does have the advantage of significantly more flexibility including the ability to even define a custom scheduler.

All of the limitations imposed by Elastic Beanstalk are lifted.

But, so is the simplified interface and the ease of deploying applications onto the cluster. Seemingly simple actions like deploying a new version of a Docker image requires a more carefully planned procedure. Because the new version of a container must be up and running before the old version is terminated, it’s easy to run into capacity problems where your instances don’t have sufficient resources for both the new version and old version to run side-by-side. In this case you’re forced to temporarily reduce the desired number of containers for that service, allowing autoscaling to kick in and terminate one, which then allows the new container to launch in it’s place and slowly roll out to your cluster. Once completed, you need to return your desired number of containers back to where it should be.

Granted this scenario won’t always happpen, and there are some other ways to avoid this by setting up CloudWatch metrics to autoscale the cluster when events like these occur. However, more sane defaults and simple configuration options that would allow a container to be terminated before its replacement is launched could solve some immediate usability issues that both myself and others have experienced early on with ECS.

ECS does have a straightforward approach to declaratively defining containers which allows you to easily compose several “container definitions” within a “task definition”. An ECS task is the primary unit of container orchestration that you use to launch containers. Each task includes one or more container definitions, allowing you to group containers together into a logical set that’s launched and terminated at the same time.

Finally, services are used to wrap tasks in definitions that also define load balancers, desired task counts, and health-related thresholds that should be maintained. The service –> task –> container topology is easy to follow, but creating initial service definitions, task definitions, and container definitions that offer sane defaults is still a bit of a challenge. As of this writing, creating a load balanced service is still a bit of a juggling act, and managing a multitude of task definitions with ever growing revisions that can’t be deleted or cleaned up is a hassle.

Still, ECS is a powerful platform and offers a good deal of flexibility.

Continue to Part 3: Kubernetes