Docker founder here. > What is the motivation and benefit for running containers without docker? I regularly hear from people who want to run containers witho

Docker founder here. > What is the motivation and benefit for running containers without docker? I regularly hear from people who want to run containers without Docker. There are several motivations, all of which are perfectly valid: 1. Learning. It's fun to build things from scratch to understand how they work under the hood. 2. Bad experience. Early versions of Docker were quite buggy, and we initially struggled to keep up with the colossal growth in usage and feature requests. As a result, many of the people who tried Docker in production too early were badly disappointed. Some of them decided Docker wasn't for them, and started looking for alternatives. 3. Extremely custom use case. If your deployment is larger, or more complex, or more specialized than 99.99% of deployments out there, then "mainstream" platforms like Docker might not be the right fit for you. Of course we try to make Docker as customizable as possible, to support more a wider spectrum of use cases with plugins. But realistically, no single platform can cover all use cases, and I don't think any platform ever will. Docker is no exception. 4. Philosophy disagreement. Different people have different opinions on how applications should be developed and deployed. Docker tries very hard to be agnostic - to accommodate as many opinions as possible. But we can't please everybody. If Docker does not fit your philosophy of development and deployment, then the natural response is to look for an alternative. 5. Competition. Many Docker competitors started out as extensions or modifications of Docker, and over time are looking to reduce their dependency on Docker. I'm probably missing other reasons, but these are the ones I've been most exposed to. These are all reasonable reasons to not want to use Docker. Our approach is that, if you want to run containers without Docker, we should make it as easy as possible. In practice that means spinning out as many of the underlying components as possible (what we call the "plumbing") so that you can assemble it yourself without being stuck using the entire Docker platform. For example: - containerd [https://github.com/docker/containerd https://github.com/docker/containerd] is our low-level container runtime. - runc [https://runc.io https://runc.io] is a standardized "container executor", which we donated to the Linux Foundation as the reference foundation for the OCI spec. - libnetwork [https://github.com/docker/libnetwork https://github.com/docker/libnetwork] is the low-level networking implementation (including overlay networking which is a very useful primitive for container clustering) - swarmkit [https://github.com/docker/swarmkit https://github.com/docker/swarmkit] is a clustering/orchestration implementation - notary [https://github.com/docker/notary https://github.com/docker/notary] is a cryptographic content verification tool, which you can use to sign and verify container images. - infrakit [https://github.com/docker/infrakit https://github.com/docker/infrakit] automates the provisioning of infrastructure capable of running containers. Our opinion is that, even if you don't use Docker, by using these components for your own purposes, you are indirectly contributing to making Docker better. Splitting out these components has also forced us to refactor Docker into a more modular, more robust design. We even send Docker employees to explain how to run containers without Docker :) For example here's a talk we gave at Linuxcon: https://linuxconcontainerconeurope2016.sched.org/event/7oHM/building-distributed-systems-without-docker-using-docker-plumbing-projects-patrick-chanezon-docker https://linuxconcontainerconeurope2016.sched.org/event/7oHM/...