At CoreOS, we believe strongly that open standards are key to the success of the container ecosystem. We are excited about the amount of work going into standards and foundations around containers and cloud native computing, including today’s announcement of the Open Container Initiative’s (OCI) formalized technical governance structure.
Things have been moving very quickly over the past year, from the launch of the App Container (appc) specification and rkt, to the Open Container Initiative (OCI), to the Cloud Native Computing Foundation (CNCF). Today we want to take a moment to articulate where we see these important projects heading and how we intend to participate in them. While today’s announcement helps further clarify the scope of OCI, we believe there is more work to do for the container specification to be complete and achieve true interoperability.
Open Container Initiative (OCI)
When the Open Container Initiative (originally called Open Container Project) was announced in June this year, we were excited to partner with Docker and a large portion of the industry to work on:
"Creating and maintaining formal specifications ("OCI Specifications") for container image formats and runtime, which will allow a compliant container to be portable across all major, compliant operating systems and platforms without artificial technical barriers." – OCI Charter
The idea behind OCI was to take the widely deployed runtime and image format implementation from docker and build an open standard in the spirit of appc. We jumped at this prospect, as having one shared standard is a unique opportunity to foster wide proliferation and adoption of containers and a healthy ecosystem of competing implementations.
While initially it appeared there was some overlap between OCI and appc, the OCI has solely focused on the runtime, which is more narrowly focused than we anticipated for the project. Our efforts to bring in container image and image distribution of appc have not been incorporated, but we still believe these are important parts of a container standard.
Where OCI and appc Intersect
While we are happy the industry has come together to support the OCI runtime, CoreOS believes that the the most critical aspect of container standards is the distributable container image: the part that gives end-user portability. This component is not currently addressed by OCI, which is why it is important to continue our work with appc. With a standard image format, a user can build/package their container once, sign it, and run in a variety of vendors implementations and platforms. This means, for example, a user can build a container using
docker build, and then run it in rkt, Amazon EC2 Container Service (ECS), Kubernetes, or Mesos, all without needing to repackage. We believe this is the most important aspect of containers to standardize, so we intend to continue this discussion, and ask that members of the community join us.
Image distribution and discovery is another area of container standards we believe is very important. By creating a vendor-neutral, federated protocol for how containers are namespaced, discovered, and downloaded, we can provide a simple federated view for end-users while eliminating vendor lock-in and encouraging a variety of implementations. We think tools like git do a great job of this. GitHub is a very popular centralized repository, which makes it highly convenient for users to share projects, but the git protocol itself does not favor GitHub in any way. This model opens the playing field for competition, benefiting the user.
Cloud Native Computing Foundation (CNCF)
CNCF was formed to build and drive the adoption of “Cloud Native” computing, an approach to infrastructure architecture oriented around micro-services, containers, and dynamically scheduled applications. This is the style of infrastructure that we refer to as “GIFEE”: Google’s infrastructure for everyone else.
We started CoreOS to fundamentally improve the security of the Internet, and the cloud native architecture is key to making this happen. Therefore we are willing to contribute any of the open source projects that we have built — projects essential to furthering the adoption of this style of infrastructure — to CNCF. This includes:
- etcd, a distributed, reliable key-value store for the most critical data of distributed systems
- flannel, a virtual network fabric for containers
- appc components that are not covered by OCI, like the image format and discovery
- any of our open source projects that the community feels would be better served as part of a vendor-neutral foundation
A great example to highlight is etcd, which CoreOS built to further the adoption of Cloud Native Computing. Over the last two years, etcd has been implemented and used by many different projects in the industry. We want etcd to be basic internet plumbing, like Linux or the Apache HTTP web server. If putting etcd in a foundation makes it easier for other companies — even our competitors — to contribute to the project and help it be successful, we are willing to make the contribution.
Of course, there is always risk that by putting software into a foundation it actually has the opposite effect, slowing down the project. We believe that the approach CNCF is taking is spot on, but as we move forward we will be careful to do what is best for increasing the adoption of etcd and thus cloud native infrastructure.
For more information, watch CoreOS CTO Brandon Philips speaking at the Tectonic Summit about donating critical software to CNCF.
rkt: Shared Standards Need Multiple Implementations
CoreOS is committed to developing rkt into the most secure and production-ready container engine. With the advent of standardization in the container ecosystem, the existence of rkt is even more important: standards require multiple implementations to be successful. Early in the web era, the industry rotated through a single web browser having dominant market share: we first had Netscape’s web, then Internet Explorer's web, neither being truly open or interoperable. It wasn't until a proliferation of other browsers all had meaningful market share — Firefox, Chrome, Safari — that web standards started to work. In a similar way, rkt is our effort to create a highly differentiated but standards-based container runtime to ensure that interoperability and portability remain a strong priority throughout the adoption of the container ecosystem.
With OCI standardizing the low-level runtime layer, rkt and docker will be able to share plug-ins for executing a container. For example, Intel recently contributed Intel® Virtualization Technology support to rkt, via their Clear Containers project, allowing containers to be transparently wrapped in hardware virtualization — offering the best form of isolation for any container runtime. If OCI were in place, and both rkt and docker supported it, Intel would have been able to build the exec driver once, and have it used by both rkt’s and docker’s implementation.
Interoperability with Docker
We are committed to rkt continuing to be interoperable with docker, regardless of formal standardization. This means that you will be able to build your container images with docker, and run them with rkt. OCI does not currently cover the image formats themselves—meaning tools need to convert from a docker-specific implementation to an open standard. We will continue to work with the industry to have one shared standard image format, but until this happens, we are are committed to interoperability with docker regardless.
Join us as we continue our development efforts in OCI, CNCF and appc. We intend to continue swiftly charging forward on this path to enable interoperability and portability across all major, compliant operating systems and platforms without artificial technical barriers.