Container Rivals Bury The Hatchet, Forge Single Standard

The point of software containers is to provide a level of abstraction for bits of system and application programs so they can be run anywhere and maintained easily. Having multiple software container formats seemed to have been inevitable, at least for a while, with nascent industry juggernaut Docker and Linux operating system maker CoreOS not agreeing on some fundamental issues relating to containers. Now the two companies and a slew of interested parties who want to make money on the software container wave are getting behind the Open Container Project, which will converge the various container efforts and runtimes to create a single standard.

This is a good thing for all parties concerned, but most especially for the tens of millions of organizations worldwide that have not yet adopted software containers as a means of packaging, deploying, and managing their applications. In what we assume will be a fairly short time, Docker, CoreOS, and the many companies that have developed tools to support containers – most of them the Docker container format and runtime, called runC – will work together through the Open Container Project to establish a single specification for software containers and their runtimes. Innovation will take place at a higher level in the software stack, and many of these companies will live or die based on the add-on tools they create to manage the containers.

While the playing field will be level with regard to software container formats and runtimes, Docker, the company, has by far the biggest user base and war chest, and as such, even by conceding some ground to container rivals in the hopes of establishing a standard that provides more portability, Docker has many advantages and will probably be helped more by standardization than hurt by it. Docker, which is only a little more than two years old, has raised $150 million in four rounds of venture capital funding and has a valuation that was around $1.1 billion when it raised its most recent funds back in April. The company says that there are more than 150,000 applications in its Docker Hub repository and that they have been downloaded over 500 million times.

CoreOS, which started out by creating a streamlined and easy to manage Linux for servers that was based on Docker technology, decided to create its own container format, called appc, and container runtime, called rkt, at the end of 2014 because of differences in opinion about the security model for containers, among other issues. In April this year, about two years after its own founding, CoreOS announced Tectonic, a software container management stack based on its rkt runtime and appc container spec and a number of its own open source projects. CoreOS has raised $20 million in venture funding in its four rounds, and was fighting an uphill battle with the Docker libcontainer format in that Tectonic had to support appc as implemented in rkt and also do conversions from Docker libcontainer to appc on the fly to maintain backwards compatibility in CoreOS. As The Next Platform previously reported, other container runtimes that are compatible with appc, including Kurma, which was created by Apcera (now owned by telecom equipment maker Ericsson) for its Hybrid Cloud Operating System and JetPack, which is an appc runtime for FreeBSD Unix operating systems.

“This effort is looking pretty good. It has all the right properties. It has open governance, it has vendor neutrality because it is being managed by the Linux Foundation, and it is coming from a Docker base, which is good because no matter how well-engineered it is, Docker is still what a lot of people are using and we can now take that and evolve it to the next level. It also has broad industry support, so there are no holdouts at all.”

While others are scrambling to add Docker support to their existing virtualization and management tools – the big names are Microsoft, Red Hat, VMware and IBM – what seems clear is that a lot of companies are looking for a clean slate where they can get it (particularly for new applications based on microservices) and partners that integrate Docker with existing products when the opportunity is not a greenfield one.

In a blog post, Docker CEO Ben Golub said that the code comprising Docker’s runC container format and runtime comprised less than 5 percent of the Docker software stack. (It is akin to the ESXi hypervisor buried at the heart of the vSphere and vCloud software stacks from VMware.) This code has been contributed to the Open Container Project, which is a sub-project underneath the Linux Foundation. The Linux Foundation is not just where Linux operating system creator Linus Torvalds gets his paycheck, but is also where various projects such as Cloud Foundry (platform cloud), Node.js (server-side JavaScript), OpenDaylight (software-defined networking), Xen (server virtualization hypervisor), and a number of other collaborative projects live. There are more than twenty companies that will be participating in the Open Container Project effort, including Apcera, Amazon Web Services, Cisco Systems, EMC, Fujitsu, Google, Goldman Sachs, Hewlett-Packard, Huawei Technologies, IBM, Intel, Joyent, Pivotal, Mesosphere, Microsoft, Rancher Labs, Red Hat, and VMware alongside CoreOS and Docker.

