AWS EKS, ECS and Fargate: Understanding the Differences

It is 2018. Most businesses are using containers, some still hesitate to adapt, but who hasn’t heard of containers? Really, containers are not new technology, in fact, they are old technology. A brief summary can be found here, but BSD Jails, Solaris Zones and the like, are nearly a decade old. Docker took this concept in the wave of cloud computing and really brought it front and center. AWS has put out several options for managing this, and we will finally allow the smackdown to occur; who is the best in an EKS vs. ECS vs. Fargate matchup?

But why are containers so popular? It’s simple. If you’re in the cloud, you’re already invested in virtual machines, that is, segmenting bare metal resources into provisioned, separate operating systems. You’re getting more out of less. Containers take that to the next level by isolating a workload upon an OS and exposing only what is necessary. It’s application (or workload) level virtualization.

Docker’s initial release was in 2013 at PyCon. It was a smashing success, it’s no wonder that only a year later, AWS released, at the 2014 re:invent, AWS EC2 Container Services (ECS)—now called Elastic Container Service. AWS wanted in on the market immediately, and they got in much faster than Azure Container Service (ACS) and Google’s container service (despite Google itself being a major container user). The ECS offering had a rocky start but it has garnered much wider adoption with increased features and the additional launch type—Fargate.

As of 2014, Google claimed everything at Google ran on a container. Even though the majority of its containers weren’t on Docker, Docker’s meteoric rise likely brought on the need to manage containers using a massive Enterprise approach-insert Kubernetes. Conversely, Kubernetes adoption as a service was not the same. Google creating Kubernetes could be considered ingenuity born from necessity. Now, it is the new “in” technology and SRE and DevOps shops are clamoring to integrate Kubernetes, if they haven’t already placed workloads on the open-source container scheduling framework.

Unlike Docker as a service adoption, Kubernetes as a service was adapted in reverse order. Google, the creator, offered it first. Then Azure Kubernetes Service (AKS—part of ACS) launched in late 2017. Even though AWS Elastic Kubernetes Service (EKS) was announced at the 2017 re:invent, it is only nearing launch. With it, the three titans will battle for the adoption of the service, and even though AWS comes in latest, it has an advantage—Fargate.

And now, our main event: Comparing EKS vs. ECS vs. Fargate.

ECS

What is the Amazon ECS? It is Amazon’s “Docker” as a service. It allows you to take advantage of several enhancements in managing the underlying infrastructure so that you can focus on building your service. Could you just provision a Docker Registry and Docker Images, then load Docker on EC2 instances? Of course you could, but with that comes overhead, management, patching, distributing workload, scheduling scaling, recovery, and more.

ECS takes the pain of managing infrastructure away from you. ECS offers support in its CLI for Docker Compose (the ability to launch multiple containers in a batch) and it integrates seamlessly to Amazon Elastic Container Registry (ECR) for you to manage your custom Docker Images, removing the need to manage your own registry or subscribe to a paid registry on Docker.

A managed registry and CLI support isn’t enough to make Amazon ECS mainstream. ECS took notes out of what made Elastic Beanstalk (EB) great and incorporated it into the offering. ECS takes from EB the ability to auto heal, so failed containers will be relaunched automatically (called Auto-Recovery). ECS also integrates with Elastic Load Balancers (Amazon ELBs), Identity and Access Management (Amazon IAM), and Amazon CloudWatch/CloudTrail for logs and auditing. This makes ECS fuller featured versus its manually managed EC2 counterparts.

ECS really begins to shine when duplicating environments using AWS CLI/SDK calls, managing hundreds of containers, or building and collapsing dev environments without worrying about all the provisioning that is required prior to launching Docker. Managing multiple containers upon a host has become even easier. Originally, bridged networking would allow ECS to communicate with the host ENI. This was a limitation when duplicated services were running on the same host (think Nginx running on port 8080), but with AWS’s recent improvement of awsvpc, individual interfaces are assigned to individual containers. This allows containers all the features available to an EC2 Instance with an Elastic Network Interface (ENI), such as it’s own Security Group.

EKS

Even though Amazon EKS is released only as a Preview (as of the writing of this article) it is a highly anticipated addition to the Amazon suite of offerings. Managed Kubernetes, with all the features of ECS, such as IAM, ELB, CloudWatch, and CloudTrail offerings. Where ECS removes the manual efforts to building docker hosts, EKS extracts an additional layer of scheduling and clustering provided by Kubernetes to a container environment and, again, allows you, the provider, more time to develop your solution and less time managing the architecture beneath the solution.

The real question is: where will EKS stack up compared to AKS(ACS) and Google Kubernetes Engine (GKE)?

Currently, GKE manages your Kubernetes Master Nodes for you. It boasts Global Spanning load balancing and offers ease of deployment—it is currently the most robust seasoned offering. GKE allows you to upgrade, add, and remove nodes through the management console. AKS(ACS) offers managing the Master nodes but has a nice benefit of allowing you to snapshot your configuration for reuse. Interestingly enough, the pricing model for AKS is cheaper on longer-term workloads versus GKE which is cheaper on shorter workloads.

For EKS, it is the last of the major three to enter the market with managed Kubernetes. Like its counterpart, ECS, it will allow you to place your workloads on AWS through CLI/SDK and allow you to manage your container workloads as a paid offering. It’s difficult to say until it’s launched where it will stack up directly against its more seasoned competitors, but AWS is already thinking through the next step—Fargate. This comment has been made several times in the article, and it is worth mentioning multiple times, because Fargate is what AWS is using to set its management apart from its peers.  

Fargate: The Competitive Advantage

Fargate is not an additional container, or offering in itself, it is a launch type. Why is it so important? Why has it garnished several mentions in this article? Because it is the game-changer.

Managing Kubernetes can be complicated. It can be risky. It requires a deep understanding of how to not only provision, schedule, manage your masters, minions, pods, services, and containers, but it means managing an additional orchestration of architecture atop all the virtualization that was already abstracted for you. It also requires a staff of DevOps engineers who know how to handle it. It requires learning an entirely new way of managing your offering and services. Fargate takes that effort away from you and streamlines deployments. his ultimately leads to faster delivery of what is most important to you—your service. What is the best part? You don’t have to decide and fully buy into Fargate. You can start on ECS or EKS, test your process and workloads, and then you can migrate your workloads to Fargate. Yep, that means you don’t have to choose and lock-in. You can guess, test, and pick which one is best for your use case and comfort and then change it.

Fargate is already offered with ECS. It allows you to stop considering what instance types to use. It removes the need to determine the placement of resources, scheduling, scaling, and patching; it eliminates most of the management that is a requirement for containers—and it is going to be offered with EKS.

What does this mean? This means you can focus on building your docker images, placing them in ECR, and deploying them into a web of containers through EKS, easily. This launch type could very well bring AWS in line with Azure and Google quickly and then push AWS ahead.

Summary

Containers aren’t a fad, they are a reality, and they are here to stay for now. Managing Docker in the cloud is becoming less popular as more mainstream services are maturing and, more importantly, Kubernetes is gaining wider acceptance. Now that Kubernetes management is a reality, the question is not whether to adopt it, but how, and on which vendor. The battle is only beginning between the three major cloud providers, you can bet any of them are a good gamble since they all want to be mainstage. Evaluate all three. Kubernetes is a complicated beast and deserves the R&D effort before you go all in.