May 01

Being an Austinite, I enjoyed having DockerCon local and co-authored a guide to visiting Austin in the hopes that attendees would enjoy having DockerCon in Austin as well. During this installment of Dockercon, a few major announcements were made, including the Moby Project. So, what is the Moby Project? It’s a framework to assemble specialized container systems without reinventing the wheel.

The Moby Project is to Docker what Fedora is to Red Hat Enterprise Linux.
– Solomon Hykes, Docker CTO/Founder

In becoming the container project equivalent to the Fedora project, the way docker is built is changing. Red Hat did a good job in the early days of the RHEL confusion in that they delineated the project from product; they split Fedora from RHEL. Docker sees this approach as a way to better engage community. The boundaries between community and products were fuzzy before. People couldn’t necessarily tell when they are contributing to the project vs the product. This separation of code between the moby/moby repository and the docker/docker repository clarifies this distinction.

Moby will convert Docker from a monolithic engine into a toolkit to assemble its components into different configurations.  The Moby Project should encourage reuse of each of the components.  Docker has a history of success in this regard and can be measured in their reuse beyond their creator:

  • spun out OCI/runc and it is now the established standard for container runtime and image formats.
  • spun out containerd and it is now the de-facto industry standard for cotainer runtimes with contributions from all major cloud vendors and 99% install base (millions of nodes worldwide).
  • Notary has become the industry most mature implementation of TUF and a hub of collaboration for the security community.
  • Docker distribution is the open-source foundation for a dozen commercial products.

The Docker team is hopeful that as the Docker monolith is broken into smaller pieces, that these individual components may become building blocks for custom solutions. Previously residing in docker/docker, the monolithic project has been relocated to moby/moby.

Some confusion arose about the project. Contributors were well-communicated to at the conference and most of the maintainers, however, those more casually interfacing in the community were surprised and unclear about its purpose and impact, expressing frustration in not understanding  how the various pieces fit together or what the new features (e.g. LinuxKit) do.

The Moby project enables system builders to create other projects on top of the same tooling. A system builder may want to run these assemblies differently depending on whether they’re running on a small IoT device or if they’re running on a large system with GPUs. There’s still much work to break out components, however, the goal is to create one large upstream for Docker – that being Moby. Docker Inc. wants the tooling to be more open than Docker. Product design decisions are sometimes at odds with consensus-driven open source project. Having separation of concerns allows Docker Inc. to compile opinions on user experience into their community and enterprise docker offerings.

Moby is the project. Docker is the product. The project can be described in four layers:

  1. all the way upstream components
  2. Moby
  3. Docker CE
  4. Docker EE

The organization of the project into layers should assuage natural content that arises when decisions need to be made between what works for the project vs. product. Docker as a product will add opinions informed by their users (to be easier for their users). For example, containerd doesn’t have a default registry, while Docker will have docker hub as the default or the docker CLI providing a easy lookup open issues you have for your project in the docker support forum/system.

Users unaffected.
Users will still interact with docker in the same way.

  • Application developers who are looking for an easy way to run their applications in containers may look to Docker CE.
  • Enterprise IT who is looking for a ready-to-use, commercially supported container platform may look to Docker EE.

Nothing changes for these users. The command line remains the same. Docker can now leverage the ecosystem to innovate faster for them.

  • System builders who are looking to leverage components of the Moby project may innovate without being tied to Docker.

Project Governance
The Moby Project is open and will be a community-run project. Docker Inc. has a general inclination to donate individual components in this project to other governing bodies where appropriate. Containerd has to be stand-alone from the Moby org, because it was donated to CNCF. The notion Long-term individuals projects should eventually move out and go into other repositories.


      • Now that Moby is breaking up the monotlith, will languages other than Go be incorporated?
        • For LinuxKit – there’s a commitment to Ocaml and Rust. There’s no master plan to change languages.
      • Will REST be replaced with gRPC? – 
        • Docker Inc generally desires to leave REST API as constant façade, while moving internal communications between Moby projects to gRPC. A component can change languages and not have it affect other components (just like microservices provide choice). Engine has an HTTP REST API, all of the lower-level components have adopted gRPC. Solomon proposes to adopt gRPC as the standard interface. Benefit includes more automated tooling.
      • Where will you find Docker CE (the open source project)?
        • TBD – docker/cli will have the client libraries and SDKs for now. Packaging and building is edition-specific given that there are many Docker for XXX.


  • gabrielschenker

    Nicely written!