Containers require to be managed throughout their lifecycle. Market is filled with products that are aimed at container orchestration from dedicated solutions like Kubernetes, Rancher, OpenShift, Container as a Service platforms like Amazon Elastic Container Service (ECS), provider-specific implementations such as Azure Kubernetes Service (AKS), and Elastic Kubernetes Service (EKS) to lightweight orchestrators like Docker Swarm or HashiCorp Nomad.
All these different platforms come with their unique advantages and disadvantages. Amazon itself offers a whole host of container management services and associated tools from the above-mentioned ECS, EKS to AWS Fargate, and the newest option EKS Anywhere. As such AWS users need to carefully evaluate these before committing to a specific service to host our containers.
What is Container Management?
A container is a lightweight, stand-alone, and portable executable package that includes everything that is needed to run the application from the application itself to all configurations, dependencies, system libraries, etc.…. This can simplify the development and deployment of applications, however, to we need some other additional resources and configurations to successfully run the containers.
An executable environment with CPU, RAM, and storage resources.
Networking to communicate between containers, other services, and the wider internet.
Manage scalability, fault-tolerance and availability of containers.
Storage, Caching, APIs, other external services
Monitoring capabilities for metrics, application and system logs, security.
While containers encapsulate the application itself the container management or an orchestration platform provides the rest of these functions throughout the container’s lifecycle.
ECS and EKS are the primary offerings by AWS that aim to provide this container management functionality. In the following sections, we will look at what exactly these two offerings bring to the table.
What is Amazon Elastic Container Service (ECS)?
The Elastic Container Service can be construed as a simplified version of Kubernetes but this is misleading. The Elastic Container Service is an AWS-opinionated fully managed container orchestration service. ECS is built with simplicity in mind without sacrificing management features and easily integrates with AWS services such as AWS Application/Network load balancers, CloudWatch, etc…
How Amazon Elastic Container Service works is to use its scheduler to determine where a container is run, the number of copies started, and how resources are allocated. As shown in the following image ECS follows a simple easily understood model. Each application in your stack (API, Thumb, Web) is defined as a service in ECS and schedules (runs) tasks (instances) on one or more underlying hosts that meet the resource requirements defined for each service.
As this closely resembles a traditional server-based implementation, it is rather simple to understand and implement for containerized workloads. Thus, migrating applications to ECS becomes a simple task that only requires the containerized application, pushing the container image to the Amazon Elastic Container Repository (ECR) and then defining the service to run the image in ECS. Most teams can easily adapt to such a workflow. ECS also provides simple yet functional management and monitoring tools that are situated for most needs.
What is Elastic Kubernetes Service (EKS)?
The Elastic Kubernetes Service is essentially a fully managed Kubernetes Cluster. The primary difference between ECS and EKS is how they manage services such as networking and support components. ECS relies on AWS-provided services like ALB, Route53, etc… EKS manages all these mechanisms internally just as in any old Kubernetes Cluster. The Elastic Kubernetes Service provides all the features and flexibility of Kubernetes while benefiting from the managed nature of the service. However, all this comes with an increase in the complexity of the overall application architecture.
When deploying containers while ECS directly uses individual containers EKS introduces the Kubernetes concept of Pods to deploy and manage containers. Pods can contain either one or more containers with a shared resource pool and provide far more flexibility and fine-grained control over components within a service. If we look at the below image, we can see that all the services (ex: proxy, service discovery) that need to run containers are within the Kubernetes cluster.
Let us assume that our Thumb service was a combination of three separate components. A microservice API, image processor, and a storage engine. With Kubernetes, we can run these three separate components as distinct containers within a single Pod that makes up the Thumb service.
Containers within the pods run collocated with one another and they have easy access to each other and can share resources like storage without relying on complex configurations or external services. All this leads to EKS allowing users to create more complex applications architectures. Also, EKS enables users to tap into the wider Kubernetes echo-system and use add-ons like the networking policy provider Calico, Romana Layer 3 networking solution, CoreDNS flexible DNS service, and many other third-party add-on and integrations. As EKS is based on Kubernetes this gives users the flexibility to move their workloads between different Kubernetes clusters without having to be vendor locked into a specific provider or platform.
How does Fargate Affect all This?
Even with managed services, servers still exist, and users can decide which types of computer options to use in ECS or EKS. AWS Fargate is a serverless, pay-as-you-go compute engine without managing servers. This means that AWS takes over the management of the underlying server. Instead of users creating a server, installing software, and keeping it up to date, With AWS Fargate you only need to create a cluster and add a workload and AWS will automatically add pre-configured servers that match your workload requirements.
Fargate is the better solution in most cases. This should cost no more than self-managed servers and most of the time offers cost savings as Fargate only charges for the exact usage without needing to worry about unused capacity in self-managed servers which require manually shutting down to get cost savings. However, some notable exceptions for Fargate use are.
Highly regulated environments with strict security and compliance requirements will not be able to use Fargate as they lose access to the underlying servers. Which users might need control over to meet stringent regulatory requirements. Also, Fargate does not support “dedicated tenancy” hosting requirements.
ECS and Fargate only support AWS VPC networking mode. Which may not be suitable if deep control over the networking layer is required.
As Fargate automatically allocates resources depending on the workload with limited control over the exact mechanism. This can lead to unexpected cost increases, especially in R&D environments where many workloads are evaluated. Self-managed servers with capacity limitations will be a better solution in these scenarios.
What about EKS Anywhere?
EKS Anywhere extends the functionality of EKS by allowing users to create and operate Kubernetes clusters on customer-managed infrastructure with default configurations while providing the tools necessary to manage the cluster using the EKS console. This builds upon the Amazon EKS Distro and provides all the necessary and up-to-date software which resides on your infrastructure and gives a far more reliable Kubernetes platform compared to a fully self-managed Kubernetes cluster.
This is a great option to power hybrid cloud architecture while still having operational consistency between the cloud and on-premises. Also when data sovereignty is a primary concern EKS Anywhere provides the ideal solution to keep data with on-premise infrastructure while leveraging AWS to manage the application architect and delivery.
Which Platform is Right for You?
EKS is undoubtedly the more powerful platform, but that does not mean EKS is the de facto choice for any workload. ECS simplicity combined with its feature set still is a suitable choice for many workloads.
ECS is much simpler to get started with a much lower learning curve. Small organizations or teams with limited resources will find ECS the better option to manage their container workloads compared to the overhead associated with Kubernetes.
The tighter AWS integration allows users to use already familiar resources like ALB, NLB, Route 53, etc. to manage the application architectures that help them to quickly get up and running.
ECS can be the steppingstone for Kubernetes. Other than trying to adapt EKS at one user can use ECS to implement a containerization strategy and move its workloads to a managed service with less up-front investment.
On the other hand, ECS can sometimes be too simple with limited configuration options. This is where EKS shines. EKS offers far more features and integrations to build and manage workloads at any scale.
Pods may not be required for many workloads however Pods offer unparalleled control over pod placement and resource sharing. This can be invaluable when dealing with most service-based architectures.
With the flexibility to run on EC2, Fargate, and even on-premises via EKS Anywhere, EKS offers far more flexibility when managing the underlying resources.
Ability to use any public and private container repositories.
ECS monitoring and management tools are limited to the ones provided by AWS. These are sufficient for most use cases, however EKS allows for greater management and monitoring capabilities both via inbuilt Kubernetes tools and readily available external integrations.
Overall, it comes down to specific user needs. Both options have their pros and cons. Each will be the right choice for different workloads. But to sum all this If you know Kubernetes and want to have the flexibility and features this provides go with EKS, but you want a simpler solution or just starting up with containers try ECS first.