Story of Meeting Docker: My Take on Docker's Edge

Docker is employed by developers to build containers for their code, which are then shipped to any locations, like servers or user devices, where the code will begin to do all those wonderful things it's intended for.

Why Should One Place Code Within Containers?

This is a great question. Sometimes even developers have a superficial understanding of it because not everyone encounters this line of work every single day.

Many people interpret it this way: inside each container, there is the necessary operating environment for code to work - and each has its own. In other words, containers isolate pieces of code with different environments from each other.

This is certainly true, but it's not the most important thing. If it were only about this - what would be the point of creating, for instance, several containers with completely identical environments? Yet, this is a common practice.

The main use of containers is to ensure the code is separated from the whale's back, following the Docker container metaphor.

You see, the software world changes every second. There are two reasons for this:

• First, developers want to train their code to address new tasks or improve its efficiency - essentially, they're making it better.
• Second, there's a security issue. Old software versions can't be used because they contain critical vulnerabilities that malicious actors will undoubtedly exploit.

This continuous progress is good news for users but bad news for developers. And you can't even imagine how bad it is for us. From the outside, it's hard to grasp in full all this pain and the depth of this issue.

In the new version of the environment, your code simply stops functioning. No more, no less. But do you have the time and resources to make it compatible? Will the customer cover the costs? They have plenty of alternatives to spend their money on.

Containerization comes to the rescue in this regard. A container shields the code from the ever-changing environment.

It eliminates any discrepancies between the cargo's configuration inside the container and the shape of the whale's back. Whether the cargo is round, triangular, or square, a whale can transport it in a container; otherwise, transportation would be impossible, just like in real cargo shipping by sea or rail.

Containerization Technologies Before Docker: Bazaar in Action

Every container technology Docker employs was known well in advance.

I was already making conscious and successful use of one of them in 2008, a whole five years before Docker's debut - it's like an eternity in the IT world. At the time, people referred to the act of placing code in containers as virtualization on the OS level, but the essence remains the same.

However, the process was way more effortful back then. I had to manually craft containers without any instructions to follow. I had to invent the process from beginning to end by myself. So, each container was like a piece of art - a unique product, and quite an expensive luxury.

Many of us got the idea to use pre-made containers as templates instead of starting from zero. Developers shared their containers publicly, and I made use of these resources. However, searching for the right container online remained a time-consuming endeavor.

There was a significant need for tools to automate container creation. I made them myself with OpenVZ that completely lacked automation. Notably, I encountered one of OpenVZ project leaders in the Docker team later, and it was no surprise to me. Most of such tools were open source, so let's explain what open source development looked like at that time.

Does the Bazaar Outdo the Cathedral?

Inspired by the open source movement, Eric S. Raymond in 1999 authored The Cathedral and the Bazaar, a book that has since become renowned.

There, he refers to the traditional, closed source software development model as the Cathedral, where software is developed under a centralized and hierarchical authority following a well-defined plan.

He contrasts this model with an open source development approach, where a decentralized community of independent contributors operate at their own discretion, creating a modular system. He calls it the Bazaar.

The author argues that the bazaar model is more effective, innovative, and resilient than the cathedral model. This is achieved by giving developers the freedom to experiment with new ideas and leveraging diverse inputs for rapid issue detection and fixing.

The development of open-source containerization technologies I mentioned was a quintessential bazaar. No rules. Everyone does as they see fit. The outcome was a variety of tools created by different individuals using distinct languages, which weren't made to work together and frequently don't.

Containerization With Docker: Back to the Cathedral

Docker didn't invent anything new, but it did something else that turned out to be surprisingly correct and impactful. Its creators merged the functions of all existing diverse tools into one solution. Instead of trying to make them work together, they started from the ground up, creating a new platform based on a centralized plan and control.

Essentially, they assembled a cathedral with what was on hand in the bazaar by adding just one missing piece, and that piece is the docker command known to almost every developer.

Docker Command

Docker is a versatile command that lets you handle any feature of this multi-purpose tool, which is extremely convenient. Here are its main capabilities:

• Enables the automatic generation of standardized containers

Every container is created with parameters and configurations set by the program, meaning it's all done according to a centrally established plan. This mirrors the cathedral principle that shaped the platform and the entire company. Do you find the same aesthetic enjoyment in this fractality as I do?

• Automates finding containers on Docker Hub, a free repository for users' container images

Docker provides its own official container images and supports them. Besides, it allows anyone to upload their created images to its cloud storage, Docker Hub. This enables you to take an already existing container as a basis and craft your own extension, markedly speeding up the development process.

It's fascinating that Docker Hub acts as a bazaar element, paradoxically integrated into the cathedral and exceptionally successful at it.

Using another user's container as a template, you can later upload your modified version on the hub, thereby contributing to the author's work. Such a possibility didn't exist previously. When developers shared their container samples online, they typically had neither the means nor the interest in gathering modifications from other users.

To Sum It Up

What makes Docker great can be be boiled down as follows:

Docker has brought code containerization to an exceptional level of convenience by automating the search for suitable container images and streamlining the process of their modification, all centralized in one place.

What's particularly noteworthy in the history of Docker is that it reveals how the bazaar model turned out to be unsuccessful.

That attractive image, which appeared so appealing - when enthusiastic developers pursue their ideas without any limitations, and their efforts naturally blend into a harmonious whole - it didn't endure the test of time.

And Docker demonstrates what an alternative could be. It's a cathedral that has managed to encompass and make the best use of all the advantages of open-source development.

Docker is an open source platform that offers free functionality, which is sufficient for the majority of developers' tasks. Thanks to this, it attracts a vast number of contributors who, in the best traditions of open-source development, simultaneously are:

• Firstly, free testers who serve up discovered errors to the company.
• Secondly, free developers who share their container modifications and ideas for problem fixing, or even directly contribute to the platform's evolution.

In this way, by leveraging the superpower of the open-source community, Docker quickly made its product extremely convenient and popular. And it employed this for monetizing selected features, which proved to be quite profitable.

This entire building is designed and constructed in a centralized and hierarchical manner, following the cathedral principle. The only element of the bazaar it contains is the Docker Hub. And in my view, it's only in such circumstances that a bazaar can operate effectively - when someone has assumed the duty of coordinating it.

It's in this that I see the essence of Docker's achievement and its success formula.

And it goes without saying that the history of containerization started well before Docker came onto the scene.

When I dabbled in Linux back in 2000, there were already efforts to isolate code from its changing surroundings. It was an idea in its infancy, without the now-common term "container," but containers were definitely around.

By 2008, as I was crafting containers myself, they had already become very much like Docker's versions. However, Docker was the one to make the process of containerization genuinely easy, swift, and cost-saving.

That's what I wanted to share with you, my take on the history of Docker. Does it resonate with how you feel about it?