Container technology has become all the rage in the cloud computing field over the last few years for developers and other practitioners who use open source to build, test, and run applications. There is no doubt that open source communities like Docker, DC/OS, and Kubernetes provide a huge stage for developers. The level of openness has helped customers get the tech they need at the right price. However, people tend to ignore another pioneering work in the container field: standardization. This article describes the standardization work in container that Huawei has excelled in, and interprets its significance from the viewpoint of the industrial processes of container technologies.
Open Container Initiative: Cornerstone of Container Ecosystem Prosperity
In 2014, Docker started to focus on cluster management, overlay networks, and container image distribution in addition to Docker Container, and packed all the functions into compressed image files. Docker used its strong position to enter other fields, which promptly triggered a rebound from its former partner CoreOS, who moved quick to launch the App Container specification and its implementation rkt at the end of 2014, coming into direct competition with Docker Container.
The market split. Intel and Hyper also launched a VM-based container engine not long after CoreOS launched its own solution. Public cloud service providers such as Google and Huawei also launched their own container engines. Had the situation continued with everyone building their own environments, the container engine and image format would have become a serious headache for developers and customers. Containers would only have been able to contribute to the ecology when the standardization baselines were agreed upon by the players. If each company manufactured containers with different specifications, the linkage, scheduling, and metering of various containers would have become difficult, and the drawbacks may have very well outweighed the benefits.
Container technologies all faced the same problem during the initial stages. However, if no unified container engine or image format had come into place, the threshold would have been set high with one or two players dominating the market. Putting aside the argument as to whether each company would be able to venture out in the huge business and technical uncertainties, another danger existed: without unification, new alternative technologies could emerge and leave the container effort by the wayside. All the players stood to lose out big if they elected to propitiate technical divisions and in-fighting in the hopes of gaining more market share.
Figure : June 1 2015, Huawei and 19 other players formed OCI.
When Open Container Initiative (OCI) was formed, players came together to ensure the portability of container technologies. This laid the atmosphere for the entire sector. All ensuing actions and innovations would have to start with this mindset for it to become viable in the container technology realm. 20 entities, including Docker, CoreOS, AWS, Google, Huawei, and Microsoft, jointly established OCI under the Linux Foundation in June 2015, formally opening up container technology to standardization.
OCI focused on the standardization of container runtimes and image formats during its early years. Docker contributed runc to the community as the foundational runtime and then gained the support of Google, Huawei, Red Hat, and SUSE. Meanwhile, CoreOS, Docker, Google, Hyper, Huawei, IBM, Intel, Microsoft, Red Hat, and SUSE jointly established runtime spec and image spec projects. In addition to standardization, Huawei and Red Hat also contributed runtime and image tools projects to verify that container runtimes and images are compliant with standards.
Figure 2: Disputes arising from container standardization
Since 2015, OCI efforts have been repeatedly debated (as shown in Figure 2) regarding the scope, development, and compliance of container standardization. Eventually though, everyone reached a compromise and in 2017, the industry's first container standards (as shown in Figure 3) were released. The release yielded the needed portability amongst containers. Players in the container circle showed their commitment to comply with the OCI standard. Red Hat also launched its CRI-O project in CNCF, aiming to enable the Kubernetes management environment to directly invoke the container runtimes of the OCI community. In the KubeCon + CloudNativeCon held in Europe on May 2 this year, Google released a new security container technology that complies with the OCI standard, naming the solution gVisor. This product delivered a much different experience for developers and customers compared to the CoreOS’s release of rkt just a few years ago. Thanks to OCI, vendors no longer have to focus on rising above divisions in the market, they can focus on technological innovations to fill differentiated needs.
Figure 3: OCI announces industry’s first container standard
Evolution in container standards
After the first release of the OCI standard, CoreOS, Docker, Google, Huawei, IBM, Intel, Red Hat, SUSE, and other entities all agreed that the image distribution mechanism should also be standardized. Taking this approach would yield better portability in containers so that technology providers and customers could avoid being subject to using highly specific container engines and corresponding registry technology.
In addition to OCI, the CNCF community is also working on standardization. For example, the Container Runtime Interface (CRI) between Kubernetes and the container engine is defined, and the Container Networking Interface (CNI) and The Update Framework (TUF) specifications were initiated in the container network and security domains. In addition, independent Container Storage Interface (CSI) projects were also initiated. Huawei has played a huge part in the important specifications, working closely with industry players to ensure positive results. For example, now Kubernetes can focus on container orchestration and scheduling. Other players can innovate on container engines, container networks, and container storage based on Kubernetes – all of which are implemented through standard interfaces. Kubernetes uses CRI to connect to containerd, rkt, CRI-O, kata, or gVisor as the container engine. Customers can select Tigera, CoreOS, Weaveworks, or Huawei's container network solution that align with CNI specifications.
In addition to formulating specifications, the CNCF community released the Certified Kubernetes Program at the end of 2017 to ensure each player complies with community specifications, streamlining the relationship between standards development and certification. Currently, 32 platforms, including HUAWEI CLOUD, have passed the community's certification. This means that customers can use the compatibility tools together with the container services of HUAWEI CLOUD, solving interoperability problems while reducing lock-in risks.
Summary
CNCF and Kubernetes are visible battlefields in the container field. Issues about whether the architecture and modules are accepted by the community indicate the architecture and code capabilities of each participating company. However, the container industry should not overlook the struggles in standardization. It is the dedication of these companies and individuals that allow the container industry to have a stable cornerstone, be quickly accepted by the market, and move forward with the next big thing in their innovation.
