Overivew
We all know that EKS is in many ways considered the darling of the container world in AWS, and there are of course some good reasons gor this. Kubernetes has been a big deal for a while in the industry, and there is of course the idea that if you learn how to manage EKS, you can also pick up Kubernetes platforms in other environments fairly easily too. Or, bring your Kubernetes knowledge to AWS.
There is absolutely nothing wrong with that, but that doesn't mean that ECS doesn't have a place, and in many cases, is can remain the better option.
Below, we will look at where ECS might just be a better choice.
What is ECS?
ECS, like EKS, is a container system. If you want to run your containers (Linux or Windows), you need to run them on a container system, and ECS is one of those.
One of the big advantages of containers is that they are portable, and when you move them from one environment to another (say, from your laptop to the cloud), they should run consistently. They might perform differently of course, but because of container architecture, you are not going to run into the dreaded "well, it worked on my machine" issue. Although this might not solve all of your problems!
(Before devops / after devops, by Daniel Stori, licenced under CC BY-NC-SA 4.0)
Containers are also very efficient, allowing for higher density on the same hardware compared to traditional virtualization (VMware, Hyper-V, etc.)
But, management challenges can remain. With traditional virtualization, you need to manage the VMs and the hypervisor, which hosts the VMs. Within containers, you still need to manage that underlying layer.
That is where ECS comes in. What ECS does, is allow you to concentrate on the containers, and not the underlying environment that hosts the containers, and it does this by doing the bulk of the environmental management for you. With ECS, the control plane is fully managed.
Amazon themselves use ECS to run their own services. Amazon RDS, Redshift, and SageMaker are just some of the services that run on ECS.
Supported ECS Environments
So where can we run containers with ECS? With ECS, you get the flexibility to run on:
- EC2
- Fargate
- Edge and 5G
- ECS Anywhere
That is comparable to the EKS offering, and gives you enormous flexibilty in choosing how you want to run your containers.
The last one in particular is worth calling out. ECS Anywhere, allows you to use the same single control plane across your own hosts (yes, in your own DC, office, or even home if you are doing this for fun!).
If you go back two years, a significant majority of new customers at AWS were using ECS for their containers. It has an established pedigree, and if you talk to your AWS representative to get a list customers who use ECS, you will see some enormous and established names there. The pedigree, and flexibility that ECS offers are major contributors to that.
Scaling
An important element of any container platform is the abililty to scale.
ECS can support launching more than 500 tasks/min (a task defines one or more containers that comprise your application, and details the resource requirements for those), whether on EC2, or Fargate. For the majority of use cases, that is a staggering amount of scaling.
A task is a fairly key element here because understanding tasks, and how they relate to your application will help in optimising scaling. If you are using EC2 for ECS, you can define your own Capacity Providers, to give you a lot of flexibility in scaling. The Capacity Provider will handing task launches and scaling.
Basically, ECS is going to all the hard work on scaling for you. If you were to use EKS, you will need to look at elements such as an HPA to perform horizontal scaling, and also configure the HPA.
What is AKS?
AKS is AWS's platform for to allow for Kubernetes environments to run on AWS. As it designed to be managed like any other Kubernetes environment, the elements are quite different form what you will have in ECS, and required knowledge of Kubernetes to deploy and manage.
Differences Between ECS and EKS
Kubernetes (K8s), Docker Swarm, and ECS are all orchestrators that handle the management (orchestration) of your containers.
Unlike K8s, ECS is proprietary.
With ECS, when you create the cluster, ECS will start/stop, deploy/destroy container in your cluster (via the ECS Control Plane). You still need to manage your nodes (for example EC2 instance) yourself though, and will need to configure your ECS agent to allow ECS to manage those. If you use Fargate, a lot of that pain goes away, as it is a Serverless architecture (server resources are created/managed on demand without your intervention). Fargate allows a much more "hands off" approach.
If you were to deploy K8s on AWS, you would need to create the control plane manually, install your management services (API Server, Scheduler, Controller Manager, etc.) yourself, and then provision your worker nodes, that will run your containers. And on your worker nodes, you would need to install your worker processes (kubelet, kube-proxy, container runtime). Running K8S this way has a much higher overhead compared to ECS.
Alternatively, you can use EKS. At that point AWS manages the control plane processes, and handles scaling for you. This is an experince much closer to ECS. A key advantage here of both ECS and EKS compared to building your own Kubernetes environment from scratch is that all of the control plane security is handled by AWS, meaning that a significant responsibilty is taken away from you. EKS doesn't manage the worker nodes themselves those. You will still need to manage those, which means creating the EC2 nodes, configuring them, installing worker node processes, patching them, etc.
You can push back some of that worker node responsibility back to AWS using EKS Managed Node Groups. In that case, AWS will manage the provisioning of the EC2 nodes, and they will run an EKS optimised image. Things like creating or updating nodes is still your responsibilty, but some of the complexity is abstracted from you, leaving you will an easier set of commands to use.
You also have Fargate on EKS, which is very similar to ECS. If you use this, AWS will be responsible for your worker nodes so you don't need to provision them, you don't need to maintain them.
Really though, one of the main differences between the two is the way they are accessed for management. ECS is AWS specific, so the APIs used to manage ECS only apply to ECS. EKS however is largely open sourced, and many of the APIs requests would apply to other Kubernetes platforms. This means that it should be easier to move an application to another platform, in theory. It is worth noting though, that this isn't quite as straight-forward as people might think, and if you are using other cloud specific services (ACM, DynamoDB, etc.) it definitely won't be as easy as just moving your images.
So ECS is more closely tied to AWS, however, it is generally less complex and easier to onboard too. Kubernetes is going to be another technology to learn (on top of simply containers), which can require a significant investment in time to really get to grips with. This doesn't meamn it can't be done, there is fantastic support out there, but if you are moving a critical system to containers, how confident are you in Kubernetes, not when it is running well, but when it is running badly? So unless you have a significant amount of experience with Kubernetes, ECS still remains a less complex platform to work with. You also don't pay for the control plane and worker nodes, like you do with EKS.
Which Should I Choose Then?
Given the scales that ECS can offer (just think about who many AWS services you use, which run on ECS under the hood), there is really no performance or scale reason to not go with ECS.
EKS is probably a better choice if you really need multi-cloud (or hybrid-cloud), and so are not using other cloud native services, or looking to migrate away from those too. That could be something that financial institutions need to consider to avoid vendor lock-in. Additionally, if you either already have the skills and experience with Kubernetes, or you have the time and resources available to invest in up-skilling in Kubernetes, EKS could be a sensible choice because of the wide adoption.
ECS should however, in my opinion, still be the default choice for the majority of customers because of the easier configuration and management, which leads to faster "time to market", easier support. And one of the driving factors is moving to the cloud is so allow a cloud provider to do the "undifferentiated heavy lifting". By letting AWS manage more of your underlying infrastructure, isn't that what you are doing by choosing ECS? You remove all the complexity around namespaces, nodegroups, scaling, etc.
Just as importantly of course, ECS is going to be cheaper to run.
So ECS should be the default choice. Then consider EKS, if ECS isn't going to meet a specific business or technical requirement.
comments powered by Disqus