AMAZON ECSIcon-Architecture/64/Arch_Amazon-Elastic-Container-Service_64Created with Sketch.

A FULLY MANAGED CONTAINER ORCHESTRATION SERVICE

DOCKER🐳

Before getting started with ECS, you need to understand Docker, because it's one of the basic building blocks.

Docker helps to create environments to run your application, regardless of the underlying operating system.

KEY TERMS🔑

Let's dig into ECS Key Terms, which can be confusing at first but are good to understand how it internally works, Task Definition, Task, Service and Cluster.

CONTAINERS📦

This lightweight environment is called a Container and - like the name already suggests - contains everything that's needed to run your application, like certain versions of a library or language.

You can run multiple containers on the same machine. Containers can even communicate with each other when needed.

When your application grows, there will most probably be challenges in managing all the deployments, containers, scheduling and other Kubernetes tasks.

CONTAINER MANAGEMENT⚙️

That's why you'll be in need of a container management or orchestration service. It's another abstraction layer that helps you easily manage your containerized applications and reduce your operational tasks.

That's exactly where ECS steps in.

ELASTIC CONTAINER SERVICE🚀

Amazon's Elastic Container Service (ECS) is a highly scalable & fast container management service.

It allows you to view & manage the state of your clusters from a centralized service. Easily schedule based on resource needs & availability requirements.

There are two different areas of responsibility:

  • Effective management of your tasks
  • Actually running your containers

ECS does not actually execute or run your containers. It only provides the management pane for controlling your tasks.

CONTAINER INSTANCE VS. FARGATE⚖️

If you have very high computation requirements, you should know that Fargate is way more restrictive regarding possible capacities for a single task.

General note: Even if you're a big serverless fan, knowing about ECS is crucial because you'll bump into it almost everywhere.

Considering the abstraction layer of ECS in combination with Fargate, it's considered a serverless technology.

TASK DEFINITION📝

A Task Definition is a blueprint of your container. It includes things like:

  • the image to use
  • CPU & memory allocation
  • secrets & environment vars
  • logging configuration
  • exposed ports

A Task is an actual instance that runs the containers that are provided in your definition. Single tasks can run multiple, different container for different purposes.

Additionally, you can run multiple tasks from the same definition if required, for example to have higher concurrency or meet increasing traffic demands.

SERVICE🔧

As we can have several tasks for the same definition, we need some boundaries and management. This is where the service comes in.

Among a lot of other things, you're able to configure rules for auto-scaling, load distribution as well as the minimum & maximum number of tasks.

CLUSTER🔗

A Cluster is a logical grouping of tasks or services that run on infrastructure that is registered to such a cluster. You can even provide your own on-premise virtual machines as compute capacities for your cluster.

FASTER DEPLOYMENTS

With a non-optimise configuration, deploying a new task definition to your cluster can take several minutes.

You can fine-tune many settings to get down to just a few seconds.

1. ECS Agent Settings

  • prefer cached images from ECS's disk cache
  • reduce grace periods for container shutdown

2. Load Balancer Settings

  • reduce time for keeping connections alive
  • reduce intervals for health checks & the needed number of successes before the task is considered healthy

3. ECS Deployment Settings

  • decrease the number of required healthy tasks to enable ECS to start more tasks in parallel

LAUNCH TYPES🚀

So finally it's the important question: which services actually run our containers?

You can either pick from using:

  • EC2 Launch Type
  • Fargate Launch Type
  • External Launch Type

So it's for example not ECS or Fargate, but ECS and Fargate.

Fargate offers a higher abstraction, as you're not responsible for the underlying infrastructure.

The External Launch Types allow you to register on-premise servers / virtual machines to your ECS cluster.

LAMBDA VS. FARGATE⚔️

Both Lambda and Fargate go into the category of serverless as they remove a lot of technical burdens due to not having to manage a lot of (or any) underlying infrastructure, it's worth to do a quick comparison.

  • Cost: Lambda is solely pay-per-use - you don't have any costs for idle functions. Your Fargate tasks are always charged if they are running. Nevertheless, looking at high traffic demands, Fargate can quickly outperform Lambda at costs.
  • Scalability: Lambda immediately scales horizontally; simple image tasks up to 10 minutes & that's much greater new tasks.
  • Performance: A Lambda function can only serve a single request at a time, so with varying traffic patterns will cause a lot of cold starts. Whereas with an AWS native key-value store like DynamoDB, you'll also have to fight with database connection management. You won't face any of these issues with Fargate.
  • Getting Started: with Lambda, networking knowledge is almost not relevant & tools like Serverless Framework enable you to spin up a simple application within minutes. ECS & Fargate need more time, even with great helpers like CDK & Level 3 Constructs that simplify via high abstraction.

OBSERVABILITY👁️

CloudWatch comes with default metrics like CPU or memory usage to grant you insights into your ECS services & tasks.

Developer Tools like Dashbird.io will collect metrics in a simple place, guide you with well-architected hints & can notify you of critical service events through your favourite channel like Slack.