Back to Basics - Amazon ECS

This blog post is based on a presentation I gave at the Brisbane AWS User group and by the end of this blog, I hope you’ll have a better understanding of Amazon ECS and the benefits it presents to you and your customers.

Back to Basics - Amazon ECS

“Amazon Elastic Container Service (Amazon ECS) is a highly scalable and fast container management service.” - https://docs.aws.amazon.com/AmazonECS/latest/developerguide/Welcome.html

This is a quote direct from the AWS website. Why? Because big quotes as hero blocks look cool.

Some of the key problems seen by ECS customers in the lead up to them deciding to use ECS are;

• Over / underutilised workloads
• Incorrect scaling of workloads,
• High administrative overhead
• Complicated integrations to other services.

What’s a container though?

To explain what a container is, we should look at the history of compute first and see what problems containers were designed to solve.

When modern computing was first invented we started with mainframes, computers that took up entire rooms! Wings of a university would have been considered a container cluster. Compute was large, bulky and expensive.

1993 saw the popularity of the rack server increase swiftly, followed by the tower server which would sit on the floor of most server rooms (either making a great doorstop or being kicked out of frustration). Traditionally, this would involve a single operating system and one or two workloads such as file servers and email or core business apps and everything else they possibly could fit into it. This created single points of failure and could be expensive or difficult to make highly available (HA).

Around 1999. VMWare launched one of many popular virtualization platforms, a software defined, logically separated virtual computer. This now gave people the ability to launch multiple operating systems and compute workloads inside their own desktop or on a single server. Other vendors followed very quickly. This became an accepted method of separating workloads logically and made HA easier.

In 2006, Amazon launched EC2 (Beta) providing “a web service that provides resizable compute capacity in the cloud. It is designed to make web-scale computing easier for developers.”

All of these options allowed the administrator to easily allocate resources to a server (CPU memory, etc.), however, it still left the administrator looking after an operating system and its underlying hardware configuration.

So what IS a container?

In very basic terms, a container helps abstract the important software / application / code from the operating system and hardware. To quote Docker;

“A container is a standard unit of software that packages up code and all its dependencies so the application runs quickly and reliably from one computing environment to another”

A container is not an Amazon or AWS invention. It’s a global standard.

Amazon ECS

So, the reason we started this blog, Amazon ECS is an orchestrator of containers that you can configure to deploy your workloads based on one or more containers. ECS orchestrates Tasks as Services into a Cluster. I’ve just introduced three new terms there so now I’ll explain what they mean.

An amazon ECS cluster is a logical grouping of tasks or services. You can use clusters to isolate your applications, this way they don’t use the same underlying infrastructure.

You can use an Amazon ECS service to run and maintain your desired number of tasks simultaneously in an Amazon ECS cluster. How this works, is that if any of your tasks fail or stop, for any reason the Amazon ECS service launches another task based on your task definition. It does this to replace it and thereby maintain your desired number of tasks in the service. Right there, we have scaling and self healing.

A task is an instance of a task definition within a cluster. A task definition is just a configuration file which tells us how to run your software. After you create a task definition for your application, within Amazon ECS, you can specify the number of tasks you want running in your cluster. You can run a standalone task or you can run a task as part of a service.

ECS on EC2 vs ECS Fargate

Traditionally ECS requires a set of host resources to be launched, prior to launching a service or a task. This is achieved by launching a set of EC2 instances into the account. This creates a familiar resource that we’re able to understand, especially if we’ve been using EC2 since 2006.

Red flag!!

We’re still maintaining an operating system, EC2 instances and the underlying configuration. This is administrative overhead.

re:Invent 2017 introduced Fargate for deploying and managing containers without having to manage any of the underlying infrastructure. All of a sudden we’ve removed the administrative overhead of the operating system and extra resources.

Containers are now serverless.

Other advantages of ECS on Fargate is that you could easily integrate with other services. Less code, more productivity.

You can integrate with;

• Cloudwatch logs,
• EFS
• Load balancers or target groups
• Route 53

… and many other services.

Summary: Benefits of ECS

So let’s look at some of the benefits here that we get in terms of using ECS Fargate;

• We have Docker, it’s a common tool set, it’s portable between various cloud providers.

• We have security and isolation by design, access to all these integrations mentioned earlier are secured by IAM roles. We can also use a technology called “scan on push” when we deploy our containers into Amazon web services. This will then check for common CVEs and other vulnerabilities that might be present in our container image.

• Ease of scalability. We can now scale to hundreds (if not thousands) of Fargate tasks very quickly.

• Reduced administrative overhead by removing operating systems, nodes and instances.

• We also have cost benefits as well. Cost benefits by auto scaling and auto provisioning, pay as you go pricing and Fargate spot, which is also suitable for your dev clusters presenting cost savings of up to 90% of your production instances.

Why ECS Fargate?

So why should you choose Amazon ECS Fargate? Why should your customers choose ECS Fargate?

Getting things done, not worrying about how it gets there! Write your code and run it. You want to be productive. You don’t want to waste time managing that infrastructure. You don’t want to manage servers. You just want to get on with it

Fargate is also the technology behind a lot of other services (lambda, codepipeline, etc). Amazon develops a lot of their own toolsets and products using Fargate. If they build on Fargate, why wouldn’t you?

It’s easy to use and it’s reliable. It scales fast much faster than EC2 can and it’s also free to start using, unlike EKS where you have to pay for a control plane from the start.

ECS Fargate requires a skill set that’s easier to hire for and more available in the market right now, especially compared to EKS which in some cases might need two or three full time employees just to manage a single EKS cluster. And it’s easy to find support for too because of the skill set that’s in the market that’s easy to hire for.

There are many reasons to make AWS Fargate the right choice.