Part 1: The Evolution of Software Deployment

The Problem That Started It All

Every engineer has heard it. Every operations team has lived it. The phrase that launched a thousand infrastructure innovations:

Imagine you are a developer in 2005. You have built a web application that runs perfectly on your laptop. It uses Python 2.7, a specific version of OpenSSL, a particular PostgreSQL client library, and a custom-compiled image processing library. You hand this off to the operations team to deploy to production.

The production server runs a different Linux distribution. It has Python 2.6. The OpenSSL version is older. The PostgreSQL client is newer and has a slightly different API. Your application crashes immediately.

Deployment Nightmares

This was not an edge case — it was the default experience for most software teams. The problems were systemic:

• Dependency conflicts — Application A needs library v1.2, Application B needs library v1.8, and they cannot coexist
• Environment drift — Development, staging, and production slowly diverge as patches and updates are applied inconsistently
• Configuration sprawl — Each server has hand-crafted configurations that nobody fully understands
• Slow deployments — Provisioning a new server takes days or weeks of manual work
• Poor utilisation — Servers sit idle most of the time but cannot be shared safely

These problems were not just inconvenient — they were expensive. Studies from the era showed that up to 40% of IT budgets went to maintaining existing infrastructure rather than building new capabilities.

The Physical Server Era

In the beginning, there was hardware. Every application got its own dedicated physical server — a practice that now seems almost unimaginably wasteful.

flowchart TD
    A[Physical Server] --> B[Operating System]
    B --> C[Runtime Libraries]
    C --> D[Application]
    style A fill:#132440,stroke:#3B9797,color:#fff
    style B fill:#16476A,stroke:#3B9797,color:#fff
    style C fill:#3B9797,stroke:#132440,color:#fff
    style D fill:#BF092F,stroke:#132440,color:#fff
                            

The model was simple: buy a server, install an operating system, configure the runtime environment, deploy the application. Each layer was tightly coupled to the ones below it.

The Limitations of Physical Servers

This approach had severe limitations that became increasingly painful as businesses grew:

Think of it like this: imagine buying a five-bedroom house for every person who needs a place to sleep. Each person uses one bedroom and the rest sit empty. That is exactly what physical server deployments looked like — massively over-provisioned and enormously wasteful.

The Virtual Machine Revolution

