Right as Docker prepared to kick off DockerCon Europe 2014, CoreOS -- creators of a Docker-powered variant of Linux -- came out with a radical suggestion: Docker has problems, so try our container technology instead!
The timing of CoreOS's announcement couldn't have been more awkward for Docker, and Docker wasn't shy about defending its position as an industry incumbent and technology leader, as well as insisting it had solutions in the works for many of the stated problems. But the question remains whether CoreOS has legitimate points to make and whether it'll take a full-blown schism in the Docker community to solve them.
The argument against
The problems CoreOS cited revolve mainly around the architecture of Docker. It depends on a single daemon that requires root privileges to run, it has become top-heavy and unwieldy (does a software containerization system need a network overlay, too?), its security model is questionable, and the tools are too closely wedded to the technology.
Forking Docker wouldn't fix any of this, CoreOS argued; the only strategy is to start over with CoreOS's new container technology and its implementation, Rocket. Such a shift would come at the cost of abandoning, or at least severely disrupting, any existing work in the Docker ecosystem.
Oliver Thylmann, co-founder of Giant Swarm, a Docker-based service for deploying applications developed as microservices, noted some of these issues were borne out by his own experience. With security, he noted in a email, "You need to know that the container you run is the container that was supposed to be deployed. Docker still doesn't have that." Digital signatures have been added to Docker containers, but the verification mechanism currently does little more than throw a warning in order to avoid breaking existing functionality.
Thylmann also noted that the weight of Docker was another issue: "Docker is one binary that is getting new features by the minute, and Rocket makes sure that you can use the parts you want to, e.g. [use the] Rocket runtime, downloader, or installer, or build your own [since] it is all separate. We also see that the Docker daemon is really resource hungry." For him, Rocket emulates the Unix model of having small tools for specific jobs, something that CoreOS also implemented with its etcd project.
The argument in favor
The arguments in favor of staying with Docker revolve around two factors: The open source roots of the project (and its open APIs), and the existing commitment to Docker that's sprung up around it in a relatively short time.
Node.js maintainer Joyent, also making a name for itself in delivering "container infrastructure as a service," responded to CoreOS's ideas with a blog post, which spelled out how Docker's open API provides a path for future innovation with the product from inside. "There are many open questions (especially around network virtualization and persistence)," wrote Joyent's Bryan Cantrill, "but given the robust community and the API-driven ethos of Docker, we are confident that the Docker ecosystem will continue to expand and flourish."
Aater Suleman, CEO of Flux7, a cloud and devops consulting firm and a Docker Foundation Partner, also doesn't believe a radical break is required to reform Docker. "Innovation doesn’t occur without mistakes," he wrote in an email, "it's a pre-requisite to innovation. Docker has made their share of mistakes and has learned from them, and CoreOS will make some mistakes of their own as they will innovate. Our industry is used to this model of continuous learning."
For Suleman, the fact that industry leaders like Amazon and Joyent have invested as heavily as they have in Docker is a sign of its validation. "These companies know that Docker is new technology, and they understand that security is a challenge with new software," he wrote.
What if Docker and Rocket ended up evolving along different and parallel paths? In that case, Suleman said, any fragmentation between the two "is often addressed by the community." His notion was that connectors could be used to ease transition between multiple container formats.