There have been rumblings about a possible split in the Docker ecosystem. Now Red Hat has unveiled a project that may not be pitched as a Docker fork, but certainly has the makings of one.
The OCID project uses many Docker pieces to create a runtime for containers that can be embedded directly into the Kubernetes container orchestration system.
That version of the Docker runtime, Red Hat says, has been built for those who “need a simple, stable environment for running production applications in containers” — a broad hint that Docker’s “move fast and break (some) things” philosophy of product development has spurred a backlash.
Mother of invention
The technical details of OCID are not complicated. It’s a set of projects that provides Kubernetes with the ability to obtain and run container images by way of a version of the core of the Docker runtime, the “runC” project, that has been modified to fit Kubernetes’ needs.
Some of these modifications are purely practical, providing Kubernetes with features that are useful when running containers at scale, such as being able to verify if a current container image is the same as one found in a container registry.
Other features are more strategic variations on existing Docker functionality, with philosophical differences that stem from how Kubernetes is used in production. The OCID storage driver, for instance, “provide[s] methods for storing filesystem layers, container images, and containers,” according to Red Hat, but allows storage images to be mounted and handled more like Linux filesystems, instead of in-memory objects only known to Docker.
Fork in the road
Reading between the lines of the news release, there are strong hints that the OCID project arose because Red Hat found itself at odds with the pace and path of Docker’s development.
According to the release, work on the storage component of OCID was hobbled because “upstream Docker was changing at a rate that made it difficult to build off of.” Likewise, when Red Hat proposed remote examination of a container as a possible standard add-on, “the Docker community showed little interested in such a capability.”
Chalk this up to the fact that Red Hat and Docker generally aim for different audiences. Red Hat targets enterprises that want to run applications at scale by way of a whole gamut of tools: as its newly container-centric Linux stack, its OpenShift container platform (version 3.3 was released today as well), and its focus on Kubernetes as the mechanism for combining and managing things together. The sheer size of such a stack, and the demands made on it by an enterprise, mean it can’t be built on shifting sands.
What Red Hat wants
Docker, on the other hand, has been driven more by the enterprise developer than by the enterprise itself. It isn’t afraid to iterate quickly and assume its audience is agile enough to keep up. It has also been attempting to present itself as a one-stop, end-to-end solution for deployment.
Bundling Docker Swarm as a native orchestration solution, for instance, was meant to provide an out-of-the-box option to get a cluster running — and to give Docker users a reason to use Docker-native tools generally. But Kubernetes is making a case for itself, both because of its open-ended community and because people serious about scale (such as OpenStack) tend to turn to Kubernetes as a once-and-for-all solution.
It is not in Red Hat’s best interest to seem divisive, though. To that end, the announcement about the OCID is liberally salted with statements of open source goodwill: Red Hat wants to “drive broad collaboration” by contributing these tools back to the container ecosystem at large and by “engaging with upstream open source communities.”
But Docker is under no obligation to accept any particular pull request. And if Red Hat’s intention is to build a powerful container stack that’s distinctly its own, it will be all but obliged to diverge from Docker. The question is not whether Red Hat will do so, but by how much and to what end.
IDG News Service
Ltd
