I. The Beginning
1.1. Chaos
In ancient times, when heaven and earth had just been separated, a group of people called “operations” spent every day creating their own world inside a mysterious box called a “server”. In that world they labored daily, writing their history over and over, for example setting up an nginx, deploying a java web application…
Most people aren’t actually that clever. What they “created” may in fact be something someone else had already created, and they probably did the same repetitive work every day. Over time, some grew tired of it, exhausted… After a while longer, some deeply skilled old-timers created batch deployment tools to help people with some of the repetitive labor. These tools were named “Asible”, “Chef”, “Puppet” and so on…
But as the times advanced, the “world” became more and more complex, and the operations people had more and more to deal with, such as isolating all kinds of network and disk environments, high availability for all kinds of application services… In the flood of the times, operations people urgently needed a simple and efficient deployment tool that offered a degree of isolation, was convenient to use, and minimized repetitive labor to boost efficiency.
1.2. Genesis
In the surge of the times, a man named “Solomon Hykes” rose to prominence. He created a tool called Docker, and once created, Docker showed operations people its power with world-ending force. An operations person with a combat power of just 5 could, after a very short time learning Docker, accomplish what only senior operations people could do before. In some cases work that used to take a whole day could be finished in a few minutes with Docker. At this point operations people realized that a “new era” had begun. Docker then went open source and was used by the entire operations world, and Docker kept improving and adding all kinds of features. From then on the world formally entered the “Container Era”.
II. Strife
2.1. Development
As Docker matured day by day, some people began creating more powerful tools on top of Docker, while others began providing a more stable runtime environment beneath it…
One of them, a company called Google, built a tool named “Kuberentes” on top of Docker. Kubernetes manipulates Docker to accomplish more complex tasks. Kubernetes’ emergence further confirmed Docker’s power and the correctness of the “Container Era”‘s direction.
2.2. Ambition
Of course this is a world full of profit. Google’s creation of Kubernetes could bring them benefits, for example they could make Kubernetes deeply adapt to their cloud platform, thereby increasing cloud platform sales and so on. At this point Docker’s founder also set up a company, offering paid Docker services and deep customization and so on. It’s worth mentioning, though, that the paid services offered by the Docker company never brought in as much profit as Kubernetes brought Google, so driven by profit, the Docker company started getting crooked ideas: create a replacement for Kubernetes, use user stickiness to replicate Kubernetes’ success, and snatch this piece of cake right out of Google’s mouth! At this point the Docker company only wanted to grab the cake, but they never noticed that a group of people in the shadows had created something called “rkt” that was also trying to take the cake from their mouths.
2.3. Conflict
After a period of silence, the Docker company created another tool called “Swarm”, attempting to take away the cake Google had won with Kubernetes. Of course, Google is an extremely large company with a huge headcount and enormous influence in society…
Finally, the giant awoke. Google joined forces with Redhat, Microsoft, IBM, Intel, Cisco and others to decide on sanctions against this mischief-loving Docker company. Of course the means of sanction couldn’t be too violent, since that would give others a handle against them, become a laughingstock, and be despised. In the end they decided to draw up specifications and form an organization, explicitly defining Docker’s role and the capabilities it ought to have. These specifications included but were not limited to CRI, CNI and so on. From then on the major companies announced that their container-related tools would only be compatible with CRI and other related standards — whether Docker or rkt or any other tool, as long as it implemented these standards it could be used together with these container tools.
III. Success and Failure
From then on, Docker fell from its altar. All sorts of experts created tools satisfying CRI and other specifications to replace Docker. Docker lost its former dominance, and eventually, to keep up with the times, split itself into modular components. These modular components were placed in mobyproject for others to reuse.
To this day, although Docker is no longer what it once was, it is still the first choice for containerization, because Docker is a complete product that offers more convenient features beyond merely satisfying CRI and other standards. But the sanctions did bear fruit: Google took the opportunity to create cri-o to satisfy the CRI standard, and other companies correspondingly created their own CRI implementations. To further split Docker’s forces, a tool called Podman was created; built on cri-o and compatible with most Docker commands, it began poaching Docker users. So far Podman can already replace Docker in most of its functionality.
Original article: https://mritd.me/2019/06/26/podman-history-of-container
