Those of you who have perused my blog last year (or talked to me in person) know that I’m pretty stoked about containers.  I think they are very cool conceptually and can bring a lot of value to streamlining the development process.

AWS has several options for containers and I wanted to do a VERY high level run through these to distinguish them a bit and maybe whet your appetite to dive into them a little more.

Briefly, containers are isolated areas to run multiple applications on the same machine without them stepping on each other.  E.g. I can run two different apps of the same flavor with completely different versions and dependencies on the same system.  For VMware folks, think of these as VMs (even though they are decidedly not VMs).  Container orchestration is the ability to schedule, scale up and down container instances, restart them if they fail, etc.  For VMware folks, think vCenter.

Also, why would you want to run containers on AWS?  Well depending on the type you may get better manageability, availability, etc. than you do by running on your own infrastructure.  You also leverage the cost structure and economics of the cloud (opex vs capex). And finally you can connect containers to AWS services like RDS, DynamoDB, etc. via IAM roles.

Roll Your Own – Docker Swarm

So this isn’t an available service from AWS (nor does it need to be Docker Swarm – could be Kubernetes, Mesos Marathon, etc.), but you obviously have the option of building your own container ecosystem yourself.  You can deploy EC2 instances of whatever type you want, and install your desired software.

Lots of flexibility here, but also a lot of management for you to take on.  This may be a good solution if you already have experience running your own container orchestration system and you want to leverage either AWS availability or services, but one of the other options is probably going to be a better long term solution.

Elastic Container Service – ECS

https://docs.aws.amazon.com/AmazonECS/latest/developerguide/Welcome.html

The first container service we are talking about is ECS.  Think of ECS essentially as AWS’s version of Docker Swarm (or again, whatever container orchestration tool you like).

The idea behind ECS is that you spin up EC2 instances which are running Docker, but that also have an ECS agent.  Instead of directly interacting with Docker, you set up tasks that are managed by the ECS system and agents.  The agent communicates with the Docker daemon.

You have some flexibility in how your environment is configured.  You can configure different sized container hosts, flexible OS choice (though Windows has several restrictions).  You can also take advantage of awsvpc networking mode which is cool as it greatly simplifies container networking, especially when running multiple conflicting containers (like multiple web servers listening on port 80) on the same host.  (check it out here) (this is one of those things that isn’t available on Windows)

Containers run on ECS are specified by tasks which are not standard Docker things – though they are pretty close.  In other words, if you are used to running Docker commands directly, they won’t work for you here, so there is a mild amount of learning or translation required.  No real heavy lifting, but something to consider.

At the end of the day, this is cool but still something you are managing.  There is a set of instances tied to your account that are running your containers that must be monitored and scaled, even though ECS handles some of this for you.  And this is where Fargate comes in.

Fargate

https://aws.amazon.com/blogs/compute/aws-fargate-a-product-overview/

Fargate shares a lot of similarity between standard ECS, without you actually having to run your own container instance cluster.  Instead you simply define tasks as a Fargate type, and they will run on the AWS Fargate infrastructure.  You are charged for the tasks themselves, not for the container EC2 instances.

I like this as there is less to manage and deal with.  But Fargate also has some restrictions currently.  For example, it is Linux only, and you must use the awsvpc networking type.  However if you are running these types of tasks in ECS, then you can simply swap the launch type to Fargate – no muss no fuss.

Fargate will let you deploy containers in a resilient manner without having to manage the underlying infrastructure.  Fargate, in my opinion, is much closer to the VM vs EC2 instance comparison than ECS is.  You don’t spin up EC2 clusters in order to launch EC2 instances – that part is managed by AWS.  Similarly, Fargate is perfect when you don’t care about the infrastructure, you just want to launch a task.

EKS

https://aws.amazon.com/eks/

EKS is Kubernetes on Amazon, and like every other Kubernetes acronym it is all wrong (“Elastic Container Service for Kubernetes”).  It is currently in preview mode but will likely GA soon.  There will also be a Fargate option with EKS, but again not today.

Kubernetes is a container orchestration system that came out of Google.  It is very popular today and is fantastic for container scheduling.  However managing the Kubernetes system itself (day-2 operations) is still very complicated.  EKS, like other similar services, seeks to bridge this gap by providing Kubernetes management transparently, allowing you to focus on service deployment.

EKS should also support traditional Kubernetes API calls, so if you have existing Kubernetes clusters this should be a more or less 1:1 mapping.

Summary

Like I said this isn’t intended to be a deep dive or cover all use cases, but I wanted to hit the high notes and let you know what was out there.  Containers on AWS utilize standard VPC components so they can be built very securely and reliably.  You can also use the Elastic Container Registry service, or ECR (https://docs.aws.amazon.com/AmazonECR/latest/userguide/what-is-ecr.html).  And again you can easily tie containers into your existing AWS services.