Google, Twitter, Red Hat Speak Up For Container Standard

6 Ways To Master The Data-Driven Enterprise

A proposed specification for Linux containers called App Container (or more succinctly, appc) is drawing significant support as CoreOS makes the case that data centers need a standard spec, despite the current pre-eminence of Docker Containers. CoreOS produces the CoreOS version of Linux for running containers on a host.

Docker backers had to wonder what gives, as Google, Red Hat, Twitter, VMware, and Apcera all took the stage Monday to voice their support for Appc. It's conceivable that Docker will one day propose its own standard for containers, but right now it appears intent on establishing its own Docker Platform as a de facto standard through its runaway adoption. Docker Platform includes a number of management tools as well as the Docker Engine container-formatting system.

Many of the companies endorsing CoreOS's appc, including Google, Red Hat, and VMware have previously announced their support and close collaboration with Docker. That's not necessarily at odds with a CoreOS specification. Docker's formatting method could at some point be brought into compliance with the CoreOS specification, if Docker chooses to do so. So far, however, the two container pioneers have had more to say about each other in their competition than in any cooperation.

[Need an introduction to containers? See Containers Explained: 9 Essentials You Need To Know.]

The public support for appc emerged during CoreOS's first annual developer group meeting, CoreOS Fest, in downtown San Francisco this week. A panel on the need for a specification took center stage Monday morning, after an opening address by CoreOS CEO Alex Polvi in which he said the Kubernetes Project for creating a container cluster hasn't shipped a 1.0 version yet, "because it cares about getting basic security needs right." CoreOS's own Tectonic product, announced April 5, will be based on Kubernetes, and itself remains in a pre-1.0 release.

But developers can count on CoreOS with its Rocket container runtime (now referred to as rkt) and Tectonic container clusters to produce "Google infrastructure for everyone else." Having recently received $40 million in venture funding from the Google Ventures unit, CoreOS is clearly trying to take on the role of industry infrastructure standard bearer and surrogate for the world's biggest container user, Google. Google Search runs on containers, Google officials have said they launch about two billion containers a week, and they've managed containers effectively for the past decade.

"We care about interoperability. It was missed in the virtualized world," Polvi said. With its appc specification, "we're writing down what a container is, what a container runtime is," in hopes of avoiding virtualization's mistakes.

His remarks were followed by an App Container Technical Spec Panel, where Charles Aylward, software engineer at Twitter, said his firm backed the specification and its first implementation, CoreOS's rkt, because "we were looking for something that would be composable. What was available off-the-shelf was a set of tightly integrated small packages."

"We already had a fair amount of infrastructure. Taking something off the shelf would be additive infrastructure," he said.

The reference to taking something off the shelf and to "tightly integrated small packages" sounds a lot like Docker Platform, which includes a number of management tools and utilities, as well as a container formatting engine. For 20 minutes, Docker remained the elephant in the room, with several panelists talking about it without naming it.

Vincent Batts, senior software engineer at Red Hat, finds himself in the unusual position of being named chief maintainer of the appc specification, produced by his employer's chief container-optimized operating system competitor, CoreOS. (CoreOS competes directly with Red Hat's Atomic Host.) Batts tweeted news (@vbatts) of a review that knowledgeably compared the two on May 14, 2014, even though it maintained an evenhanded approach.

He has also been a frequent contributor to the Kubernetes project used by CoreOS. "There's no doubt containers are a forward progression," he told the CoreOS Fest crowd of about 300. "The more anyone can contribute what they've learned, the less likely there is to be a split in the community" to pursue divergent technology solutions, he said.

"Trying to find one way to do everything is probably self-defeating," he said, in what was another likely veiled reference to Docker.

Tim Hockin, an engineering manager at Google, added, "Before you build a cathedral, you've got to have a solid foundation. If you don't have a solid spec, the whole cathedral is going to fall down." He said appc was off to a good start because rkt (Rocket) had been produced as an implementation of the specification. "If you write a specification with no reference implementation, you're going to produce a spec that probably can't be implemented."

Hockin said the work isn't done on appc; it could be improved by allowing a container builder to specify more about the environment in which the application should run. "I don't think it goes far enough to describe the environment where the container's going to run," he said. For example, an application owner might want to say certain operating system calls are off-limits for a container on a server with extra security concerns.

Twitter's Aylward critiqued the specification's way of describing discovery as "a little prescriptive." In some settings, operations doesn't want a container query to make a round trip going out to the Internet and back after checking a service.

Ken Robertson, lead architect at Apcera, a code deployment management firm, urged the appc writers to "keep the spec from becoming too Linux specific. There might be Windows containers at some point." Microsoft is committed to support management of Windows containers in the next release of Windows Server, due in 2016.

Google's Hockin pointed out another area where containers have a known weakness. "Containers are not a secure boundary. If you're running antagonistic containers, you're going to lose," he said. On the other hand, running containers inside a secure virtual machine imposes the overhead of virtualization. "How to avoid the VM tax is a big question. That will need to be an area of innovation over the next few years," he said.