VANCOUVER -- When Google announced that it would support AppC, a vendor neutral container format, and the first container based on it, CoreOS's Rocket (RKT), some people took this as Google supporting AppC over Docker. That is not true.
Craig McLuckie, Google Group Product Manager and Kubernetes Project Co-Founder, explained in a blog posting that "Google has consistently supported the Docker initiative and has invested heavily in Docker. In the early days of containers, we decided to de-emphasize our own open-source offering (Let Me Contain that for you, LMCTFY) and to instead focus on Docker."
He then said, "We have two engineers that are active maintainers of LibContainer, a critical piece of the Docker ecosystem and are working closely with Docker to add many additional features and capabilities. Docker is currently the only supported runtime in GKE (Google Container Engine), our commercial containers product, and in GAE (Google App Engine), our Platform-as-a-Service product."
So, McLuckie continued, "While we may introduce AppC support at some point in the future to GKE based on our customers' demand, we intend to continue to support the Docker project and product, and Docker the company indefinitely."
He went on to praise Docker saying, "To date Docker is by far the most mature and widely used container offering in the market, with over 400 million downloads. It has been production ready for almost a year and seen widespread use in industry, and also here inside Google."
While Docker's popularity is white hot, not everyone agrees with it being production ready. At OpenStack Summit in Vancouver, several ISVs complained privately that Docker is trying to do too many things. They see Docker growing into a platform rather than just a container and that's more than they wanted from the program. Others said that Docker is evolving too quickly for them to trust it on production systems.
So what did Google mean when it added AppC and RKT support if not to support a Docker alternative?
Our intent with our announcement for AppC and RKT support was to establish Kubernetes as a neutral ground in the world of containers. Customers should be able to pick their container runtime and format based solely on its technical merits, and we do see AppC as offering some legitimate potential merits as the technology matures. Somehow this was misconstrued as an 'a vs b' selection which is simply untrue. The world is almost always better for having choice, and it is perfectly natural that different tools should be available for different purposes.
Thus, while Google is praising Docker, it's also well aware that others want container choice. So it is that Google will be supporting AppC, RKT, and Docker on their own Kubernetes container management system.