Most open source projects are a meritocracy, and when they make a standard, it is important to have all of the key people involved. Technically speaking, the libcontainer project maintained by Docker, Red Hat, and Google is what has been donated to the Open Container Project. Michael Crosby and Alexandr Morozov of Docker, Rohit Jnagal and Victor Marmol of Google, Mrunal Patel of Red Hat, and independent developers Daniel Minh and Tianon Gravi, who all worked on libcontainer, have switched over to the new effort. The two key maintainers of the appc effort, Brandon Philips (one of the co-founders of CoreOS) and Vincent Batts (of Red Hat) are on the governance body for the Open Container Project. Golub expects for the list of Open Container Project maintainers and contributors to grow in the coming weeks.

CoreOS is relieved, it seems, that there will now be one standard container and runtime and that it will not have to spend time and money explaining the differences between libcontainer and appc and actually coding the low-level container format and runtime all by its lonesome. And it is the kind of open specification that CoreOS CEO and co-founder Alex Polvi says the company wanted from the get-go.

“This effort is looking pretty good,” Polvi tells The Next Platform. “It has all the right properties. It has open governance, it has vendor neutrality because it is being managed by the Linux Foundation, and it is coming from a Docker base, which is good because no matter how well-engineered it is, Docker is still what a lot of people are using and we can now take that and evolve it to the next level. It also has broad industry support, so there are no holdouts at all.”

For once, the IT industry seems to be getting a single standard, like it always talks about delivering. Imagine a world where there was one Unix, or one hypervisor, from the beginning.

While CoreOS will be donating its appc container spec to the cause, the Docker genie is not going all the way back into the bottle at CoreOS. Polvi was very clear that CoreOS would continue to support its rkt runtime in its minimalist Linux operating system and its Tectonic application platform; it is not switching back to Docker even if there will be a single format for the software containers themselves. The innovation will revolve around how the containers are managed, but not in the container formats and runtimes themselves.

It will take a few months for the Open Container Project to get its initial specification out the door, and it will be very interesting indeed to see how the maintainers work out their differences.

Sign up to our Newsletter

Featuring highlights, analysis, and stories from the week directly from us to your inbox with nothing in between.
Subscribe now

1 Comment

  1. Industry Temptation , propagated by cloud services, is the new IT model behind Docker.
    Next Platform may do better to report solid basis for runaway success in Docker (given 2 years is a blur in hitech) and why rkt has not taken hold sooner. Could it be that Windows VisualC dominated .Net / C# landscape that sugar coated programmers are are so stuck on ?

    CoreOS have stuck to their guns with a lightweight runtime ( rkt ) which 12 months ago weighed in at 8MB.. whereas Docker had a dependency on the application being deployed.. IT seems reasonabe , but what are the facts .. about as difficult to summarise as the Accel FPGA wars in terms of binding to a Host environment in its runtime .. No-one has clear answers as to exactly what parts of the runtime expect Host kernel support (at what overhead , ie: is that from Cache / DRAM / SSD ? what size each kernel call is , etc ..) or global library ( PGA kernel ) support (thats the GPU video RAM) ..not one reliable source .. IS it that hard to bror a side-by side comparison to. bring these overheads together rather than debate Goliath cant fall over ..
    Containers are a software wrapper for portable/ stateful /relational what have you,.’spreadsheet’ or desired result (data mining / sharing / selling ) and it is important to realize overheads and the security model baggage / vulnerability which CoreOS address ..

    Theres no way in the world the first of anything is a preferred method .. Are u all going to sit around as Windows Beta Testers for another global standard with a 2 digit year code that cost the planet trillions FOR NOTHING ?

    Popularity Breeds Contempt is a suggested title ..to analyze this ..

Leave a Reply

Your email address will not be published.


*


This site uses Akismet to reduce spam. Learn how your comment data is processed.