Moby makes container system assemblies part of open development

Extracting a component does not eliminate the work of integrating it with other components. A container runtime can be reusable while each platform builder still repeats the work of assembling a complete system around it. Docker's Moby announcement addresses that second level of reuse. The project is meant to make combinations of components available for development and experimentation alongside the individual components.

In the 18 April announcement, Solomon Hykes connects this problem to Docker's own platform editions. Supporting different desktop, server and cloud environments required teams to share more than individual libraries. They also needed to share assemblies. The announcement turns that internal production concern into a proposed model for wider open source collaboration.

I regard Docker's repeatable image construction as its central contribution to application delivery. Moby applies a related concern to the container platform itself. A system builder needs to know which components form the system and how to assemble them, just as an application builder needs an explicit description of the environment being shipped.

Component extraction leaves integration work behind

The announcement describes an earlier move away from a monolithic codebase toward independently reusable projects. It names runC, HyperKit, VPNKit and SwarmKit among the components extracted during that process. Containerd is another example. These projects have distinct jobs, so reusing one does not require adopting every part of the Docker platform.

That approach solves a code ownership and reuse problem. It does not automatically provide a tested combination of components for a particular host environment. The person assembling a system must still choose implementations and connect them. As the number of target environments increases, repeating that integration work becomes a production problem of its own.

Hykes says Docker created a dozen editions specialized for platforms including Mac and Windows desktops, Windows Server and cloud platforms. His explanation of Moby begins with the difficulty of producing those editions with small teams. Sharing assemblies is a way to retain common integration work while allowing the resulting products to differ where their platforms require it.

The distinction is especially relevant to systems whose differences are below the application image. A desktop edition has host integration requirements that differ from a server deployment. A reusable image-building workflow does not remove those host requirements. Moby gives system builders a proposed place to work on those combinations without requiring application developers to design the underlying container system themselves.

The project includes both a library and an assembly framework

Docker describes a library of containerized backend components. Its examples include logging, volume management, networking and image management, as well as containerd and SwarmKit. This is a set of responsibilities needed to construct container systems. The components do not all have to perform the same role or expose the same kind of interface.

An assembly framework sits alongside that library. The announcement includes tooling to build, test and deploy artifacts produced from assemblies. That is the part that makes the proposal more substantial than a directory of reusable repositories. A system builder needs a way to turn selected components into a usable artifact and repeat the process after changing an input.

The announcement also names a reference assembly, Moby Origin, as the open base for the Docker container platform. A reference assembly provides a concrete combination against which other combinations can be understood. It can show how the project uses its own components without making that one selection the only permissible system.

Participants may supply their own components packaged as containers and combine them with components derived from Docker. That condition is important to the project's scope. Reuse is not limited to selecting only implementations produced by one company. A specialized system can preserve a useful assembly approach while replacing components whose assumptions do not fit its environment.

An assembly has a different purpose from an application image

An application image describes the filesystem and execution environment for an application. A container system assembly selects the machinery that builds or runs such applications. Confusing these levels would make the announcement harder to use. Moby is intended for people building container systems, while Docker remains the product application developers use.

Docker states that distinction explicitly. The announcement says Moby is for system builders and that application developers can continue using Docker or another container platform. It also says Docker will remain an open source product for building, shipping and running containers. The intended user-facing continuity is part of the announcement, even though the location of open development is changing.

This division lets an application developer evaluate Docker as an integrated tool. A developer does not have to become the maintainer of a component assembly to build an image. System builders accept a different responsibility because the combination of components is itself the thing they produce. Their output needs its own integration work and testing.

I favor keeping that responsibility explicit. A collection of individually useful components does not justify assuming that every possible combination will behave as one coherent platform. The framework's role in building and testing assemblies acknowledges that compatibility between components is work that someone must perform and maintain.

Containerd shows why the boundaries matter

The December containerd announcement already described separating core runtime functionality from Docker's broader platform. Its roadmap included image distribution and local storage in addition to execution and supervision. That effort provides a concrete example of a component gaining a scope useful to other system builders.

The March CNCF acceptance announcement then gave containerd an independent foundation home. That governance decision addresses shared stewardship of one component. Moby addresses how components can be assembled into systems. The two announcements concern related engineering work, but one does not replace the other's purpose.

A component may therefore participate in an assembly while keeping its own governance and project identity. A system builder can depend on containerd without requiring all its other decisions to become part of containerd. This is useful because a runtime's callers can disagree about application scheduling or host integration while still sharing the local execution implementation.

The practical integration task remains visible. The runtime supplies particular operations. Other components supply additional behavior, and an assembly determines which implementations belong together. Describing those dependencies makes it possible to discuss a change at the level where it actually applies, whether that is the runtime API or the complete system produced around it.

The proposed audience extends beyond conventional server platforms. Hykes names Internet of Things systems and industrial control among the use cases motivating specialized container systems. Those examples explain why a single fixed assembly would be insufficient for the stated goal. Different system builders need to decide which components fit their target infrastructure, while sharing the construction and integration work that remains common between those targets.

Open experimentation and product delivery need different decisions

Docker calls Moby an open research and development environment and says its open source collaboration will move there. That gives the project a broader remit than maintaining only combinations already selected for a released Docker edition. Contributors can experiment with new components and alternative systems without requiring every experiment to enter the integrated product.

A product still needs a selected combination with a delivery process its users can rely on. The announcement retains Docker in that role. This separation means an experimental assembly and a downloaded Docker product should not be treated as interchangeable merely because they share components. Their intended consumers and integration responsibilities differ.

There is a tradeoff for contributors trying to locate a particular change. The product name alone will not identify every repository or component responsible for its behavior. More modular development asks people to understand the boundary involved. In exchange, a component or assembly can be discussed without making every decision an argument about the whole application platform.

The announcement does not provide evidence that every proposed combination is complete or that every specialized system now has a supported assembly. It establishes the project and its development model. The specific components, build tooling and reference assemblies are the material system builders will need to evaluate as they decide how to participate.

Moby's immediate significance is the explicit inclusion of integration artifacts in open development. Docker has already extracted several underlying components, and now wants collaborators to share the way those components become systems. Application developers retain the integrated Docker product, while system builders gain a project whose stated scope includes selecting components, assembling them and producing the artifacts they deploy.