The first major breakthrough came with virtualisation. The concept had existed since the 1960s (IBM's CP-67), but it became commercially practical in the late 1990s with VMware's founding in 1998.

flowchart TD
    HW[Physical Hardware] --> HV[Hypervisor]
    HV --> VM1[VM 1]
    HV --> VM2[VM 2]
    HV --> VM3[VM 3]
    VM1 --> OS1[Guest OS]
    VM2 --> OS2[Guest OS]
    VM3 --> OS3[Guest OS]
    OS1 --> APP1[App A]
    OS2 --> APP2[App B]
    OS3 --> APP3[App C]
    style HW fill:#132440,stroke:#3B9797,color:#fff
    style HV fill:#16476A,stroke:#3B9797,color:#fff
    style VM1 fill:#3B9797,stroke:#132440,color:#fff
    style VM2 fill:#3B9797,stroke:#132440,color:#fff
    style VM3 fill:#3B9797,stroke:#132440,color:#fff
    style OS1 fill:#BF092F,stroke:#132440,color:#fff
    style OS2 fill:#BF092F,stroke:#132440,color:#fff
    style OS3 fill:#BF092F,stroke:#132440,color:#fff
                            

A hypervisor sits between the hardware and the operating systems, creating an abstraction layer that allows multiple virtual machines to share the same physical hardware. Each VM gets its own complete operating system, its own kernel, its own memory space, and its own virtual hardware.

Benefits and Trade-offs

Virtual machines solved many of the physical server problems:

• Better utilisation — Multiple VMs per physical server pushed utilisation from 15% to 60–80%
• Isolation — Each VM is completely isolated with its own kernel; a crash in one VM cannot affect another
• Faster provisioning — New VMs can be created in minutes from templates
• Snapshots and migration — VMs can be saved, cloned, and moved between physical hosts

But virtualisation introduced its own costs:

There are two types of hypervisors, and the distinction matters:

The Container Paradigm

Here is the single most important insight in this entire series:

This distinction is not pedantic — it is fundamental. Understanding it correctly changes how you think about security, performance, networking, storage, and orchestration.

flowchart TD
    HW[Physical Hardware] --> K[Host OS Kernel]
    K --> CR[Container Runtime]
    CR --> C1[Container 1
App A + Libs]
    CR --> C2[Container 2
App B + Libs]
    CR --> C3[Container 3
App C + Libs]
    style HW fill:#132440,stroke:#3B9797,color:#fff
    style K fill:#16476A,stroke:#3B9797,color:#fff
    style CR fill:#3B9797,stroke:#132440,color:#fff
    style C1 fill:#BF092F,stroke:#132440,color:#fff
    style C2 fill:#BF092F,stroke:#132440,color:#fff
    style C3 fill:#BF092F,stroke:#132440,color:#fff
                            

Notice what is missing compared to the VM diagram: there are no guest operating systems. Every container shares the host's kernel. This is why containers start in milliseconds (they are just processes), use megabytes instead of gigabytes (no OS overhead), and can run hundreds on a single machine (no hypervisor tax).

Virtual Machines vs Containers — The Complete Comparison

The analogy that helps most people understand the difference:

When you run a container, the kernel creates a set of namespaces (for isolation) and cgroups (for resource limits) around a process. The process sees its own filesystem, its own network stack, its own process tree — but underneath, it is just a process on the host machine. We will explore these mechanisms in detail in Parts 2 and 3.

# Prove that containers are just processes
# Run a container in the background
docker run -d --name demo nginx:alpine

# Find the container's main process on the HOST
docker inspect --format '{{.State.Pid}}' demo
# Output: 12345 (a regular Linux PID)

# View it in the host's process table
ps aux | grep 12345
# Output: root 12345 ... nginx: master process

That command shows something profound: the "isolated" nginx process inside the container is visible as a regular process on the host. It has a normal PID. It uses the host's kernel. The isolation is created by namespaces — a kernel feature that controls what the process can see — not by hardware separation.

A Brief History of Containers

Containers did not appear overnight. The ideas behind them evolved over decades:

Beyond Containers — The Full Progression

Containers are not the end of the story. The evolution continues:

flowchart LR
    A[Physical Servers] --> B[Virtual Machines]
    B --> C[Containers]
    C --> D[Orchestrated Containers]
    D --> E[Serverless]
    style A fill:#132440,stroke:#3B9797,color:#fff
    style B fill:#16476A,stroke:#3B9797,color:#fff
    style C fill:#3B9797,stroke:#132440,color:#fff
    style D fill:#BF092F,stroke:#132440,color:#fff
    style E fill:#132440,stroke:#BF092F,color:#fff
                            

• Orchestrated containers — Tools like Kubernetes manage thousands of containers across clusters, handling scheduling, scaling, self-healing, and service discovery automatically
• Serverless — Platforms like AWS Lambda and Azure Functions abstract away even the container, letting you deploy individual functions that scale to zero when not in use

But here is the key: each layer builds on the previous one. Kubernetes runs containers. Most serverless platforms run containers underneath. Understanding containers is understanding the foundation of modern cloud computing.

Exercises

1. Mental Model Check — In your own words, explain why a container is NOT a lightweight VM. What is the fundamental architectural difference?
2. Utilisation Calculation — If a physical server costs $10,000/year and runs at 12% utilisation, what is the effective cost per unit of compute? How does this change with VMs at 70% utilisation?
3. History Research — Look up chroot and explain how it provides filesystem isolation. What does it NOT isolate that containers do?
4. Hands-On Exploration — If you have Docker installed, run docker run -d nginx:alpine and then use docker inspect to find the PID. Verify it appears in the host's process list.

Conclusion & Next Steps

In this article, we traced the evolution of software deployment from physical servers through virtual machines to containers. The key takeaways are:

• Physical servers were wasteful, slow to provision, and difficult to manage
• Virtual machines solved utilisation and isolation but added OS overhead
• Containers are isolated processes (not lightweight VMs) that share the host kernel
• Docker's innovation was developer experience and standardisation, not the underlying technology
• Each evolution layer builds on the previous — containers are the foundation of modern infrastructure

Now that you understand why containers exist, it is time to understand how they work at the kernel level.