By “Cloud Native Computing Foundation,” of course, I mean Kubernetes. At least for the time being. The CNCF
was created originally as a neutral home for Kubernetes, and now plays host to a bunch of complementary technologies, as well. Its original membership of a handful of container-focused companies has expanded to dozens of vendors and even some big end-users.
There’s almost too much history to unpack here, but the very short version is that as Docker the company grew, it started building more stuff into Docker the open source project, a move that rubbed many users and ecosystem players the wrong way. This led to competing technologies (including rkt) and, ultimately, the Open Container Initiative
, which helped spur a stripped-down, industry-standard container format and runtime (runC). containerd, a stripped-down, modular version of the original Docker daemon, manages runC.
Here is some background reading (and I mean a tiny sampling from a huge body of work) on some of the technologies and business factors at play:
The CNCF came about separately (although both are Linux Foundation projects), but really is fruit of the same tree as far as Docker is concerned. Whether it was Google’s original intention or not, Kubernetes helped further the notion that containers themselves should be dumb, modular commodities. Let the orchestration platform do all the work; no need for any company’s bloat or other funkiness in the containers themselves.
To Docker’s credit, it has been instrumental in helping launch the OCI and—clearly, with the submission of containerd—to helping advance the CNCF causes. But I would argue this hasn’t always been by choice. Docker—borne and bred of open source—has to listen to its community or risk taking an incredible amount of flak. Or, worse yet, risk losing users and coming down on the wrong side of history.
In fact, Docker’s completely understandable (and, arguably, necessary) decision to compete against Kubernetes with Swarm, and integrate that into the core Docker components, only exacerbated calls for an alternative.
When I say that CNCF is winning the container wars, I’m not suggesting it’s doing so by playing unfairly or even, really, by fighting. It’s able to determine the pieces of the cloud-native stack because it has a large community, good technologies and is just so damn open. Even Kubernetes, the CNCF’s linchpin project, is no longer just a Google joint; one of its creators is managing container services at Microsoft, and the other two started a Kubernetes company called Heptio.
When you say “Kubernetes” you are not, in fact, implying any specific vendor. You could be talking about the open source project, or any of the various distributions and services built upon it. Being bigger than any one vendor is critical to any open source project that’s aiming for revolutionary impact.
Companies that develop what the container community calls “boring infrastructure” aren’t forced to join the CNCF or donate their technologies to it, but it sometimes might feel like they don’t have a choice. You can either try to become an anointed component of the new application stack and hope it results in paying customers, or you can go it alone against one of the world’s most-popular open source projects and the technologies pulled in by its gravitational field. If you don’t contribute that that core functionality, someone else probably will.
I guess what I’m trying to say is that open source coopetition and modularity are great for users, but not always great for the companies involved. There is huge opportunity in front of every company in the container space right now, but with the CNCF seemingly calling the rules of the game, everyone else needs to play their cards very carefully and (at the risk of mixing metaphors) always look a few moves out to see where they’ll be competing, differentiating or assimilating down the road.