An Ode to Boring: Creating Open and Stable Container World
Disclaimer: This is my personal opinion, not an official Samsung SDS position.
I’ve been involved heavily in open source projects for some time, notably Openstack while I was at HP Cloud. I’ve also led teams deploying Cloud Foundry globally. Most recently I’ve been openly involved in the Kubernetes project as a part of the Samsung SDS Cloud Native Computing Team (CNCT).
The CNCT provides services and consulting to clients inside and outside Samsung Group. We help our clients leap forward in product velocity and operations efficiency — migration towards the principles of cloud native. In support of the organizational transformation, we help our customers build and operate large, reliable Kubernetes clusters. We were on stage at the Kubernetes launch and were the first to publicly demonstrate a thousand node Kubernetes cluster.
My direct experience on this effort and my experience with other open source projects leads me to ask a question: Is it time for a common open source stability fork of the docker engine, container image packaging, naming, and deployment specifications?
Let me fully give credit where credit is due; Docker has done an amazing job in improving developer work life and enabling much needed change in IT. Docker’s passion for the developer experience is undeniable and wonderful.
Adoption of common fundamental building blocks is a powerful force in any ecosystem and is required for mass adoption. The sweeping change of an industry caused by standardized shipping containers is no less true for having been so often repeated.
Those of us pursuing industrial grade computing have long recognized that container orchestration was the key technology. Distributed systems at scale are very hard. As many teams deep in implementations will tell you… the orchestration job is right now much harder than it should be because there is far too much product and feature excitement about containers. We need boring!
If your team is working deeply in Kubernetes, Mesos, or Cloud Foundry, you need a stable, simple, boring container implementation with minimal essential characteristics, and community agreement around image creation, naming, and publishing. You need to use the same simple, boring container implementation that everybody else is using. As a community, we need to slow the pace of change of the fundamental building blocks. Stability will allow the systems built on top to thrive.
Docker’s current approach is in conflict with these goals of these communities. The Docker approach has been characterized by a rapid pace of feature introduction in Docker Engine versions along with the fragility caused by code churn. It’s very exciting! New versions have new features with new bugs (note the links in the postscript below), along with fixes from the previous versions; there is no community available LTS (Long Term Support) version.
Docker’s recent move to embed Swarm into the docker engine is equal parts poor architecture and brilliant marketing. Docker is moving away from the simple building block that can be used by many systems. This was a large new system developed in secret without transparent community involvement. Docker seems to be moving away from an open community. The commercial strategy here is one that should be worrying to those who prefer the architecture or communities of Kubernetes, Mesos, or Cloud Foundry. Docker has established that they will use their position to impede the progress of those communities in favor of their commercial interests.
Linux OS vendors and communities are now carrying different sets of backported docker patches (see postscript for an example). Docker is ALREADY forked independently by many different groups. Every new Docker version comes with breaking fixes and features and the forking starts over again.
Docker appears to offer support on a paid basis. But Docker has also now made it clear they are competing with the other frameworks. Paying Docker for support when you’re using a competing orchestration framework is akin to paying the fox to fix holes in the henhouse. But, even for those who would take that risk, users of a paid Docker LTS would, by definition, no longer be using the same building block as everyone else. Open source systems are stable because many eyes and hands are using the same software and fixing the same bugs.
It is now critical to the success of those building boring infrastructure systems to openly and transparently collaborate on a minimum essential container implementation. It is time for this effort to happen in the open. Although Docker’s commercial interests may take them in another direction, I hope they bring their passion for the developer experience to a truly open effort.
I call on the CNCF to formally foster a common community container implementation project backed by the Kubernetes, Mesos, and Cloud Foundry communities. We need a transparent, community-driven implementation, extensively vetted across many communities with federated CI. The project goal should be to become the default container implementation for a wide number of open source orchestration systems; I’ve mentioned only a few of the most influential ones. Let’s work hard together to keep it simple, common, and boring.
-Bob Wise
Postscript: Related threads you might want to read:
https://news.ycombinator.com/item?id=12364123
http://www.linux-toys.com/?p=684
http://www.projectatomic.io/docs/docker_patches/