Kubernetes Chief: We Back Docker, Although appc Might Have Merit
Google announced last week its support of CoreOS’s effort to become a maintainer of appc, an emerging specification for containers. Designed to enable containers to bear multiple processes, it appeared to many an endorsement of CoreOS’s bold manifesto for containers that could be more closely aligned with Kubernetes’ support of clustering.
That appearance was soundly obliterated Monday in a blog post from Kubernetes leader and Google Group Product Manager Craig McLuckie. In it, McLuckie rephrased Google’s support of appc from “an important milestone for the Kubernetes project,” as he called it last week, to something “we may introduce … at some point in the future,” to Google Container Engine.
“Our intent with our announcement for AppC and RKT support was to establish Kubernetes (our open source project) as a neutral ground in the world of containers,” wrote McLuckie, referring to CoreOS’s new brand for the container system formerly known as Rocket.
“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,” he continued. “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.”
McLuckie concluded by praising Docker Inc. for “democratizing” container technology, and reiterating that Google plans to support the Docker standard “indefinitely.”
The Google product manager’s statement makes official his point of view which first emerged on May 4, when he tweeted, “Saddened that rkt/Docker support in @kubernetesio seen as either or:
It must be both. rkt/appc is promising, but Docker has real traction.
Following his blog post Monday, McLuckie added this tweet:
Been saddened by the unnecessary drama recently.
Resetting the Milestone
Last week, CoreOS CEO Alex Polvi stacked Google’s Tim Hockin alongside Red Hat’s Vincent Batts and Twitter’s Charles Aylward, not only as official maintainers and collaborators on appc but as backers of what Polvi portrayed as a single, common container standard.
“In the months after the launch of appc, we have seen the adoption and support behind a common application container specification grow quickly,” Polvi wrote. “These companies and individuals are coming together to ensure there is a well-defined specification for application containers, providing guidelines to ensure security, openness and modularity between stacks.”
But at no time did Polvi imply that he believed appc would replace Docker’s libcontainer in Kubernetes. So no, nobody of any importance put forth the notion that appc would come to replace Docker among the open source ecosystems that utilize Docker today.
That said, Google’s backing of appc, which is far more than merely verbal, is indeed a bet placed on CoreOS. Just because you bet on more than one horse doesn’t make you less of a gambler.
What’s more, while many open source ecosystems have come to fruition under the premise of “democratization,” and letting the customer choose the right components, at some point customers defer to someone’s judgment with respect to what “the right components” are. Which is why this issue runs far deeper than merely a skirmish over the syntax of a specification document.
The distribution mechanism of choice for the emerging appc format will be Quay.io, which CoreOS acquired last August. As CoreOS’s Polvi told The New Stack earlier this month, Quay.io is not the “default registry” for appc containers the way Docker Hub is the default for Docker containers. Nonetheless, Quay is a separate ecosystem whose proprietor currently professes that there should be no single default hub for the distribution of container images.
That argument should sound very familiar to the folks at Google. “We chose the term ‘market’ rather than ‘store’ because we feel that developers should have an open and unobstructed environment to make their content available,” was the argument Google’s Eric Chu made in 2008 in favor of opening an independent Android Market — a service whose name, despite Chu’s argument, was changed to Google Play Store.
In a statement Tuesday afternoon to The New Stack, CoreOS CEO Alex Polvi had this response to McLuckie’s post:
We believe that the post is saying that the world is almost always better for having choice, and that appc does offer merits.
“The appc community has a strong belief that users need basic security features, as well as a standard shipping container that can be shared by a variety of vendors,” Polvi continued. “We feel this is what users want and need to succeed with containers. We are seeing traction with the appc approach with a variety of software communities — Kubernetes included.”
Red Hat is Not a Sideline Spectator
To many enterprises, “openness” with respect to technology does not imply tolerance of alternative standards but rather a frank discussion about the possibility of a single one. Since open source developers are, at least purportedly, open, enterprise customers may assume that if these developers have failed to work together to craft a single, common standard for achieving a goal that’s in everyone’s best interests, there must be a pretty good reason.
That’s the perspective of Lars Herrmann, Red Hat’s senior director of strategy, speaking to us Tuesday from the OpenStack Summit in Vancouver.
“As an industry, we have an opportunity with containerization to agree on a single format and make it just work for everybody,” Herrmann told The New Stack, “instead of fragmenting it into different formats. Because that just creates a lot of redundancy and redundant work for very little benefit at all. We’ve been living with this fragmentation at the format level for so long. Now we have an opportunity to overcome that.”
The differences between appc and Docker’s libcontainer are far more than semantic, Herrmann noted, bringing up the argument about whether Docker’s daemon should be responsible for launching processes rather than systemd, which CoreOS relies upon. Herrmann acknowledged that Docker’s design choice does make containers generally more difficult to manage, as well as to exploit for security purpose. For that reason among others, he said, Red Hat assigned an engineer to the appc specification.
“Ideally, we really would want to have the communities figure out how to work together instead of against each other,” remarked Herrmann. “We really don’t think we need another format here.”
Even though Red Hat was a principal author of systemd, he continued, “We believe that just switching from a Docker daemon infrastructure to systemd is not enough value to throw away the homogeneous, unifying format. We really encourage the communities to work together. That’s why we participate in both.”
We’ll have more of Herrmann’s interview with us later in The New Stack.
CoreOS and Red Hat are sponsors of The New Stack.
Feature image via Flickr Creative Commons.
