The pace of Docker: DevOps and OS

Learn about Linux, please refer to the book "Linux should Learn"

The development of cloud computing over the past decade has provided new opportunities for the shared economy in the IT sector, and the rise of the mobile internet over the past five years has presented new challenges to it architecture in many ways. New challenges, new opportunities, and new vitality. For a time, new vocabulary such as Docker, MicroServices, DevOps, and lean research and development is rife with the entire IT industry in a relatively short period.
The development of cloud computing over the past decade has provided new opportunities for the shared economy in the IT sector, and the rise of the mobile internet over the past five years has presented new challenges to it architecture in many ways. New challenges, new opportunities, and new vitality. For a time, new vocabulary such as Docker, MicroServices, DevOps, and lean research and development is rife with the entire IT industry in a relatively short period. Infrastructure, the monopoly of giants, and the presence of technical barriers tend to limit the entry of people and discourage later. Faced with the continuous evolution of business requirements, the software provider's ability to respond, in the face of the opportunity to be tested.

is often the leader of the Times, first sniff to the brewing before the historical change. We generally see: the timing of the new ideas always seem a little playful, but also not yet aggressive. Behind the thought, we can always find: Some companies are doing those who are surprised by the nature of the attempt, they are radical, they open up, they from 0 to 1. Docker The company is not a big deal in this.

So far, history has given Docker more than three years of time. Over the past three years, Docker has used "build, ship, run" as the company's purpose, which is to help users build, publish and run any application.


By summarizing Docker's three years, it is not difficult to discover the pace of Docker:
The first year, focus on software construction, docking to build downstream, to create a mirror ecosystem
Next year, service container management, release scheduling platform, build delivery process
The third year, the integration of enterprise resources, improve the platform function, start to apply the orchestration

Now, in the second half of the fourth year, to Decipher Docker, we will find that the development of Docker seems to be in addition to the application of "Build, ship, Run", but also in two areas of efforts a little "Shattered Glass":

Advancing the DEVOPS process
Managing capacity toward OS

Docker pushes DevOps
DevOps in IT is a culture that emphasizes collaboration and communication between development teams, operations teams, and other teams in order to achieve a fast maturity of software products and a safe and controllable system. From the purpose of Docker, the idea of DevOps seems to match, and Docker is fully capable of accelerating and guaranteeing the software's life cycle. From these years of industry development, Docker, as a tool, is indeed helping companies implement the DevOps philosophy, while also leveraging the tool's polished, visual value to promote devops in larger groups.


It is a cliché to say that the DevOps value of Docker is still described in terms of software build, CI/CD, etc. If you follow Docker's latest developments, you won't miss the explosive news of Docker native integration orchestration. Rumours and speculation about the controversy over orchestration and the division of container ecology were rife after Dockercon 2016 released the news. In my opinion, orchestration is just a form, and Docker expects more DevOps than that, and so does the current movement.

Native integration Orchestration

Docker launches Swarmkit, native integrated orchestration capabilities, and I believe it's a less-than-friendly message for other distributed platforms that target container orchestration, such as Kubernetes,mesos+marathon. A tool, a manufacturer, with a large number of user groups in the container ecosystem, drastic, intercepting the north to the ecology. At first glance, that's true, but if you look at the problem from a DevOps perspective, you might get a different harvest.

DevOps is a new cultural concept, driven by the large and small value of devops, which is often difficult to measure, and tends to be simply contrasted with existing curing processes. PAAs, people are used to connecting DevOps, and from the effect, the existence of PAAs does greatly simplify the management of the traditional operations personnel for the post-application, so similar to the Kubernetes and other platforms are really popular with the traditional operators, release operations seem to see the dawn.

However, returning to DevOps, the term exists, and the beneficiaries are more than "ops". There is also value for developers. Perhaps some people say: that does not mean that the developers will take more work, to involve the operation of the dirty work, hard work, dirty it? If it is a traditional IT architecture, there is not enough tools to help, I am afraid, or DevOps is not a difficult one.

Now, in the world of Docker, a lot of things seem to be simple enough. After solving the problems of network, storage, security and so on, Docker's Swarmkit help Docker greatly reduces the user's use of containers and the threshold of DevOps. So far, most of the enterprise internal software delivery, often involves three departments: development, testing, operation, three indispensable. Docker's ideas are much simpler than imagined, and strive to be the most minimalist at the tool level, with just one tool for development, testing, operations, and more. If only the resources that developers occupy, Docker can provide a complete "end-to-end" tool chain, the engineer can be easily qualified for the DevOps role. Development engineers, in the development process into the concept of operations, with the power of Docker tools, through the software life cycle of the entire process. The development and deployment of Docker brings the environment consistency and the completeness of the orchestration function, which will greatly reduce the communication cost and resource cost within the team. I think it's so obvious that value-orientation is impossible to turn a blind eye to when it makes decisions within the enterprise.

DevOps is not confined to the operation of the PAAs, the ability to liberate the application operations compared to the large PAAs platform, whether there will be the cart before the horse, everything is still unknown, at least Docker this lightweight, most convenient integration approach to DEVOPS provides a new way of thinking.

Development Drive Monitoring

Docker is a lightweight way to achieve the user's needs for orchestration. Appearances seem to be glamorous, but we might as well think about the current general arrangement. Will it be found that the orchestration, similar to the Kubernetes and Swarmkit, focuses on the runtime management of the application, if limited to the runtime, limited to the application operations, the lack of input from the source of the development, the gap between development and operation is still impressively in the eye, a little bit, no change whatsoever.

