March 24, 2017

Docker is an open-source platform. But how open is the container ecosystem as a whole? That’s a question worth considering as organizations make plans to migrate to containers.

To be sure, most of the core technologies on which containerized workloads are built are open-source. Those technologies include all parts of Docker, from Docker Engine to Swarm to Docker Hub.

In addition, many complementary tools are open-source, such as CoreOS’s suite of container storage and security solutions, such as etc2 and Clair. So are most container orchestrators, such as Mesos and Kubernetes, and most registry options.

The Standardization Challenge

However, an open-source code base is not the same thing as a totally open ecosystem. Even though most container stacks can be built using said code, the container ecosystem is still struggling to agree on universal standards for the way containerized workloads should be configured and managed.

Debate over the Open Container Initiative, or OCI, is the most obvious example of this lack of standards. The OCI’s goal is to define common standards for containers. At first, it was unclear whether Docker would sign on to the initiative. Then Docker did sign on, and even helped to build an OCI standard around runC, Docker’s container runtime. For a while, everything looked peachy. But this fall, the waters rose again when Red Hat announced OCID, an alternative implementation of runC.

OCID doesn’t mean that the Docker-approved container standards are falling apart. In theory, OCID’s runtime and Docker’s runtime will be built according to the same standards.

Still, things start to feel less open when you have multiple versions of the same technology built by companies that are clearly frenemies when it comes to containers. The runC runtime may be standardized today, but it’s hard to have a high level of confidence that everything will remain the same and mutually compatible in the future.

Closed-Source Components

There is also the issue of container products that are not open-source. Take FlawCheck, for example, which was acquired late last month by Tenable. FlawCheck had built one of the most advanced container security products on the market. But it was not open-source. Implementing FlawCheck means accepting all of the baggage and worries about vendor lock-in that come with closed-source technology.

The rising popularity of containers as a service, or CaaS, platforms also complicates the openness of the ecosystem. Cloud-based CaaS services, such as Amazon ECS, are built mostly with open-source components. But because they run in the cloud, users can’t modify the source code behind the CaaS implementation or otherwise tweak the configuration. They may as well be closed-source when it comes to being able to customize the services.

The Bottom Line

True openness is hard to define. The container ecosystem is open in many senses, especially when it comes to the nature of its code base. But in some important respects, it is more closed than their licenses would suggest. That’s important for organizations to keep in mind as they evaluate how much control and portability they will have when they adopt containers.

Christopher Tozzi

Christopher Tozzi has covered technology and business news for nearly a decade, specializing in open source, containers, big data, networking and security. He is currently Senior Editor and DevOps Analyst with Fixate.io and Sweetcode.io.

  • dennyzhang.com

    Good to know that. Thanks.

    Hope Container community can resolve the dispute between “docker swam” and “kubernetes” soon.