The problem Docker solves
Summary: between 2005 and 2013, installing an application on three different machines gave three different results. This inconsistency cost the software industry millions of lost hours every year. Docker solved this problem with a simple idea: packing the application AND its environment into a sealed box. This lesson describes the original problem.
1. The most hated sentence in software development
You are a developer. Your application works perfectly on your workstation. You push the code, your colleague pulls it, they try to launch it.
Error.
You check. On your machine, everything works. On theirs, everything breaks. You then utter the most hated sentence in all of software development:
"Strange… it works on my machine."
This scene played out billions of times between the 2000s and 2013, in every technical team in the world. It cost hours of debugging, delivery delays, tensions within teams, and weekends ruined fixing a production that refused to start.
Each cause of divergence is mundane. Taken separately, each is easy to fix. But they combine, accumulate, and turn a simple production release into a criminal investigation.
2. The five most frequent sources of inconsistency
Let us dissect the real causes of "it works on my machine".
2.1 · Diverging versions
Your application uses Node.js 20. Your colleague installed Node.js 18. The production server runs Node.js 16. Each version has its own APIs, its own bugs, its own subtleties.
Result: the same code produces three different behaviours. A test passes on your machine, fails on the colleague's, crashes in production.
2.2 · The invisible system libraries
Your application depends on the libpq library to talk to PostgreSQL, on libjpeg to manipulate images, on openssl for encryption. These libraries are silently installed on your workstation, often for years. You forgot they were there.
On the colleague's machine, they are missing. On the server, the version differs. Cryptic error message: error while loading shared libraries: libpq.so.5: cannot open shared object file.
2.3 · The forgotten configuration files
Your application reads a .env file with the Stripe API key, the database URL, the JWT secret. That file is in your project directory, but it is excluded from Git (good security practice). The colleague pulls the code without the file.
The application starts… then crashes as soon as it tries to read a variable that does not exist.
2.4 · The installation order
Your application needs PostgreSQL, Redis, ImageMagick and Node.js, in a precise order, with precise versions, and some dependencies must be installed before others. You did it 6 months ago, you no longer remember the steps. No document lists them.
The new team member spends two days reconstructing the correct order.
2.5 · The OS differences
Your team uses Windows, macOS and Linux — a mix that has become normal in modern companies. Each OS has its quirks: file paths with \ or /, line-ending encoding (CRLF on Windows, LF on Linux), different permissions, missing system tools.
A Bash script that works on macOS can crash on Windows — and vice versa with PowerShell.
3. The invisible economic cost
This chaos had an enormous cost, invisible in budgets but very real in schedules.
A Puppet Labs study in 2013 estimated that technical teams spent between 40% and 50% of their time fighting environment problems rather than writing useful code.
4. The attempted solutions before Docker
The problem was well known, and the community had tried several approaches — each bringing progress but none truly solving everything.
Virtual machines were the solution closest to the need: each VM contained a complete, reproducible environment. But the cost was prohibitive: several gigabytes per VM, several minutes to boot, impossible to launch 20 on a developer workstation.
A revolution was needed.
5. March 2013: the presentation that changed everything
On March 15, 2013, at the PyCon conference in Santa Clara (California), Solomon Hykes, a young French engineer and founder of a small startup named dotCloud, takes the stage for a 5-minute lightning talk.
He presents Docker, a tool that takes the best ideas from virtual machines (isolation, reproducibility), but based on a Linux kernel technology called namespaces — which achieves isolation without the weight of a full OS.
The room was buzzing. Within a few months, Docker became the fastest-growing open source project in GitHub's history. In 2 years, 83% of large companies adopted it. In 2026, Docker (and its cousins) runs tens of billions of containers per day worldwide.
6. What Docker made possible
This "sealed box" unlocked things that were technically possible before, but economically unrealistic.
In 13 years, Docker did not just solve a technical problem — it transformed the very way modern software is designed, deployed and operated. Without Docker, the DevOps movement, the rise of the cloud, and the microservices architecture would never have reached their current maturity.
Remember in 30 seconds
- Before Docker, the same code produced different behaviours depending on the machine it ran on — the famous "it works on my machine".
- The five sources of inconsistency: diverging versions, system libraries, forgotten config files, installation order, OS differences.
- The cumulative cost approached 40 to 50% of the time of technical teams.
- The solutions before 2013 (docs, VMs, Ansible, scripts) were all imperfect.
- Docker (March 2013) brought the lightweight sealed box: the reproducibility of VMs without their weight.