Containers with Mama J: Docker, ECS, and Fargate Explained
Containers, Docker, ECS, Fargate. You've heard the terms, but what do they actually mean? I sat down with my mom (Mama J) to explain containers from absolute zero. In this post, I walk through the "it works on my machine" problem, what containers are, how to build one with Docker, why you need orchestration, and how Amazon ECS and Fargate let you run containers at scale without managing servers. If Mama J can get it, you can too.
"It works on my machine."
If you've written code for more than a week, you've said this. I know I have. The app runs perfectly on my laptop. The buttons click, the data saves, everything is great.
Then I deploy it to a server and it breaks. Different OS version, missing library, slightly different configuration. Whatever the reason, it worked for me and it doesn't work over there.
Containers, Docker, ECS, Fargate. If you're newer to development, you've probably heard these terms tossed around without anyone stopping to explain what they actually are or how they fit together. Containers exist to tackle that problem, and I got the chance to sit down with Mama J (my mom) again to explain how! Last time we covered Serverless . This time it's containers on ECS. The way I see it, if Mama J can get it, you can too. In this post, I walk through what they are, why they matter, and how Amazon Elastic Container Service (Amazon ECS) lets you run them at scale without managing the underlying infrastructure.
The "works on my machine" problem
Here's why this hurts so much. Take a team of five developers. One is on macOS, another on Windows, a third on Linux. They all have slightly different versions of things installed. And the production server they're deploying to? That's different from all of them.
Works on my machine
When I say "environment," I mean everything surrounding your code. The operating system, the tools, the library versions, the settings. All of it. And on a team of five, you've got five different environments plus production. That's six chances for something to be slightly off.
So the question becomes: how do I make sure that what I build on my machine runs exactly the same way on your machine, on the test server, and in production? That's the problem containers solve.
What is a container?
I love this story. In 1956, a truck driver named Malcom McLean changed global commerce with one idea: put everything in a standard metal box. Same size, same shape, every time. Before that, workers loaded ships by hand. Boxes, barrels, crates, all different shapes. It took weeks. McLean said: standard box, never open it in transit, and make every ship, crane, and truck handle that one shape. Loading went from weeks to hours.
Software containers are that same idea. I take my application and pack it into a standard box along with everything it needs to run. The language runtime, the libraries, the tools, the config. Everything goes in the box. Now that box runs identically on my laptop, your laptop, a test server, or production. The environment is no longer a variable.
Containers vs. virtual machines
Now, someone's thinking: "Don't VMs already do this?" Fair question. They do, but with a lot of overhead.
VM vs. containers
Think of it this way. A virtual machine is a house. It has its own foundation, its own plumbing, its own electrical system. Everything is separate and self-contained. Strong isolation, but heavy. Each VM includes an entire operating system, takes up gigabytes of space, and can take minutes to start.
A container is an apartment. The apartments share the building's foundation and electrical grid, but each one has its own locked door and its own furniture. Containers share the host OS kernel but keep applications isolated from each other. They use megabytes instead of gigabytes, start in seconds instead of minutes, and you can fit hundreds on a server that might support 10 VMs.
Same isolation. Way less waste.
How to build a container with Docker
The tool that made containers mainstream is Docker (2013). The workflow has three steps, and once you see it, it clicks.
Building a container
First, you write a Dockerfile. This is your recipe card. It says what goes into the container:
1
2
3
4
5
6
FROM node:18-alpine
WORKDIR /app
COPY package.json .
RUN npm install
COPY . .
CMD ["node", "server.js"]
Start with a Node.js 18 base, install dependencies, copy the code, run the server. That's it.
Second, you build an image. When you run
docker build, the result is a read-only snapshot of your application and everything it needs. Think of it as a frozen meal. It's fully prepared, frozen in time, ready to go. You can store it, version it, share it across your team. But it's not running yet.Third, you run a container. Take that image and start it. Now it's live. And from one image, you can run 10 containers, 100, or a thousand. All identical copies.
Now, you can store images on Docker Hub (Docker's public registry), but for production workloads in AWS I use Amazon Elastic Container Registry (Amazon ECR). It's a private registry that stores your images, handles access control, and scans them for known vulnerabilities on upload and on a schedule.
Why you need container orchestration
So far, everything I've described works great for a single container on a single machine. But production looks nothing like that.
Picture a real application. I have an order service, a payment service, a notification service, and a few others. Each is its own container, and I'm running multiple copies of each for redundancy. That's potentially hundreds of containers across multiple hosts.
Now the questions start piling up. A container crashes at 3am. Who notices? Who restarts it? Traffic spikes on Friday. Who scales the service? The payment service needs to talk to the order service, but it moved to a different host. How does it find it?
Without something managing all of this, it falls apart fast. You need an orchestrator. Think of it like a kitchen. One chef handles everything fine. But during a dinner rush with 50 chefs? You need a head chef assigning stations, replacing sick workers, routing orders, and scaling up as demand changes.
Amazon ECS: the orchestrator
Amazon ECS is that head chef. It's a fully managed container orchestration service that's been running in production since 2014. It handles scheduling, scaling, health monitoring, networking, and load balancing for your containers.
ECS Architecture
The core concepts:
| Concept | What it is |
|---|---|
| Cluster | The logical boundary where your containers run. Dev cluster, staging cluster, production cluster. |
| Task definition | The blueprint: which image to pull, how much CPU and memory, which ports, what environment variables. |
| Task | A running instance of a task definition. |
| Service | A rule: "always keep N healthy copies running. If one dies, replace it. If demand grows, scale up." |
Here's what a simplified task definition looks like:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
{
"family": "product-catalog",
"cpu": "256",
"memory": "512",
"networkMode": "awsvpc",
"requiresCompatibilities": ["FARGATE"],
"containerDefinitions": [
{
"name": "catalog-api",
"image": "123456789012.dkr.ecr.us-east-1.amazonaws.com/catalog:latest",
"portMappings": [
{ "containerPort": 8080, "protocol": "tcp" }
],
"logConfiguration": {
"logDriver": "awslogs",
"options": {
"awslogs-group": "/ecs/product-catalog",
"awslogs-region": "us-east-1",
"awslogs-stream-prefix": "catalog"
}
}
}
]
}
This tells ECS: pull the
catalog:latest image from ECR, give it 0.25 vCPU and 512 MB of memory, expose port 8080, and stream logs to CloudWatch. ECS handles the rest. Placing the task on available compute, attaching it to the network, registering it with the load balancer. You define what you want running. ECS makes sure it stays running.Fargate: serverless containers
With ECS, you choose how containers actually run. You can manage your own Amazon EC2 instances (you pick the type, you patch the OS, you handle capacity). Or you can use AWS Fargate .
Fargate is serverless containers. You specify CPU and memory in the task definition. That's it. AWS handles the rest. You never see or manage a host.
I like to think of it this way: EC2 is owning a car. You maintain it, fill it up, change the oil. Fargate is a rideshare. You say where you want to go, the ride shows up.
Fargate vs. Lambda
Both Fargate and AWS Lambda are serverless, so what's the difference?
Lambda is event-driven and short-lived. A request comes in, Lambda runs your function (maximum 15 minutes), the execution ends. It scales to zero when nothing's happening. Great for API handlers, file processors, and quick scheduled jobs.
Fargate runs containers that stay up. A web server accepting requests around the clock, a background worker processing a queue, a service that needs persistent connections. Fargate containers can run for hours, days, or indefinitely.
The rule of thumb: if your workload is a short reaction to an event, Lambda. If it's a long-running process that needs to be always available, Fargate.
Running microservices on ECS: a real example
Let me make this concrete. Imagine a simplified online store with five services: product catalog, shopping cart, payment, order management, and notifications. Each runs as a separate ECS service with its own scaling rules and resource allocation.
A real example
Black Friday hits. The product catalog gets hammered because everyone is browsing. ECS Application Auto Scaling sees CPU climbing and adds containers. From 5 replicas to 50. Meanwhile, the notification service stays at 3 because nobody has checked out yet.
Each service scales independently based on its own demand. You're not paying to scale the entire application when only one piece is hot.
An Elastic Load Balancing Application Load Balancer distributes incoming requests across healthy containers for each service. If a container fails its health check, the load balancer stops sending traffic to it and ECS launches a replacement. The shopper never notices.
Container security on ECS: VPC, IAM, and encryption
Now, if you've seen the serverless video, you know Mama J has strong opinions about security. She's right. None of this matters if it's not locked down.
Every container running in ECS operates inside an Amazon VPC (Virtual Private Cloud). That's an isolated network where no traffic flows unless you explicitly allow it.
Each task gets its own IAM task role with least-privilege permissions. When a container starts, it can do nothing. You explicitly grant only the access it needs: read from this DynamoDB table, write to this S3 bucket, publish to this SNS topic. The notification service cannot access payment data. Isolated by design.
Data is encrypted in transit (TLS between services) and at rest. And ECR scans your images for known CVEs on push and on a recurring schedule, so you catch vulnerabilities before they reach production.
Getting started with Amazon ECS
If you want to go from reading to doing, here's the shortest path:
- Push an image to ECR. Build an image locally with Docker, create an ECR repository, push the image.
- Create a cluster. In the ECS console, create a cluster. With Fargate, there's nothing else to configure for compute.
- Write a task definition. Image URI, CPU, memory, port mappings, log configuration.
- Create a service. Tell ECS how many replicas, attach a load balancer if the service receives HTTP traffic.
- Deploy an update. Push a new image tag to ECR, update the task definition, update the service. ECS performs a rolling deployment with zero downtime.
The Amazon ECS Getting Started guide walks through each step.
Containers, ECS, and Fargate: the mental model
Here's what to keep in your head:
- Container = your code plus everything it needs, in one portable package.
- ECS = the system that runs, monitors, and scales your containers.
- Fargate = serverless compute under ECS so you never manage hosts.
- Security = least-privilege roles, network isolation, encryption everywhere.
Containers solve the consistency problem. ECS solves the operations problem. Fargate removes the infrastructure problem. Together they let you focus on building the application instead of managing what it runs on.
If you're ready to build, start with the ECS Workshop for a hands-on walkthrough.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article