Why CoreOS and Docker's breakup was meant to be.

This article is translated from "", the original author Daniel Compton.

"Gretzky once said:" I always sneak to the point that the puck will reach, rather than chasing where it once was. ”

The controversy over whether Docker should expand the boundaries of the product to expand CoreOS's cluster management is also a direct result of CoreOS's development of its own container rocket to Docker potence. This phenomenon can be reasonably explained by the view of Professor Clayton Christensen's Book of Conservation of Modularity:

"according to our research, there is a phenomenon that when a product in the value chain is commercialized, while there is certainly a tendency for the current product to be non-commercial in the value chain, this interaction process means that when a new destructive wave washes over an industry, The ability to differentiate continues to shift in the value chain. When this happens, companies that have a value chain that is not sufficiently well positioned are able to profit "-clayton Christensen, sixth chapter: the Innovator's approach."

This is not new in the tech sector between Docker and CoreOS, which has happened in the early days of the development of the computer industry. When the ability to differentiate is constantly shifting in the value chain, there is a variety of confrontations between those who try to possess it. Like in a hockey game, there's always someone slipping to where the value is going to come from.

History will not repeat itself, but it is always strikingly similar. At first, mainframe development was always passable, so it was a big trend to design, manufacture and sell the whole. IBM has made most of its profits in the historical trend of integration, as its supply has been able to fill the gaps in the trend. A few years later, minicomputer and mainframes have developed sufficiently. At this time the profits were transferred from the integration resources of the entire machine, such as IBM and Compaq, to the manufacturer of each component: the operating system (Microsoft), the processor (Intel), the memory and the drive. Now it is time to integrate the resources of the business by filling the gaps in the integration of resources to obtain profits.

In the desktop world, processors and operating systems were less satisfying at first, so the value shifted and continued to improve. But memory and drives are less fortunate. When they developed well enough and were able to perform modular operations, profits were already carved out by the manufacturers of DRAM.

In the cloud services sector, the virtual machine services provided by cloud service providers have been sufficiently sophisticated and commercially successful by 2013. Development is not as human as the application of refactoring, deployment and multiple server management. A large number of tools such as Puppet,chef and Ansible emerged, but the performance of all the tools was no. Until the appearance of King Docker in GitHub broke the existing pattern.

In terms of modularity and integration, we can assume that Docker was designed to run synchronously on a stand-alone package and on any platform. Docker integrates operating systems, virtual machines, physical machines, and operations based on the above to commercialize. It also provides a series of APIs that enable others to operate based on these APIs. The part of the Docker that cannot be commercialized is the data center, and we will explain why this is particularly emphasized later on.

From a developer's point of view, the implication of applying encapsulation in Docker is that you can operate the entire cloud service as a module, where the module is just a product that can be substituted. The great thing about Docker is that you can arbitrarily migrate your application without making other changes. This is not good news for providers of cloud services such as Google, because the cost of migrating users has become very low. In this era, value is flowing from cloud providers that provide VMS to virtual environments to Docker.

The point of Docker for developers is that encapsulation applications need only Docker. It is expected that a large number of companies will soon be offering Docker-based, differentiated integration services. The most famous is undoubtedly CoreOS. CoreOS provides a separate Linux version service and container docker cluster machine services. CoreOS stripped virtual machines and container Docker and replaced it with a single cluster and a commercialized data center. The value is shifted again, from Docker to the services provided after the integration of Docker. Whether they admit it or not, CoreOS and its friends are a potential threat to other cloud providers: they want to commercialize cloud services and the integration platform they build on.

To feel such a threat, it is not surprising that a cloud service provider such as Google should adopt a strategy that adjusts its services to accommodate the development of Docker. Their services can be based on their own hardware platform and integrate Docker into their services to manage, which can make the value redistribution. But surprisingly, Google has launched its own container cluster management tool kubernetes. Until now, I still understand.

What's the last thing left to Docker? From the beginning he provided a modular component for use by other applications. This is of great value to other components, but it is of little value to Docker, because the process does not make a huge profit. Full commercialization is not a good way out, and certainly not a very high return for Docker investors.

So CoreOS will certainly treat Docker as an element of the composition of a commodity, and when Docker realizes its value but is being created as a tool by companies like CoreOS, Docker must not just stay on the OS level to provide value. For Docker, the only way out is to move up one level. Integrated Cluster services that are built and run based on Docker and managed are meaningful to Docker.

CoreOS is very concerned about this change, because Docker for them, among developers, is a huge potential competitor. The most natural response is to build a new container as a tool for gaming with Docker to support their own services. Rocket has a technical advantage in relation to Docker from birth, because it is coreos manufactured to withstand threats from Docker.

In the near future, cluster management will be fully commercialized, the value will flow elsewhere, and the cycle will be repeated. This trick is no different than playing ice hockey.

Original link: Why Docker and CoreOS ' split was predictable