A World Before Docker
Imagine it’s 2008.
Cloud computing was starting to take off. Startups were building products faster than ever. Developers were writing code, testing it on their laptops, and feeling confident that everything was ready.
Then comes deployment day.
The same application that worked perfectly yesterday suddenly refuses to run.
The developer checks the code.
“It works on my machine.”
The problem was never just the code.
The real problem was the environment.
Software had become dependent on the place where it ran.
An application wasn’t just an application anymore. It was the code plus the operating system, the libraries, the software versions, and all the tiny settings that nobody remembered configuring.
Moving it to another computer, server, or environment often made its behaviour unpredictable.
The industry needed a better way to run software.
But before Docker entered the picture, companies had already spent years trying to solve this problem.
The Age of Physical Servers
Back then, companies mostly ran applications on physical servers.
The idea was simple:
One application, one machine.
And honestly, it made sense at the time.
Because applications were unpredictable.
Two applications sharing the same machine meant they also shared the same environment. If one application required a newer library version, upgrading it could break another application that depended on the older version
So companies chose the safer option:
Keep everything separated.
But the problem was that isolation came with a huge cost.
Imagine a company bought a server with 32 GB of RAM and a powerful processor, while the application running on it used only 8 GB.
Normally, you would put another application on the same machine and use the remaining capacity. But companies couldn't confidently do that. The second application might require different software versions, different libraries, or different system configurations. A conflict could bring down both applications.
So instead of using the remaining 24 GB...
They bought another server.
Companies were buying huge amounts of hardware but using only a small part of what they paid for.
They needed a way to use servers more efficiently.
The first major breakthrough came with virtualization. Instead of solving the problem by buying more hardware, engineers began asking a different question:
"What if one physical server could behave like many independent computers?"
Virtual Machines: The First Big Shift
Virtualization changed the way companies thought about servers.
Technologies from companies like VMware introduced the idea that a single physical machine could run multiple independent computers.
Instead of buying ten physical servers, a company could buy one powerful server and create ten virtual machines on top of it.
Each virtual machine had its own operating system, its own applications, and its own isolated environment.
For companies, this was a massive improvement.
Costs dropped significantly.
Hardware that was sitting unused could finally be shared.
A server that previously ran only one application could now run several workloads at the same time.
But there was still a problem.
Virtual machines were still heavy.
Every VM included its own kernel, system services, drivers, and operating system processes. That means memory and CPU are consumed even before the application starts.
To understand why, imagine running three simple applications on the same physical server.
Physical Server
│
├── VM 1
│ ├── Linux
│ └── App A
│
├── VM 2
│ ├── Linux
│ └── App B
│
└── VM 3
├── Linux
└── App C
Notice something?
The operating system is being repeated over and over again.
But here's the question.
Do three Linux applications really need three copies of Linux ?
It's like sending ten people to the same destination. Instead of taking one bus, each person drives their own bus — with the engine, fuel tank, and maintenance costs duplicated every time.
Clearly, virtualization wasn't the final answer. Engineers began asking a new question:
“What if we could isolate applications without needing to install the same operating system every time?”
This search for lighter isolation eventually led to containers.
A container packages the application with its required libraries, but it does not include a full operating system. It uses the host OS kernel, so the kernel does not need to be downloaded or installed again and again like in virtual machines. This makes containers lightweight, fast, and efficient, while still keeping applications isolated.
Did Docker Really Invent Containers ??
One of the most misunderstood parts of Docker's history is that Docker invented containers.
The idea of containers existed long before Docker became popular.
Linux developers had quietly been adding features like:
- chroot
- Linux namespaces
- control groups (cgroups)
Interestingly, these features weren't built for Docker.
But using Linux containers was complicated.
You needed deep Linux knowledge.
You had to manually connect different technologies and understand exactly how isolation worked.
That’s where Docker changed the game.
“Docker didn’t invent containers.”
It made containers “easy”.
Docker is an orchestration of existing Linux features.
So when we write
docker run
Behind this single command, Docker quietly sets up multiple Linux kernel features to isolate the application.
It automatically creates namespaces, configures cgroups, sets up networking, mounts the filesystem, and finally starts your application—all in a matter of milliseconds.
✔ PID Namespace
✔ Mount Namespace
✔ Network Namespace
✔ UTS Namespace
✔ IPC Namespace
✔ cgroups
✔ Start the process.
Making containers easier to use sounds obvious today, but someone actually had to build the tooling that made it possible.
The Company That Wasn't Trying To Build Docker
Around 2010, a startup called dotCloud was working on a different problem.
They were building a Platform-as-a-Service (PaaS).
The idea was simple:
Developers should be able to write an application, upload it, and let the platform handle the complicated infrastructure underneath.
For that, dotCloud engineers built tools around Linux containers. These tools helped package applications and isolate them from the rest of the system.
At first, it was just infrastructure.
But slowly, the team noticed that developers were more interested in the internal container technology than the actual platform.
The tool that helped run dotCloud was becoming more exciting than dotCloud itself.
So the company separated the technology and open-sourced it.
In 2013, that project became known as: Docker.
Docker didn't invent containers. It made them accessible.
By hiding the complexity of Linux namespaces, cgroups, and other kernel features behind a few simple commands, Docker transformed containers from an expert-only Linux feature into a tool that millions of developers could use with a single command.
And that was just the beginning.
In the next article, we'll go one level deeper and explore how Docker has evolved over years
Top comments (0)