When it comes to container orchestration, Kubernetes has become the de-facto standard for managing and running containerized workloads in production. “Openness” is one of the main reasons why Kubernetes has leapfrogged the competition, primarily driven by its open source roots. Kubernetes brings a thriving open source ecosystem that takes advantage of the platform’s modular design. Almost every cloud provider has integrated the software as a native service, establishing a new category known as “Managed Kubernetes”. The big players include AWS Elastic Kubernetes Service (EKS), Azure Kubernetes Service (AKS), and Google Cloud’s Kubernetes Engine (GKE) offering.
However, some cloud providers like AWS offer additional container orchestration options. Amazon’s Elastic Container Service (ECS) is one example, and it’s native to the AWS platform. In this post, we’ll shed some light on the pros/cons of ECS, Kubernetes, and recommended approaches.
AWS ECS comes in two flavors: ECS powered by Fargate, and ECS powered by EC2.
Traditional ECS - powered by Amazon EC2 compute - was launched in 2015 as a way to easily run Docker containers on the cloud. Traditional ECS gives you underlying control over the EC2 compute options for your containers. This flexibility means you can select the instance types to run your workloads on. It also hooks you into other AWS services used for monitoring and logging activity on those EC2 instances.
Fargate, on the other hand, was released in 2017 as a way to run containers without having to manage the underlying EC2 compute. Instead, Fargate automatically calculates the desired CPU and memory requirements. Fargate is usually a good option if you need to get a workload up and running quickly and don’t want to bother calculating or figuring out the underlying compute options.
When comparing the two services, traditional ECS offers the most flexibility. One possible migration path is starting on Fargate and then moving to traditional ECS when you need more operational agility.
That said, most companies have a growing application and service footprint, driven by product roadmaps and customer requests. In these situations, it’s possible to outgrow ECS for your container orchestration needs. Consider the following business situations:
For example, the Fargate service can have slow launch times, mostly because you’re leaving the compute decisions to Amazon in favor of a more simplified operational experience.
It’s perfectly fine to start out on ECS when you have a small number of services, but ensure you have an exit plan to another PaaS, like EKS or Kubernetes, when you need flexibility and control.
If any of the above situations are relevant to you, then consider a strategy for graduating from ECS to a more modern platform like Kubernetes. Learn more about the benefits of Kubernetes and options for moving away from ECS in our next post: The Benefits of Managed Kubernetes vs. Amazon ECS