Introduction to Containerization

In this article, I’m going to give some background to containerization.

In The Beginning

When I started in IT back in the, *ahem*, we were slowly growing racks of servers & PCs in our machine room. The problem, however, was that most of the time they were idle. We couldn’t merge them as the software they were running got unhappy if they didn’t have exclusive control of the operating system. With some work you could force some applications onto the same machine, but it was fragile and external support never liked it.

So we had racks of machines burning electricity doing very little most of the time.

And then we started running out of space in the racks in the machine room. Getting more machine room space was cost prohibitive. (We’d already knocked through to the adjacent rooms!)

We looked at very small form factor servers (e.g. four or more mini servers in a 1U chassis). Great for space but the spaghetti was crazy.

We also looked at mainstream blade systems. Less of a cabling issue (Well, except the higher power feeds needed for them) but the costs were high compared to standard servers. Plus you had massive vendor lock-in. Buy a HP blade chassis? You can only use HP servers.

Then we were introduced to VMware and its virtualization software.

In computing, the adage that nothing is new, just a rehash, is once again proven in the area of virtualization.

Whilst VMware’s virtualization came to prominence in the naughties, it’s a technology that IBM first pioneered in the 1960s.

But what is virtualization?

Virtualization is the method where software called a hypervisor can carve up a computers resources (CPU, memory, disk, etc) into many virtual computers. On each of these virtual computers (called virtual machines, abbreviated to VMs), you install your operating system (Windows, Linux, etc) If the hypervisor is doing a good job, the operating system thinks it’s got a computer all to itself. It won’t know that it’s running on the same CPU as other operating systems.

Suddenly, a single 1 or 2U server could replace many physical machines. This saved not only the cost of purchasing the hardware, but also electricity & cooling costs. One downside, however, was the cost of the hypervisor. VMware is not a cheap solution. But a VMware licenses for one physical computer (called a host) is substantially less than the cost of half a dozen physical computers. And when you end up running 20 or more virtual computers on that one host, the cost pendulum swings back in VMWare’s favor.

But there was another unforeseen problem with virtualization: The ease of creating a virtual machine. With virtual machine systems such as VMWare, you could create templates for virtual machines and spin up a new instance of a machine (complete with operating system and applications) in seconds.

This lead to patching & licensing hell. Keeping track of all the virtual machines and making sure they were patched and the installed operating system & applications were licensed correctly.

Once system administrators got a handle on the patching and licensing problems, another problem appeared. Every time you wanted a new application, you had to spin up another full operating system, even though you were only going to use a tiny fraction of it. You now had lots of virtual machines eating CPU, memory & disk just to run an application.


The next step in virtualization is where the operating system kernel creates virtual user space environments. One of the early versions of this system is the chroot jail feature in many unix variants.

Although there are many versions of this containerization feature (chroot jails, Solaris containers, OpenVZ, etc) we’re going to be looking at the Docker containerization system.

Apart from leaner systems (and being the latest IT fad!), what other reasons are there to use containers?

In my experience, there are several reasons to favour containers.

Firstly, it forces you to keep your application & configuration clearly separate from the operating system. This separation then makes updating the base (e.g. operating system of the container) much simpler.

The leads on to another reason: Upgradeability. It is trivial to update the core for the container as there is clean separation between your application and its operating environment.

My final reason is deployability. It is easy to develop software on your local workstation and then deploy it into production. No need to worry about your server and workstation running different operating systems or versions. Your container configuration specifies exactly what versions you’re going to use – and it’s the same as you’ve developed on.


  • There is nothing to stop containerization systems running on top of virtualization systems.
  • In around 2018, IBM announced the release of an ultravisor: A hypervisor to run hypervisor. It’s turtles all the way down…

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s