The container ecosystem map — from an engineer’s perspective, i.e., layer cake stack


Introduction:

I attended a 2-day conference Container World in Santa Clara this week and met quite some smart and enthusiastic folks there. I feel it’s beneficial to share some of the takeaways for those who did not get chance to attend the conference. Moreover, since the whole Docker/container ecosystem is rapidly evolving and people can easily get lost in the jungle, I feel I’d share from an engineer’s view point.

Thoughts on the Methodology:

Recently, Matt Miller from Sequoia Capital published a microservice ecosystem map, and people working in infrastructure space really liked it. At least, I saw several republish on my Linkedin friends (they mainly work on infrastructure space), and a huge number of ‘likes’ there. The original map is here, and if you have not read it, you should.

This post is heavily inspired by Matt’s effort but more from an engineering perspective. Here are the two major differences that this article tries to bring value to the readers. First, in Matt’s article, the diagram was mixed with company names and (open source) product names. As a company may ship several very popular (open source) products, people who want to conduct follow-up research may get lost which open source product Matt was exactly talking about in that building block/layer. Secondly, microservice != container infrastructure, though container infrastructure helps build, ship and run microservices, therefore some of the building blocks in Matt’s map are not necessarily in the core container ecosystem.

Another useful diagram people may feel educational is the Open Container Ecosystem Graph. This graph provided a thorough collection of related efforts in the container space. However, I personally feel it listed quite some projects that are not necessarily in the core container ecosystem, which made it a little busy. For example, the Cassandra project in the ‘BigData/Database’ bucket in the map, which is about how to run Cassandra in Docker runtime, is not necessarily something the core container ecosystem cares or should care about much — it was simply a use case. Furthermore, some of the projects in that graph have either already become irrelavant in the ecosystem (i.e., nobody cares anymore) or become not actively developed/maintained (open source zombies).

A Figure is Worth 1000 Words:

Engineers and engineering managers are good at visualizing system building blocks (a picture is worth 1000 words), and product managers are good at visualizing interface and contracts (managing roadmap, commitment and etc.). So a diagram is a great communication vehicle to align everyone on the same page.

# Edit on 5/2/2016 (change the box of Networking to reflect networking models and individual driver plugins)

Caveat:

A product in one block may include another product as its internal component in the above diagram. For example, Kubernetes includes etcd as its internal component. But I believe we should list them separately because they deserve being defined as independent functional blocks.

TODO

This is just a quick recap of what I got from the conference, and I’d love to improve over time this diagram to increase its accuracy with friends in the infrastructure space. (Send me a message if you feel something is missing or confusing)