Why We Need the App Container Spec

Perhaps you spent some time reading CoreOS’ announcement yesterday - CoreOS is building a container runtime, Rocket. So I got to thinking last night about their container runtime implementation, Rocket, and the App Container spec they proposed. The timing is interesting and many are focusing on the fact that it’s a shot across the bow at Docker given that DockerCon Europe is going on later this week - but there is a lot more to it. I think it was a great PR move that they came out with it this week. It was a great way to capture our attention with some controversy, but I think that there’s a bigger reason why it is important.

I follow the Mesos project closely, and the Mesos User mailing list lit up with suggestions of how something like App Container could be integrated with Mesos. There are other projects such as Kubernetes, and of course, CoreOS, that would benefit greatly from this. What is so important, in my opinion, is that this is not just a competitor to Docker, or another way of doing something that we are already doing. Docker was a great start in the direction that we are going with the container deployment style, but as CoreOS stated, Docker is already expanding what they are doing well beyond just the individual isolated container. They are trying to do everything rather than focusing on just that one thing that they started out being good at.

That’s not the problem though. The problem is standards. For those that have been in Web technology long enough, I would like to take you back to the mid and late 90s when Internet Explorer exploded on the scene. With the arrival of Internet Explorer we had ActiveX, Microsoft's “standard” for the web that was to deliver dynamic and interactive Web experiences. As many will remember, Web sites across the Internet adopted and required ActiveX. Some company Intranet Web sites still require ActiveX. What was the problem with ActiveX?

  1. ActiveX was only from Microsoft.
  2. ActiveX was not a standard. No one else could come up with their own implementation.
  3. Microsoft was constantly tweaking and changing the way in which it would render pages. So every time a new version of Internet Explorer came out, pages had to be redesigned by Web developers in order to make their sites work for both old versions of Internet Explorer and new versions of Internet Explorer. Then we went into the chaos of Internet Explorer “compatibility modes” and “tweaks modes”

Now compare that to WiFi standards. We have 802.11 a, b, g, n, etc; all these are ratified standards that a consortium came up with, agreed upon, and codified in order that manufactures could all come up with the same end result. The end result being that various WiFi cards for desktop computers and laptops and WiFi routers and access points could all communicate with each other regardless of the operating system, the manufacturer, the implementation details. None of these details matter so long as the product adheres to the specification - it just works!

Now lets go to the App Container specification. It’s the same story - different characters and plot details. On one end we have Docker. Anyone that has been using Docker for a while, has had to change the way they’ve implemented their images as time has passed because Docker has been evolving. That’s a good thing, but there’s no standard. Docker, Inc. would have you look at the fact that it’s open source; that you can look at the source code. However, that open source project is 100% driven and controlled by Docker, Inc. as opposed to an open source project that is community-driven.

An important point to clarify is that two things were announced: a spec (App Container) and an implementation (Rocket). Here is the spec:https://github.com/coreos/rocket/blob/master/app-container/SPEC.md This separation of spec and implementation is important. It makes it much easier to integrate in Mesos. systemd is also just the implementation of the runtime part of the spec that CoreOS chose for Rocket. Mesos can use something else or come with its own.
— Tobias Knaup, Co-founder at Mesosphere (12/1/2014, Mesos User mailing list, used with permission)

Time will tell whether or not the App Container spec and the Rocket runtime implementation from CoreOS will actually be community-driven. However, I can predict this: if it isn’t, something else like this will be. There is an awakening I’m seeing across several different projects: that putting our eggs into the Docker basket got us this far, but its not going to get us to a place where we can have predictable results in our infrastructure orchestration projects long-term. I believe that we are going to see a groundswell around this App Container spec or something very similar. I, for one, am bullish on this. If you haven’t read the information that CoreOS put out on this, do it. Go read about Rocket, look at their Github project, and look at the discussions that are already evolving.