Containers 101: From ‘It Works on My Machine’ to ‘It Just Works’

Why You’re Probably Here

You’ve likely heard developers or DevOps engineers say, “Let’s containerize it” or “I’ll just spin up a Docker container.” And if you’re not already familiar, it might sound like tech jargon or even hype.

But containers are not just a trend — they’re a foundational shift in how modern software runs. If you’re just starting your cloud or DevOps journey, understanding containers is one of the most important steps you can take.

This post isn’t just about Docker — it’s about the journey of containers: where they came from, why they matter, and how they evolved into a key pillar of cloud-native computing.

The Problem Before Containers

Let’s start with a story many developers know too well.

You spend days building an application on your local machine. It works beautifully. Everything runs smoothly. You test it, you tweak it, you polish it — and then you deploy it to staging or production…

…and everything breaks.

What happened?

The new environment had a different version of a system library. Or maybe a configuration file wasn’t set up the same way. Or it was running on a different OS entirely. These types of problems are painful and common. They’re caused by the fact that software often depends on its environment to function properly — and environments are rarely identical.

We needed a way to package not just the code, but everything the app needs to run: libraries, configuration, tools, even the file system structure.

That’s where containers come in.

What Is a Container, Really?

A container is a self-contained unit of software that includes the application itself and everything it needs to run. That means not just the code, but also:

• Runtime libraries
• Dependencies
• Environment variables
• File structure
• Configurations

When you run a container, it behaves exactly the same on your laptop, a cloud server, or a production cluster. That consistency is the magic.

You can think of containers like shipping containers in the global trade system. It doesn’t matter what’s inside — electronics, furniture, bananas — every container has the same shape and size, so it can be moved easily between ships, trucks, and ports. That’s what containers do for software: standardize the format so apps can run anywhere.

Before Docker: The Hidden History of Containers

Here’s a surprise for many people: containers didn’t start with Docker. In fact, the roots of containerization go back over 40 years.

In 1979, Unix introduced a feature called chroot, which allowed a process to see only a specific part of the filesystem. It was primitive, but it planted the first seed of isolation.

Fast-forward to the early 2000s, and you get more advanced systems:

• FreeBSD Jails (2000): A way to isolate multiple user environments on a single Unix system.
• Solaris Zones (2004): Even more powerful, allowing separate OS-like environments with their own resources.
• OpenVZ and LXC (Linux Containers): These brought container-like environments to Linux, using kernel features like namespaces and cgroups for isolation.

These tools worked — but they weren’t easy to use. You needed deep Linux knowledge, manual configuration, and a lot of trial and error. Containers existed, but they were invisible to most developers.

The Docker Revolution (2013)

Then, in 2013, something changed. A small company called dotCloud released an internal tool they built for packaging and running applications. They called it Docker.

Unlike previous tools, Docker wasn’t just a container runtime — it was a full developer-friendly toolkit that made working with containers easy:

• A simple CLI (docker run, docker build)
• Reproducible image builds using Dockerfile
• Docker Hub, a place to share container images
• A daemon that handled all the low-level kernel operations behind the scenes

Suddenly, you didn’t need to be a sysadmin or kernel expert to use containers. Docker made containers as easy to use as Git.

Developers could now build once and run anywhere — confidently.

Within two years, Docker became one of the fastest-growing open source projects ever.

But Docker Isn’t Alone

Even though Docker became the face of containerization, it’s important to know it’s not the only player — and it doesn’t do everything.

As Docker grew in popularity, the ecosystem evolved too. Many of its internal components were modularized:

• containerd became the default container runtime inside Docker (and is now used independently in Kubernetes).
• CRI-O emerged as a minimal container runtime built specifically for Kubernetes.
• Podman offers a daemonless and rootless Docker alternative, focusing on security and compliance.
• Other earlier tools like rkt by CoreOS also explored alternative container paradigms (though it’s now deprecated).

Today, Docker is often used for local development and image building, while Kubernetes handles container orchestration using runtimes like containerd under the hood.

You don’t have to pick one. They all work together.

Containers vs. Virtual Machines: What’s the Difference?

It’s easy to confuse containers with virtual machines. They both offer isolation, right? But the way they do it is fundamentally different.

• A VM runs a full guest operating system on top of a hypervisor.
• A container shares the host OS kernel but keeps the process isolated at the user-space level.

That means:

In many cases, containers are faster, lighter, and easier to manage, which is why they’ve become the preferred choice for modern application deployment.

How Containers Power the Cloud-Native World

Docker and containers didn’t just solve a developer pain point — they unlocked a new model of computing. That model is what we now call cloud-native.

Containers are now the building blocks of:

• Microservices architecture
• CI/CD automation
• Immutable infrastructure
• Dev environments (e.g., GitHub Codespaces, devcontainers)
• Kubernetes clusters
• Serverless runtimes (yes, many serverless tools use containers behind the scenes)

Because they’re fast, portable, and predictable, containers allow teams to scale apps effortlessly and reliably — whether it’s one container on a Raspberry Pi or a thousand containers in a production Kubernetes cluster.

So, Why Should You Care?

If you’re stepping into cloud, DevOps, or backend engineering, containers are foundational knowledge.

You don’t need to memorize every runtime or kernel trick — but you do need to know:

• How to build and run a container
• What a Dockerfile does
• How containers behave in different environments
• Why Kubernetes and modern infrastructure depend on containers

Containers are not just a trend — they’re how modern apps are built and shipped.

Up Next: Your First Hands-On Docker Lab

Enough theory — it’s time to build something real.

In the next post, we’ll walk through:

• Building a simple Node.js app
• Containerizing it with Docker
• Publishing it to Google Cloud’s Artifact Registry

📬 Want more beginner-friendly DevOps and Cloud tutorials?

Subscribe here and get new labs, tools, and insights sent to your inbox.