Is the Kubernetes / CNCF ecosystem too big, complex, and fragmented?
For the 10th anniversary of Kubernetes, I was asked by a Kubernetes Steering Committee member what I thought the project’s most significant achievements were. My view is that it’s the scope of impact.
(Newbie question: Is there no way to make that image appear smaller?)
Kubernetes is pervasive. It runs on public clouds, private clouds, on the edge, on vehicles, and in places and for use cases we didn’t envision.
That breadth helped Kubernetes develop a large ecosystem, which was an explicit goal of ours. If you need a tool, extension, or off-the-shelf component, you can probably find one compatible with Kubernetes rather than having to build it yourself.
Within that ecosystem, Kubernetes has enabled and/or accelerated other innovations, such as service meshes, GitOps, and platform engineering.
However, with that magnitude of development comes fragmentation and a paradox of choice. The CNCF landscape has been described as a complex “hellscape”. Is the Kubernetes / CNCF ecosystem too much of a good thing?
Full disclosure: I was an inaugural member of the CNCF Technical Oversight Committee, and helped build the initial project portfolio and operating principles. I was supportive of the Sandbox because I wanted new projects to be able to be collaborated on under the CNCF, rather than in another foundation, as was the case in the Javascript ecosystem before the Node.js foundation merged with the JS foundation.
With that out of the way, let’s look back at the early days of the container ecosystem.
Mesos was reasonably popular among larger companies (power users) at the time, prior to integrating Docker. We decided not to build on Mesos for some of the reasons mentioned by its PMC members, such as problems with the information-hiding scheduler, programming language heterogeneity, ecosystem fragmentation caused by the low-level framework model, and overall complexity. Also, a number of Mesos users did not open-source the frameworks they built, which didn’t seem good for its open-source ecosystem.
Docker released libswarm, a library for connecting to Docker agents on other machines. CoreOS created Fleet, Etcd, and CoreOS for distributing containerized workloads across hosts. Rancher developed Cattle. There were a number of Platform as a Service projects built on or ported to Docker and numerous other tools for managing containers on a few machines. AWS launched ECS, a proprietary container service.
Before Kubernetes emerged as the leading open-source container orchestrator, the ecosystem was already very fragmented, just at a lower layer, similar in that respect to the Mesos ecosystem. By defragmenting the container orchestration layer, Kubernetes pushed the fragmentation, and innovation!, up the stack and reduced reinventing the wheel.
I think that was a good tradeoff, and worked as intended.
