Coalition for App Container Spec Shows Docker is not the Standard For Everyone
It’s a market when there’s competition. Maybe we don’t have to resort to some typical tech-press extreme and say the battle lines are being drawn. But even if there’s friendly chivalry involved with the process, the container market is starting to choose sides.
Monday, several major steps were taken toward the foundation of a Linux container ecosystem outside of the emerging sphere of Docker. CoreOS, one of the original minimalized Linux systems, announced at its inaugural annual conference the formal entry of Google, VMware, Red Hat, and hybrid cloud OS maker Apcera into a gathering coalition of industry partners backing App Container, or appc, the specification developed by CoreOS for its Rocket runtime system.
Perhaps for trademark reasons going forward, CoreOS will now be spelling its product without vowels, as rkt, though it will probably continue to be pronounced “rocket” and its logo will be, well, a little rocket.
Avengers Assemble
Last month, Google Ventures invested $12 million in CoreOS, which immediately resulted in CoreOS incorporating Google’s Kubernetes management layer into the beta for its infrastructure platform code-named Tectonic. Now Google is returning CoreOS’s return of its favor, by formally incorporating the-platform-formerly-known-as-Rocket into Kubernetes, and joining the emerging appc coalition.
That coalition was already made stronger two weeks ago with VMware’s support of appc in its own minimalized Linux, called Project Photon. Now add Red Hat to the mix, as CoreOS has announced it is receiving a Red Hat senior engineer and a major Docker contributor, Vincent Batts, as that company’s maintainer of appc. Batts will join Google’s Tim Hockin (another Docker maintainer) and Twitter’s Charles D. Aylward.
For its part, Apcera will premiere this week its own appc implementation, named Kurma, which at this early stage is being described as “an execution environment for running applications in containers.”
All of that may be prelude to the next step CoreOS takes in distinguishing rkt from Docker, besides stripping away its vowels: It’s revamping Quay.io, the private, secure Docker repository host it acquired last August and the foundation of its CoreOS Enterprise Registry, to act as a secure repository for rkt images as well as Docker.
As CoreOS CEO Alex Polvi stated in a note to The New Stack, the move is intended to make Quay a more effective competitor against Docker Hub.
“Quay’s ease of use and speed comes in a number of features that are unique to our platform,” stated Polvi. “Quay’s ability to build images is significantly faster due to our new build caching system. Our feature allowing dynamic construction of squashed images means deployment of containers on machines is significantly faster than a normal pull from other registries.”
Docker’s runtime currently uses Docker Hub as its centralized distribution center by default, although the image name may specify another location. Polvi explains to us that appc, by comparison, is more like git: decentralized by default.
“Discovery of container images,” the file reads, “should be simple and facilitate a federated namespace and distributed retrieval. This opens the possibility of alternative protocols, such as BitTorrent, and deployments to private environments without the requirement of a registry.”
One of Quay’s key selling points to date has been an “advanced registry.” Does that feature go away?
“Quay is Docker compatible and Docker requires a registry,” Polvi told The New Stack. “Having a registry does add some nice features, at the expense of additional operational complexity in your environment as you have to run a registry. One of the nice parts of appc is that it does not require you to run a registry, but it will work with one if an operator chooses to have it.”
The Rebels Choose Their Allies
It’s all part of CoreOS’s emerging theme, a sort of revolution outside the revolution. In appc’s readme file, the authors suggest that decentralization should remain a principal tenet of the new specification.
The keynote of this theme was struck last December, when CoreOS’s Polvi issued the first rallying cry for an App Container standard that would lay claim to Docker’s original goals, which Polvi suggested Docker had abandoned.
“We thought Docker would become a simple unit that we can all agree on,” wrote Polvi at the time. “Unfortunately, a simple re-usable component is not how things are playing out … We should stop talking about Docker containers, and start talking about the Docker Platform. It is not becoming the simple composable building block we had envisioned … We still believe in the original premise of containers that Docker introduced, so we are doing something about it.”
That something involved the drafting of an App Container standard that, very curiously, enabled a specification for multiple processes per container, working together as a single app but nonetheless sharing namespaces. It’s a key architectural distinction, and quite notably, the very same distinction subscribed to by the Kubernetes management platform.
So in five months’ time, the revolution that struck out against the development of platforms, developed a platform.
“Tectonic pre-packages all of the components required to build Google-style infrastructure,” reads CoreOS’s April 6 announcement of Tectonic, “and adds additional commercial features, such as a management console for workflows and dashboards, an integrated registry to build and share Linux containers, and additional tools to automate deployment and customize rolling updates.”
What changed between December and April? That’s a very good question — in fact, the #1 question in CoreOS’s FAQ for Tectonic. The answer estimated the distance of the gulf between “no platform” and “platform,” and issued the following result: “Nothing.”
“Development will continue, and we want to see all of the open source projects continue to thrive as independent components,” the FAQ went on.
I asked CoreOS’s Alex Polvi about how appc would resolve a problem that microservices architects, including at Google, encountered during their early implementations: tagging services that related to one another. Polvi responded that appc is not concerned with that issue, effectively passing it on to the service discovery layer further up the platform — and he had one in mind.
“App Container defines an image format, a runtime environment, and a discovery protocol for finding containers,” responded Polvi. “These issues are solved higher up the stack. For example, Kubernetes addresses service discovery natively.”
In a press release Monday, Kubernetes’ co-founder and Google product manager Craig McLuckie noted CoreOS’s design choice as key to his company’s support of appc: “Designed with cluster first management in mind, appc support enables developers to use their preferred container image through the same Google infrastructure-inspired orchestration framework.”
With Microsoft’s leading Azure engineer donning a Docker t-shirt last Wednesday and hosting Docker’s CEO on stage at its main developers’ conference, the shape and texture of the containerization market is looking less like a picnic and more like a chessboard. This week, Docker and rkt move out their queens.
CoreOS and Red Hat are sponsors of The New Stack.
Feature image via Flickr Creative Commons.
