Containers, Explained for Engineers Who've Quietly Avoided Them

If "container" still sounds like a marketing word, this post is for you. By the end you'll know exactly what containers are, what Docker actually does, and the precise moment Kubernetes stops being overkill.

Why this matters

Containers are the unit of deployment for almost every modern web stack. You can keep getting away with bare VMs or zip-and-scp deploys — but you’ll keep paying the cost in flaky environments, slow onboarding, and ops surprises at 2 a.m.

This post is the distilled version of what Module 9 of the IBM DevOps Professional Certificate taught me, written for someone who’d rather understand than memorise.

What a container actually is

A container is a process running on a host kernel, isolated from other processes by namespaces and constrained by cgroups. That’s it.

Namespaces give the process its own view of: filesystem, network, process IDs, users, hostnames.
cgroups cap how much CPU, RAM and I/O it can consume.

There’s no second operating system inside. A container shares the host kernel — that’s why it boots in milliseconds and a VM boots in seconds.

What Docker adds

Linux had namespaces and cgroups for years before Docker. What Docker added was an opinionated, friendly developer interface:

A packaging format — the image — that captures filesystem + metadata.
A build system — the Dockerfile — that produces images deterministically.
A distribution channel — registries — that move images between machines.
A runtime — the docker CLI — that runs them.

The labs in Module 9 walk you through each layer. The “aha” moment for me was realising that an image is just a stack of read-only filesystem layers, and a container is a writable layer on top.

1# Minimal mental model of an image
2FROM python:3.12-slim          # layer 1: base OS + Python
3WORKDIR /app
4COPY requirements.txt .         # layer 2: dependency manifest
5RUN pip install -r requirements.txt   # layer 3: installed packages
6COPY . .                        # layer 4: your code
7CMD ["python", "app.py"]

Every line that changes the filesystem is a new layer. Reuse means lightning-fast rebuilds.

When you actually need Kubernetes

Short version: when “I’ll just SSH and restart it” stops being safe.

You need an orchestrator when you have:

More than one host running containers.
A need for self-healing (a container dies → something restarts it automatically).
Rolling updates without downtime.
Service discovery between services.
Resource-aware scheduling across nodes.

Kubernetes is a control loop: you declare desired state in YAML, controllers continuously reconcile reality with that desire. Once that idea clicks, the rest of K8s is just vocabulary.

The five concepts that unlock 80% of Kubernetes

Concept	One-line definition
Pod	One or more containers sharing a network namespace and lifecycle.
Deployment	“I want N copies of this Pod, always.”
Service	A stable in-cluster IP/DNS name that load-balances to Pods.
Ingress	The cluster’s front door — routes external HTTP to Services.
ConfigMap / Secret	Decoupled config + secrets, mounted into Pods at runtime.

If you can read a Deployment manifest and explain what each field does, you can hold your own in a Kubernetes interview.

What the IBM course does well here

Embedded sandbox. You don’t install anything locally; the labs run in a hosted IBM Cloud environment with Docker, Kubernetes, and OpenShift available.
OpenShift exposure. Rare in MOOCs, valuable in enterprise contexts.
Bridge to CI/CD. By the end of the module the container you built feeds straight into the Tekton pipeline you’ll build two modules later — no toy disconnect.

What I had to supplement

Networking depth. The course skims CNI, kube-proxy, and Services-vs-Endpoints. I used the official Kubernetes docs + a few Tigera Calico videos to fill the gap.
Production-grade Dockerfiles. Multi-stage builds, non-root users, and minimal base images get a brief mention but no deep lab. I’d recommend a side read of the Docker Dockerfile best practices.

Next steps

Run the labs. All of them. Watching containers is the cheapest possible illusion of learning.
Rebuild one of your existing apps as a multi-stage, non-root container.
Deploy it to a Kubernetes cluster — minikube, kind, or the course’s sandbox is fine.

When you’re ready for the structured path that includes monitoring, security, and a full CI/CD capstone, the parent course is here:

IBM DevOps & Software Engineering Professional Certificate on Coursera