The Evolution of AWS’ Serverless Container Platform: Fargate
One of the interesting announcements from Amazon Web Services’ re:Invent earlier this month is the general availability of Amazon Elastic Kubernetes Service (EKS) on AWS Fargate. With this integration, AWS customers can deploy Kubernetes pods in a nodeless, serverless environment. Any Amazon EKS cluster running Kubernetes version 1.14 can be configured for Fargate.
In this four-part series, I plan to cover the evolution of Fargate, the design, and the architecture of EKS on Fargate, deployment workflow, limitations and strengths of the platform, and finally the comparison of Fargate with Azure Container Instances and Google Cloud Run. Check back on Friday for the second installment and again next week for the remaining posts.
The Rise of Serverless Container Platforms
Amazon is not the first or the last vendor to add Serverless Container Platform (SCP) support to its cloud infrastructure. In 2017, Microsoft launched Azure Container Instances (ACI) as the serverless container environment which was later extended to the Virtual Kubelet project. Earlier this year, Google launched Cloud Run on GCP with the same objective. Like Fargate, Cloud Run can be run within the context of an existing Kubernetes (GKE) cluster. See my analysis of Azure Container Instances and Google Cloud Run.
The goal of every serverless container platform is the same — bring your container image and walk away with an endpoint. This promise reminds us of the first generation PaaS offerings such as Cloud Foundry, Heroku, and Engine Yard that expected source code as an input and a public-facing URL as output. The key difference between SCP and PaaS is the input — container image vs tarball.
A Closer Look at Amazon ECS
Amazon Elastic Container Service (ECS) marked the entry of AWS into the containerized infrastructure market. When it was announced in 2014, Kubernetes was not there yet which forced AWS to build a container orchestration platform from the ground up. ECS was modeled around Elastic Beanstalk with Docker Compose compatibility. The service acted as an orchestration layer for a fleet of EC2 instances running containers.
Since ECS is a container orchestration platform much like Kubernetes, it takes a Docker container image, schedules that in EC2 instances, and scales the containers as required. A container image is wrapped in ECS task definition that declares the resource requirements such as CPU units, memory, network ports, and others. An ECS service definition will extend the task to meet the desired number of instances. It also wires the task instances to a load balancer to route the traffic across the running instances.
As we can see, the ECS task definition closely resembles a Kubernetes pod while the service definition mimics a Kubernetes deployment.
But, what is different from Kubernetes is the concept of an ECS cluster. In ECS, a cluster is an isolated, logical boundary for tasks and services. It’s different from a Kubernetes cluster which is a collection of master and worker nodes.
Before launching tasks and services, customers need to create a cluster that consists of one or more EC2 instances. Each EC2 instance participating in the cluster runs an agent to talk to the ECS control plane. Think of this agent as the Kubelet running inside every node of a Kubernetes cluster.
Amazon ECS expects customers to deal with the underlying EC2 infrastructure. They need to know a lot of details such as the instance type, AMI, EBS size, VPC subnet, security groups, and more. There is quite a bit of infrastructure plumbing that needs to be done before scheduling the first ECS task in the cluster. This is primarily because of the way ECS deals with EC2 which is only at the task and service orchestration level rather than provisioning, configuration and scaling the fleet.
AWS Fargate: Removing the Infrastructure from the Equation
In 2017, Amazon launched AWS Fargate, a compute engine for deploying and managing containers without having to manage the EC2 infrastructure. AWS Fargate became one of the options to launch containerized workloads on Amazon ECS.
At its core, Fargate lets ECS users focus on the task and service definitions instead of managing the cluster infrastructure. ECS customers choosing the Fargate deployment option will never have to deal with EC2.
Behind the scenes, Fargate still uses one or more EC2 instances to run the containers. The instance configuration is mapped to the resource requirements mentioned in the task definition. AWS Fargate users don’t get to see the EC2 instances because they don’t run in their account. Instead, Amazon provisions EC2 instances running Fargate tasks in a dedicated, private VPC which is not accessible to the outside world. If a service definition is exposed via an ELB or ALB, the subnet of the Fargate is attached to an Elastic Network Interface (ENI) that is associated with the load balancer. We will take a closer look at this in the upcoming articles of this series.
Another interesting fact is that each Fargate task runs only in one EC2 instance. Amazon doesn’t schedule multiple tasks on the same EC2 instance even if they share the same definition. If a task definition has multiple containers, all of them are co-located in the same EC2 instance. The AMI for the EC2 instances running Fargate workloads is highly optimized for containerized workloads.
In summary, Fargate is a PaaS-like layer on top of ECS that abstracts the infrastructure which enables users to focus on the desired state of the application.
In the next article, we will take a closer look at Fargate architecture and its integration with EKS.