Grape City provides developers with professional development tools, solutions and services to empower developers.

In previous articles in this series, we looked at the evolution of PaaS platforms from Cloud Foundry to Docker. Today, we will continue to introduce the reasons for Docker’s desolation and the beginning of the era of great navigation.

Commercialization of Docker

In the previous article, we mentioned that the Docker project instantly became popular with its innovative Docker Image, so many merchants also found business opportunities and launched their own container products one after another, hoping to get a share of the market. CoreOS has launched Rocket (RKT) Container, and Google has opened its own Container project LMCTFY (Let Me Container That For You). However, even Google is unable to withstand the strength of Docker project. Therefore, Google planned to cooperate with Docker, shut down its own container project, and maintain the open source container operation together with Docker. However, Docker strongly refused such cooperation, which would obviously weaken its position.

At this time, Docker also realized that it was only the behind-the-scenes hero in the cloud computing technology stack and could only serve as the carrier for the final deployment of applications on the platform. But to be at the heart of the field, you should have your own PaaS ecology. After Docker exploded and had sufficient funds, Docker began to buy and expand its strength frantically, among which the most famous one was named FIG. Fig is the predecessor of the famous Docker Composer project. Through these acquisitions and iterations of its own research and development, Docker finally launched its own three-piece PaaS suite: Docker Composer, Docker Swarm and Docker Machine. Here is a brief introduction to the contents of Docker’s three-piece package:

1. Docker Compose: The predecessor of Compose is an open source project called FIG, which is a Docker container choreographer maintained by only two people. Its functions are: If the user now needs to deploy an application A and A database B and load balancing C, FIG allows the user to define the three ABC containers in A configuration file and specify their relationships. Finally, you just need a single command to use Fig Up.

During the Docker fire, the FIG project became as popular on GitHub as Docker, so in 2015, Docker acquired it and renamed it Docker Composer, which has been used ever since as a composing tool for Docker containers.

2. Docker Swarm: Swarm is Docker’s cluster management project, and its main logic is similar to that of Cloud Foundry in the previous section. It can be used in a command-line manner similar to Docker Run My image. I run Docker as a cluster and manage it by using my image of the Docker Run-H API. Swarm upgrades Docker projects from a normal container to a PaaS platform.
3. Docker Machine: Machine is probably the least known of the three Docker pieces. Its function is to run a virtual Machine as a container, and it can manage the virtual Machine in the same way that Docker containers are managed.

OCI’s “inaction” to CNCF appears

On the road of development, Docker has always maintained the absolute authority and voice in the development of Docker open source project, and has challenged the interests of other players with practical actions on many occasions. On the other hand, Docker’s commercialization path has seriously hurt the interests of its former partner, RedHat. In addition, Docker showed various unstable breaking changes in the high-speed transformation representatives in 2015, which began to make the community complain.

There are a lot of people who are popular, not to mention Docker stealing everyone’s cake. As a result, several other players in the container space began to talk about “cutting” Docker. Finally, Docker bowed to the pressure and on June 22, 2015, led a consortium of companies including CoreOS, Google, and RedHat to form a neutral foundation and donate its container runtime, LibContainer, renamed Runc. Based on RUNC, the foundation has jointly developed a set of standards and specifications for containers and images — OCI (Open Container Initiative).

The creation of OCI means that the implementation of container runtimes and mirrors is completely separated from the Docker project, making it possible for other players to implement their own Docker runtimes without relying on Docker.

However, since the foundation was only Docker’s compromise to these large companies, and it did maintain a large enough number of communities at that time, Docker had no fear of establishing the foundation, and did not care about the formulation of standards. Under the environment at that time, Docker’s own implementation had become a unified standard in the industry.

Because the OCI Foundation has been slow to grow, leading infrastructure players like Google and RedHat have played their trump cards, Together they led a Foundation called the Cloud Native Computing Foundation (CNCF) (which was the first time the concept of Cloud nativeness had been introduced to the public). CNCF Foundation was founded on the basis of Kubernetes project to establish a platform-level community led by open source infrastructure vendors and operated in the manner of an independent foundation, to counter the container business ecology with Docker as the core. It was with this foundation that Kubernetes, the hero of our second section, began to emerge.

The emergence and development of Kubernetes

Kubernetes is an open source container infrastructure choreography framework released by Google back in 2014. Unlike other brainy technologies, Kubernetes’ technology is based on a theory, namely: Borg. Borg is a part of the entire infrastructure system of Google, and Google has also published several papers on Borg as its theoretical support. It hosts industry header technologies such as MapReduce and Bigtable. As a result, the Borg system has long been known as Google’s most powerful “secret weapon”, but also Google’s most unlikely open source project, and Kubernetes is based on this theory. Below is a description of Google’s publicly available infrastructure stack as described in the Google Omega paper.

Open source vs closed source

Facing the appearance of K8S, a container war between Docker and K8S has started.

At the beginning of this confrontation, the Kubernetes project was called the “high and low” when it was first released, due to the fact that Kubernetes was inspired and designed by Borg. The idea was too far ahead of its time for developers to understand, and since the Kubernetes project had been maintained by Google engineers, it didn’t gain much traction or growth when it was released.

However, the formation of CNCF changed all that. RedHat’s strengths are a mature community management system and enough engineering capabilities to allow Kubernetes to grow rapidly in the hands of the community, and gradually to compete with Docker. And different from the closed business model of Docker, Kubernetes takes the opposite approach to open source and democratization. Every important function provides users with customisable interfaces, and ordinary users can also pull and modify the code of Kubernetes without permission. There are specialized reviewers and Approver in the community. As long as the code you write has passed the code review and approval through PR, it will become the backbone code of Kubernetes, which greatly increases the vitality of Kubernetes. Moreover, relying on the open interface, open source projects and plug-ins based on Kubernetes can be found everywhere, and relying on the excellent architectural design, emerging technical concepts such as micro-services are also quickly implemented, eventually forming a stable and huge ecology.

Docker, which can only be modified by its own engineers, is a far cry from Kubernetes at this point.

To sum up:

In the face of the rise and growth of the Kubernetes community, Docker has to admit that its big bet has failed. Starting in 2017, Docker has donated some of the Docker project’s Containerd Runtime to the CNCF community. In October of that year, he announced that Kubernetes would be included in the Enterprise version of Docker, marking the end of a container choreography battle that had lasted nearly two years. In January 2018, RedHat announced that it was buying CoreOS for $250 million, and in March 2018, Docker’s CTO Solomon Hykes announced that he was stepping down from the company that started all of this, and the world became one.

conclusion

This article explains how Docker became the focus of the PaaS platform, and how it was replaced by Kubernetes. In the next section, we will continue to explain how Kubernetes, in addition to the community, has reduced the dimension of its container choreography technology against Docker, so stay focused.