Cloud Parts

Containers

Your app and everything it needs, packed into one portable image.

8 technologies on this page ↓
Live model
What you’re watchingA Dockerfile becomes one tagged image in a registry. Every environment pulls that exact image, so they all run the same bits.

How it works

A container image bundles your code with its runtime, libraries and config. When it runs, the host’s kernel isolates it into its own processes, filesystem and network. Containers share the host’s kernel instead of booting their own, so they start in seconds and use a fraction of the memory a VM needs, letting one machine run many of them.

Think of it as

A shipping container. The crane, the ship and the truck don’t care what’s inside, because the box is always the same shape.

Reach for it when

  • Ending “works on my machine”: dev, CI and production run the same image
  • Packaging services that need specific library versions
  • Running many small services densely on shared machines

Think twice when

  • Apps that need a different kernel or a desktop GUI
  • A tiny task triggered a few times a day, where a serverless function is simpler

A real example

A data team ships a Python API as api:1.4.2. The same image runs on a developer’s laptop, in the CI test job and in production. Upgrading means publishing a new tag.

More on containers

Narrower ideas that build on this one.

Technologies

Specific products, and what each does differently.

AWS FargateAWSRuns ECS tasks and EKS pods without servers: you size each task, AWS finds the machine.Cloudflare ContainersCommercialLinux container images that run on Cloudflare’s network next to a Worker, each instance started on demand by its own Durable Object and put to sleep when idle.+1 Cloudflare Sandbox SDKDockerOpen sourceThe tool that made containers mainstream: build an image from a Dockerfile, then run it anywhere.Google Cloud RunGoogle CloudGive Google a container that listens on a port; it runs as many copies as traffic needs, down to zero.gVisorOpen sourceA Linux kernel reimplemented in Go that runs in user space, so a container’s system calls never reach the host kernel directly.PodmanOpen sourceRuns Docker-style containers without a daemon, as root or as an ordinary user, and hands long-running ones to systemd.

Also used for containers

Products of other kinds that are often used this way, grouped by what they are.

What each provider calls it

AWS
ECS, Fargate, ECR (registry)
Google Cloud
Cloud Run, Artifact Registry; GKE Sandbox (gVisor)
Azure
Container Apps, Container Registry
Open source & others
Docker, Podman, containerd; gVisor for a sandboxed runtime

See it in a real stack

Architectures that use containers

Background jobs with a queueThe API drops slow work onto SQS and returns at once; a pool of Fargate workers drains the queue at a steady pace.AWS LambdaAmazon SQSAWS FargateAmazon S3

In code · dockerfile

FROM python:3.12-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY . .
CMD ["uvicorn", "main:app", "--host", "0.0.0.0", "--port", "8080"]

Worth exploring

Article· March 2023The Great Lambda Migration to Kubernetes Jobs: a Journey in Three PartsLiav Yona, InfoQA first-person account of how Firefly moved event-driven work off Lambda (after hitting the 15-minute timeout), briefly onto ECS, and finally onto Kubernetes Jobs on EKS, with practical notes on reusing container images, swapping an IAM trust policy for EKS OIDC, moving environment variables into ConfigMaps and a blue/green cutover. It is one company’s story with few numbers, and the author’s employer sells infrastructure-as-code tooling, which colours the emphasis on IaC.
Article· October 2020Is there a way to containerized a normal AWS Lambda function?Stack Overflow question by Sivvie LimA newcomer asks how to move an SNS-triggered Lambda function into a container on EKS. The answers, from October 2020, point to the lambci/docker-lambda images (since deprecated in favour of AWS’s official Lambda base images) and to Knative; read it mainly for the question, which is a common one, rather than for current tooling.
All resources →

Often confused with

Virtual machinesMicroVMsContainer orchestrationServerless functions (FaaS)VM, container, microVM or function?
Where it came from1979–2022

The idea of fencing a program in without giving it a whole machine goes back to 1979, when Version 7 Unix added chroot, which changes the directory a process sees as the root of the filesystem. It only hid files, though. Hosting companies wanted more: FreeBSD’s jails, released in FreeBSD 4.0 in March 2000, were sponsored by a web hosting company and aimed at providers that needed to keep their own services apart from their customers’, and they also restricted networking and visibility of other processes.

Linux built containers from separate pieces. Namespaces, starting with mount namespaces in 2002, gave a process its own view of mounts, process IDs, networks and users. In 2006 Google engineers Paul Menage and Rohit Seth started “process containers” to limit the CPU and memory a group of processes could use; renamed control groups, it was merged into Linux 2.6.24 in January 2008. LXC combined both that year.

The pieces were powerful but awkward until Docker (2013) wrapped them in a simple tool and a portable image format. The Open Container Initiative standardised that format and runtime in 2015, and orchestrators such as Kubernetes made them a mainstream way to run server software.

Why it’s built this way

Share the host’s kernel
Programs use the normal system call interface with nothing emulated, so a container starts as fast as a process and costs little memory. The price is that every container must run on the host’s kind of kernel, and they all trust it.
Partition the system instead of adding fine-grained permissions
FreeBSD’s jail designers kept Unix’s simple all-powerful root, but confined each root to its own slice of the system. Delegating a whole environment proved easier than writing detailed access rules.
Isolation assembled from separate kernel features
Linux added namespaces (what a process can see) and cgroups (what it can use) independently over years. That made them flexible but fiddly, which is why tools like LXC and Docker exist to combine them.
Ship the whole filesystem as an image
Isolation alone didn’t solve shipping software. Docker packaged the app and its libraries into a portable, layered image, which turned containers into a way to deploy software as well as a sandbox.

Timeline

  1. 1979

    chroot appears in Version 7 Unix

  2. 2000

    FreeBSD 4.0 ships jails for shared hosting

  3. 2002

    Linux 2.4.19 adds mount namespaces, the first namespace

  4. 2008

    cgroups merged into Linux 2.6.24; LXC released

  5. 2013

    Docker launches; Linux user namespaces enable unprivileged containers

  6. 2015

    Open Container Initiative formed to standardise images and runtimes

  7. 2022

    Kubernetes 1.24 removes its built-in Docker support

Sources14

Improve this page on GitHub