Uncovering our values, with a dash of spirituality
2020-04-28
ECS or EKS: a decision that many teams face when looking for a container orchestrator platform on AWS. We’ve done our best to list the most important similarities and differences here. Feel free to add your comments if you think we forgot some!
Although we’re comparing ECS and EKS as the two AWS managed container orchestrator solutions, most of the “EKS characteristics” talked about refer to Kubernetes in general, with some additions that AWS brings in with EKS. For those new to these topics, check out our knowledgebase where we share the basic definitions and explanations.
Both ECS and EKS are AWS managed services. Thus the control plane is abstracted from us, and we don’t have any control nor visibility on the underlying instances that run those control planes.
Both platforms are container orchestrators. As you would expect from a container orchestrator, both platforms have simple built-in container monitoring. Both platforms restart your containers when they stop working correctly or when they exceed their capacity limits. They also allow you to specify some resource constraints (like CPU and memory) to your containers, which allows for more informed scheduling and resource management.
It’s the user’s responsibility to run the cluster workers, both for ECS and EKS. To make it easier and simplify that task, AWS offers pre-built AMIs to run the cluster workers for both ECS and EKS.
AWS Fargate , which lets you run your containers without the need to manage workers, was first launched with support for only ECS. But recently, AWS announced support for EKS clusters as well at last re:Invent .
The ECS control plane is free of charge, regardless of how many clusters you run.
The EKS control plane has an hour based pricing, just like most AWS compute resources. Good news though, as recently AWS announced a price decrease: it’s now $0.10/hour/cluster, which translates to around $72 per month for a 24/7 running cluster, making the cost for production workloads negligable.
While both ECS and EKS are AWS-specific services, Kubernetes-as-a-platform can be used with any cloud provider and on-premise. By using a managed Kubernetes service like EKS, you’re still investing in a cloud-agnostic platform, both in terms of tech and expertise.
All of your applications and services can run on any other Kubernetes cluster, with little to no changes. Bonus: the skills you and your colleagues develop are more broadly usable. ECS, on the other hand, is an AWS proprietary service. By using it as your central container platform, you’re committed to a proprietary container platform.
ECS gives you some built-in integrations with AWS services. For example, it automatically manages targets on an existing load balancer, depending on where your containers are running, but you’re still responsible for setting up the actual load balancer. ECS will also automatically forward your container logs to CloudWatch Logs, given that you configure your service to do so.
Kubernetes, on the other hand, doesn’t have that level of integration out of the box yet. However, it’s our experience that with little to no effort, you are able to achieve the same or greater level of integration than ECS. Some examples of how we handle that at Skyscrapers:
It’s our belief, based on these best practises as well as on the AWS container public roadmap , that over time, AWS will keep on investing in stronger integrations. We even expect EKS to get more attention compared to ECS in the near future.
Kubernetes has the added benefit of offering stronger abstraction to your workloads. That means that you’ll be able to achieve the same level of integration with any other cloud provider, with little to no effort, if you choose to run your platform multi-cloud.
As ECS is so tightly integrated with AWS and its services, it also demands tight integration between the operations and developer roles in your team. For example, if your developer team wants to deploy a new service in ECS, you’ll probably need to create a new load balancer or provision some EBS volumes. That can create friction and inefficiencies in your teams slowing down innovation.
This is different with Kubernetes as it offers a higher level of abstraction and automation. Your developers communicate with the K8s API to deploy their applications and it’s the cluster that (if correctly setup) provides the needed underlying resources. Similarly for your operations team, they can focus on setting up, maintaining and upgrading the cluster as needed.
Contrary to ECS, Kubernetes has the “ namespaces “ concept, which is a feature intended to isolate workloads running in the same cluster. This seems like an insignificant feature but it offers a lot of advantages. For example, you could have staging and production namespaces running in the same cluster while sharing resources across environments, reducing spare capacity in your clusters.
And that’s just one of the many advantages this offers and just one of the advanced features that can drive innovation.
A vital characteristic of any platform, framework, software or coding language you choose for your projects is the community support and available resources. In this regard, Kubernetes is way more widespread than ECS, given its multi-platform support.
Kubernetes is an open-source platform with a large and ever-growing community behind. That brings apparent advantages:
On the other hand, being proprietary, ECS gets less community-based support, although you’ll have excellent corporate support from AWS.
From an operations standpoint, compared to Kubernetes, ECS is a more straightforward platform. It doesn’t have as many moving parts, components and functionality as K8s does. With ECS, AWS targets basic workloads with simple architectures, that need just some CPU and memory to run and won’t evolve all that much over time. ECS comes with better AWS integration out of the box and it requires limited maintenance.
Kubernetes requires more skilled hands to operate to high standards and following best practices to enjoy all the benefits it offers. However, in our experience, ECS quickly becomes too limiting when the application starts to grow in complexity and size. So you need to understand the growth expectations of your project before making the initial decision of which platform to choose. Most SaaS workloads we’ve come across quickly outgrow ECS.
After considering all the above, we ended up with a reasonably easy decision to make:
“Kubernetes is the more future-proof and versatile approach.”
ECS certainly has its advantages. The free control plane is one. However, relative to the total cost of a typical SaaS workload, the $ 72/month of the EKS control plane shouldn’t make a big difference.
Another advantage of ECS is the initial simplicity in terms of setup, integration and operations. However, those quickly become limitations once your SaaS grows, becomes more demanding and you want to start exploring ways to innovate faster, just like almost every successful SaaS business does.
At Skyscrapers, we can help you bridge that gap with our offering and services. We leverage our expertise and knowledge to offer our customers with a ready to use Kubernetes platform, fully maintained and monitored, that already follows best practices and has all the needed add-ons deployed. That way, our customers only need to focus on their application and can scale their business at their own pace.
Do reach out with comments, experiences and questions! We love to share and learn!
Need a solid go-to partner to discuss your DevOps strategy?
