Why Docker Exists

In one line

"It works on my machine" is a packaging problem, not a coding problem. Docker packages an app with everything it needs to run, so the same package behaves identically on a laptop, a test server, and production.

0/4 · 0%

Think of it like this

Shipping a piece of furniture. Before shipping containers existed, every port had different cranes, different loading rules, and cargo was handled one box at a time — slow, inconsistent, damage-prone. The shipping container standardized the BOX, so any ship, crane, or truck could move it without caring what was inside. Docker does the same for software: it standardizes the 'box' your app ships in.

Key ideas

01
The problem before Docker: your Java app needs JDK 17, a specific Maven version, three environment variables, and a particular OS library — and the tester's machine has JDK 11 and is missing that library. The app 'works on my machine' and breaks on theirs, not because the CODE is wrong, but because the ENVIRONMENT is different.
02
Docker's fix: package the app AND its entire runtime environment (JDK, libraries, config, dependencies) into one immutable unit called an image. Anyone who runs that image gets the exact same environment, byte for byte, whether it's your laptop, a CI server, or a production cluster.
03
Containers are NOT virtual machines. A VM virtualizes an entire computer, including its own kernel — heavy (gigabytes), slow to boot (minutes). A container shares the HOST machine's kernel and only isolates the process, filesystem, and network — light (megabytes), fast to boot (milliseconds to seconds).
04
The one-sentence pitch you should be able to give in an interview: 'Docker packages an application with its dependencies into a portable, isolated unit called a container, so it runs identically across any environment that has Docker installed.'
05
What Docker is NOT: it's not a programming language, not a replacement for good code, and not automatically 'production-ready' just because it runs in a container — a badly configured container is still a badly configured app.

In your stack

→
Before Docker: 'install JDK 17, set JAVA_HOME, install Maven 3.9, set these 4 environment variables, then run the app' — a full page of setup instructions per environment.
→
After Docker: 'docker run mycompany/my-spring-app' — the image already contains the correct JDK, the built JAR, and every environment variable baked in or passed at runtime.

Explain it without notes

Explain to a non-technical friend why 'it works on my machine' is actually an environment problem, using the shipping container analogy.

What's the single biggest structural difference between a VM and a container, and why does it make containers so much faster to start?

Practice

List 3 things that have ever been different between your machine and a teammate's/server's machine that caused a bug or a failed deploy (JDK version, missing env var, OS package, etc.).

Without running anything yet, write down in your own words what you think an 'image' and a 'container' are, based only on this topic — you'll check yourself against Topic 1.1.

Trade-offs

↔
Docker adds a real learning curve and a new layer of tooling to maintain — for a tiny personal script that only ever runs on your own laptop, plain execution is simpler and Docker is overhead you don't need yet.

Done when you can

I can explain, in one sentence, what problem Docker solves.
I can state the core structural difference between a VM and a container without hesitating.