Containers in the Cloud
By: Munsif Musthafa
Tags: AWS, Containers, Container Orchestration, Programming, Docker

AWS Elastic Container Service

For enterprise-grade applications or systems, it is de facto to go for Cloud-based deployment where you pay-as-you-go.

AWS, being the industry-leading XaaS provider, understood the impact containers make in building software and provides their own service, called the AWS Elastic Container Service (ECS).

AWS ECS is designed to be a highly-scalable, high-performant container orchestration service that supports Docker containers. This service enables us to easily run and scale containerized applications in the Cloud.

Imagine a scenario where your application is a Java micro-service, expected to run on a Linux server, having its own micro-database, and you decide to build this on AWS.

In this case, deploying your micro-service using ECS and using Relational Database Service (RDS) by default provides you with the added benefit of fault-tolerance as well, which means we don’t have to worry about that when designing.

Also, the specific host a container runs on and its maintenance are all managed by the platform itself.

AWS provides new terms for its services and modules. Let’s learn them along the way. For this, let’s take a small scenario similar to the above.

Imagine we need to run an application server ( app_1 ) which also requires a small cache service ( app_2 ) to run alongside it.

Task definition

As the name sounds, it’s the blueprint for a task. Think of a Java Class . It dictates which containers are to be run.

In the above example, it would declare both the applications to run in two containers in a single task. It also defines the details, such as environmental variables, to be used, CPU and memory allocations, exposed ports, and how each of the containers would interact.

The number of tasks to be run is also declared in this.

Task

A task is an instance of the above blueprint. Think of an Object of a Java Class . Tasks are run as configured via its task definition, allowing multiple tasks to be run from a single definition.

In our example, one task would run both the app_1 container and the app_2 container.

Service

Service allows you to run and maintain the specified number of instances in a task definition, simultaneously in a cluster.

This sustains the minimum and maximum tasks at a given time and manages more things, including load balancing and auto-scaling of the containers.

For example, in our case, due to high load at a specific time, if the CPU starts to throttle, the service checks for the maximum number of allowed tasks to run and increases the number of tasks one-by-one until a given average threshold is achieved.

Container instance

These tasks (and containers) need to be run somewhere to be accessed — enter container instances. Container instances are EC2 instances that run Docker and a special piece of software called the ECS Agent and registered into the Cluster of instances.

Each of these instances has the ability to run one or more tasks (i.e. one or more containers), given that it has physical resources available. Also, to note is that a container instance can run tasks from one or more Services .

The Agent acts as the bridge between these instances and ECS by providing the statuses of the running containers and managing spawning new containers in an instance.

Cluster

A Cluster is a group of ECS container instances. The ECS facades all the complications of maintaining, scheduling, and scaling these instances.

Also, based on the placement strategy, it places new container spawns in optimal instances and abstracts the pain away.

When you have multiple software modules that run independently as parts of your product, you can place several of them in one cluster, which enables optimal usage of resources and actually minimizes the setup time.