Why Docker Took Over: The Real Reason Containers Won

MahesMahes
7 min read

I know, you want to know about why docker became famous, but before going into that let me tell you all a…

Philosophy

Anything in this world that isn’t recognised by many people will be forgotten and eventually vanish.

You might be thinking, “What is this crazy dude saying? Some random philosophical nonsense?” But hear me out. If we apply this idea to software, things start to make sense. Just replace “Anything” with “Any software

“Any software” in this world that isn’t recognised by many people will be forgotten and eventually vanish.

Still not convinced? Let me rephrase it again:

Any software that is recognised by many people will not be forgotten and will become famous.

Take something as simple as your phone’s Contacts app. It’s so common that we almost forget its software.

  • Why did we start using the contacts app?

  • What did people use before this?

  • What problem does this app solve that makes it indispensable?

All the answers to these questions helps us understand why the application “Contacts” becomes essential.

And that is exactly what this story is about!
(Except it’s not about contacts but about containers.)

What is a container?

The first thing that comes to our mind is shipping container like the one in the below image.

📷
Photo by nikko osaka on Unsplash

We all know the purpose of the shipping container. It packages all the things that should be shipped from one place to another place so that everything will be sent there and no individual things will be lost.

Containers in software does the same thing. It packages the code and dependencies (libraries, all sorts of file that are needed to run the code) into one single package called image and ships them.

The application that does this job is called container Application or containerization platform.

There are may such applications the notable ones are

  1. Docker

  2. podman etc..

What did people use before Containers?

There were three generations of methods people used to install software, each with its own drawbacks that led to the development of the next generation. Let's look at them one by one.

First Generation:

The first generation people used to directly install their software in the System / Server.
The Architecture of such system should closely resemble what is given below.

Lets see this layer by layer

  1. We have Hardware layer which includes all types of hardware but for our case let’s consider processing and storage.

    1. processing includes - CPU, GPU

    2. storage includes - RAM, ROM (ie., SSD / HDD)

  2. The next layer is the Kernel, which is responsible for communication with the hardware, telling it what should be done and how it should be done.

  3. Since the kernel is difficult for regular people to use, it is wrapped with a user-friendly layer called the OS (Operating System), which is easy to use.

  4. Then comes our Application, App1 and App2.

  5. Each application needs some other application as dependencies called libraries which are denoted by lib1, lib2…lib6.
    *Note that lib3 and lib4 are used by both the applications.

Drawbacks:

  1. Many applications used same libraries in the backend but required different versions of those libraries like lib3 and lib4 used by both App1 and App2 but App1 requires v1.1.5+ of lib3 and App2 requires v1.0.5+ - In short Dependency conflicts.

  2. There was one more issue with the dependencies. During the development process the developer might have used different version and there might be some initial setup done to make it work which they were not able to properly replicate again during the installation in production, which causes issues.

  3. There is no control over how much resource(Processing and storage) an application can consume. A high resource consumption of a low priority application affects the performance of a higher priority application when it is needed.
    Say App1 is high priority which should be up 99.9% and App2 is low priority and 90% of up time should be enough. But somehow App2 consumes more than 70% of the resource leaving App1 with only 30% which is not enough.

Second Generation:

The drawbacks of the first generation were addressed in the second generation with the introduction of virtualization. Simply put, virtualization is like simulating(not physically present) a computer within another computer like below.

We have the layers same as first generation till the OS and after that we have a virtualization software.
This virtualization software creates a isolated environment and assign virtual hardwares from the original hardware layer to the environment and this environment then can act as a separate system.

This environment with the virtual hardware can have kernel, OS and installed with application and its dependencies.

This whole setup is called Virtual Machines. It is a mini version of a system inside the system. the vm created inside thinks it is a separate system and runs like that.

Each application is installed in separate virtual machines and they have their own hardware setup and libraries.

As you can see it solves drawback 1 and drawback 3 faced by First generation. Drawback 2 is still present but 2/3 problems getting solved is a major achievement and people started using it.

Drawbacks:

Yes, it solves the first generation's drawbacks, but it has its own issues.

  1. First the Drawback 2 of First generation still exist - setup and dependencies in developer system is not followed properly in production

  2. Even though we have control over the resource allocated to each VMs the resources are not fully utilised.
    Let's say we allocate 2GB of RAM for a low-priority application, App1, in VM1, and 4GB of RAM for a high-priority application, App2, in VM2. App2 uses all 4GB of RAM without any performance issues, but App1 only uses 1GB of RAM. The remaining 1GB is free but cannot be used by other applications, like App2, which could benefit from it to improve performance

Third Generation:

This is where the Container comes in, solving all the open problems as of now.

Container are almost same as Virtual machines except instead of virtualising the hardware layer in the virtual machines, Containers virtualise the OS layer making it run like one of the process in the physical system itself.

To achieve that Container use a concept called cgroups and namespaces. We dont have to explicitly provide the CPU and RAM and storage even though we can, but the whole setup is packaged as something called image and the image runs as a process and that process is isolated to what files it have access, so all the required libraries are accessible only to that application. All such images are isolated in the same manner.

Lets see all the previous problems and how it is solved by containers

  1. 1st gen: Drawback1 - Version conflict between libraries used by many applications.

    Each application is packaged into one image and these images are isolated between each other so App1 will be one image and App2 will be another image having their own dependencies in their own image itself - Hence solved

  2. 1st gen: Drawback2 - setup not done properly when moved to another system.

    During the development process itself the image should be created by providing the actual steps in order to run the application in a file called Dockerfile which have all the layers from the os to command to run our application. This Image is a single object that will be shipped to the another system so if the image works in developer system it should, it will work in other system as well.

  3. 1st gen: Drawback3, 2nd gen: Drawback2 - control over resource.

    There is not lock in of resource by container as they run just as another process in the system but still we can restrict to how much of resource should be consumed. But this is just to restrict the usage beyond some limit and if the consumption is below that the remaining resource can still be used by other processes. like I am restricting App1 not to use beyond 1GB RAM and right now it is using 500MB the remaining 500MB can be used by other processes.

End Note:

I hope this helps you understand clearly why containers became popular.
Feel free to comment, like and follow.
See you in the next Article.

Please Support by subscribing to my Tamil channel - A Coder’s Vlog

0
Subscribe to my newsletter

Read articles from Mahes directly inside your inbox. Subscribe to the newsletter, and don't miss out.

Written by

Mahes
Mahes