Toward an open container standard
Perhaps the most interesting part about the CoreOS container scheme, though – and a point that largely got lost in all the Rocket hype – is that Rocket is merely one implementation of the CoreOS container design. There may eventually be others, and in fact, the CoreOS team hopes there will be.
Work on the Rocket tools began around a month ago. But long before the CoreOS coders ever fired up their editors, they spent nearly a year crafting a specification for their new container format, which they call App Container.
Unlike Docker, where the container format specification has largely been defined by the Docker software implementation, the CoreOS developers sought from the very beginning to explicitly separate the spec for how containers are built from the actual runtime.
The company has now offered up the draft App Container spec for public input and comment. It's initially just available on GitHub, but Polvi said on Monday that he expects it will mature into something closer to a formal standard, complete with its own governance model. Eventually, CoreOS plans to "break App Container off into its own thing," he said – although what that will actually look like has yet to be determined.
Having an independent, open specification should make it easier for developers to build tools that work with App Container images – including developing their own container runtimes, if Rocket isn't their bag.
It should also help other projects integrate App Container support into their own software. Mesosphere, for example, has been working closely with CoreOS to develop the App Container spec, and the CoreOS developers have even floated the possibility of integrating support into Docker itself – which, after all, is open source software, just like Rocket.
Who needs this stuff?
So is the writing on the wall, and should container admins start planning for the day when they ditch Docker and move their container infrastructure over to Rocket and App Container? Maybe. And then again, maybe not.
Rocket will never do everything that Docker does, and that's by design. Its extremely lightweight approach to containers is ideally suited for CoreOS, which targets its products at a very specific market: massive Linux deployments, or what it terms "warehouse scale computing." In CoreOS land, minimal is always better.
"The way we use containers is really as a package manager," Polvi explained. "We don't ship apt or yum, we have our own package manager and we use containers for that."
Customers who aren't operating massive scale-out infrastructures, on the other hand, or those who aren't sold on the microserver app dev model, may prefer to stick with Docker. They may even appreciate its new, platform-oriented features, some of which are expected to be on display at the DockerCon Europe conference in Amsterdam this week.
Also, one area of emphasis for Docker is portability. Its developers are committed to making sure it's easy to move containers between various types of infrastructures, ranging from development laptops to large, cloud-based clusters.
The Docker tech may even one day be OS-agnostic – Microsoft is a Docker partner and it has announced that a future version of Windows Server will support running containerized applications based on the Docker protocols – while Rocket is likely to remain Linux-only.
Existing CoreOS customers, however, will want to watch Rocket development closely, as it's being developed to address an itch that CoreOS feels keenly but that Docker may no longer be able to scratch.
"It's not just a lackadaisical side project for us," Polvi said during Monday's meet-up. "It is something that we're going full force into."
Does that mean Docker is doomed? No. But it does mean the honeymoon is over. Just as no single winner emerged in the virtualization market, Docker isn't going to be the only player in the container game – and that's a reality that both Docker and customers will need to confront. ®