The traditional PaaS platform, such as Cloud foundry,openshift, can be used to manage the operation of the application basically. However, the life cycle of the application is often more complex than this, and subsequent monitoring, coordination, scheduling, and failure recovery are all challenges that need to be overcome. These are in the traditional enterprise, there is no doubt is the operation of the errand, out of the problem has not been avoided the retrospective development staff. If, in the context of a traditional PaaS, the lifecycle of a software can be more influenced by the DevOps culture, it can greatly reduce costs. As a simple example, in the traditional PaaS and container orchestration platform, the monitoring of the application is often difficult to achieve a universal standard. For some applications, the platform general monitoring is not too granular, as if ineffective, is to provide fine-grained monitoring is not targeted at the user's pain point, appears to be opposite. Operation and maintenance personnel in the design of monitoring, can not be used in a common way to complete the application of "personalized" requirements, therefore, the trade-offs are inevitable.

If you are concerned about the latest Docker 1.12, attentive people may find:

Dockerfile begins support for new command Healthcheck, completing user-specified application health checks
Docker's move, seemingly casual, actually flat see thunder, one at a stroke to bridge the development and operation of the gap, at least in the field of application monitoring. Docker has released the pressure on OPS, but the first step in Docker is to Docker, or Dockerfile, which is naturally a developer's category. In addition, for the personalized monitoring of the application, I think no one is more aware than the developers of the application, if it is up to the application developer to take on this part of the definition, it is entirely a happy thing to do. Since then, the development process is to complete the definition of application of custom monitoring, through the unified architecture provided by Docker monitoring, operation and maintenance link monitoring will not be so stretched.

It can be said that at the beginning of the Docker 1.12, it provides a new opportunity for application monitoring, bridging the gap between development and operations, and opening up the two sides of both, which is often the traditional PaaS platform, the container orchestration platform can not be reached.

Docker toward OSOf
Kubernetes, Mesos and other platforms, after the birth of a review of the past one to two years, as if the entire ecological subconscious has a subconscious: the container ecology is divided into a double layer, container engine Docker as a management tool, as the bottom, simply serve the container; Orchestration platform of the Kubernetes or Mesos, as the upper tier, meets the needs of application orchestration. I also once thought that Docker is bound to go to the upper, Couch side, not allow others snore sleep. However, Docker's move was a surprise, and the strategy was to take Docker to the OS.

Since the birth of Libnetwork, Docker seems to have conveyed a message that the power of a third-party tool is not the only way to leverage the power of the kernel.

Since the popularity of Docker, there are still unsolved mysteries in the face of traditional methods of resource management. If, for the moment, Docker is leveraging the kernel's VxLan capabilities to mitigate or solve the network challenges of the Docker container world, there are still problems in the internal architecture of the enterprise, such as storage, such as load balancing. The problem is to solve, but in recent years, the development of enterprise application, in the choice of the underlying soft and hard infrastructure, often more than the trust of more basic operating systems (Operating System,os), in the process of running with the upper cloud platform, more or less acclimatized. As a result, Docker management capability is not difficult to understand. The future direction of the container is likely to break the boundaries between traditional IaaS and PaaS and go back to the broader cloud OS-level transformation.

Global Storage

For applications, the importance of data is self-evident. The separation of compute and storage has always been the most desirable method of data management for Docker, and for the unified management of storage, Docker has not given a convincing solution, but the ecosystem is similar to Clusterhq,hedvig and other companies in the field. However, this is not to blame Docker, after all, it is not Docker's strengths and main business.

Docker could not close the storage market of the container ecosystem, and this effort, we can see from the Docker abstract storage concept (Docker was born, there are only two levels of container and mirror concepts, and over time, Docker abstracted additional storage volumes (Volume) and networks, As a level concept, parallel management).

Having experienced a single-machine storage volume over the past 3 years, Docker 1.12 Now introduces a global storage volume, native to support data volume sharing in a clustered environment. In addition to Dockercon 2016, the Docker official demo manages distributed data in a clustered environment with NFS. The container ecosystem has reason to speculate that Docker is not a blind eye in storage, but rather likely to plunge into the storage ecosystem with the ability of OS OS.

IPVS Load Balancing

Today, most enterprise-class applications no longer have only a single instance. The situation of multi-instance can often avoid many problems, such as single point problem, load balance problem and so on. In the world of Docker, the expansion of containers has never been a new topic. For the extended application container, the registration of the service and the discovery by WHO to complete, has not been a conclusion. The Kubernetes platform is dedicated to the introduction of a platform routing component to accomplish this part of the work. Because of the network mode and platform routing component of Docker in the collaboration, there will be more or less acclimatized, performance and other aspects of loss, it is difficult to achieve the "1+1>2" effect.

New version of Docker 1.12, when you orchestrate your application, you can use Linux IPVS to complete service registration and load balancing. Perhaps the immediate benefits of this initiative will be:

No additional configuration, deployment, and management required with kernel capabilities
Significantly improve load-balancing performance
Native support for multiple transport protocol load balancing capabilities (TCP,SCTP, UDP, etc.)
Boulevard to Jane, if the underlying technology stack, such as the Linux kernel, itself can provide load-balanced management capabilities, OPS people have no reason to install an additional load Balancer module, expensive configuration, management, and operating costs are the points that team decision makers have to consider. In addition, IPVS has advantages over nginx/haproxy, such as support for UDP, multiple load balancing strategies, and health checks.

Summary
I think it's best to use "explore" to describe the current Docker in a new area. With a global focus on software delivery, Docker's contribution to the DEVOPS philosophy cannot be underestimated. In the face of cloud computing infrastructure and platform architecture, the idea of Docker may be more OS-oriented, moving toward Cloud OS. However, as one of the world's hottest startups, Docker's vision and variety of speculation will gather in this interesting whale. We'll see what the future holds.

The pace of Docker: DevOps and OS