| THE STORY OF THE CONTAINER GOLDRUSH As seen by a verbose, presumptuous 22 year old. OPEN SOURCE MOVEMENT lays foundation for containerization: - linux kernel gains mainstream adoption, becomes standardized across distributions - kernel matures to support containerization (i.e., namespacing critical OS operations) - lxc project takes advantage of kernel support, builds tooling around namespace containerization DOCKER (THEN DOTCLOUD) is first company to capitalize on power of containerization: - dotcloud demonstrates clear use case for containers, encouraging developer adoption - dotcloud releases internal infrastructure code ("moves up the value chain") for PaaS - dotcloud develops project into docker, builds existing momentum into early adoption of docker. AT THIS POINT other companies begin to emerge around Docker, e.g. CoreOS. Key facts: - Docker is an abstraction around LXC, effectively a set of convenient scripts for controlling LXC - Docker is building a platform via a package management system preloaded with their repos - Platform is a threat to new entrants, e.g. CoreOS, because they risk becoming tenants CoreOS realized the risk of the Docker platform, and also that Docker is unnecessary for many of its value-adds. Everything Docker can accomplish, raw linux containers can also accomplish. The problem is that scripting LXC is less convenient than using Docker, but Docker depends on LXC, therefore LXC featureset will always be ahead of Docker. In the developer community, there is a growing acceptance of the fact that Docker is an abstraction over LXC. CoreOS is trying to standardize the abstraction as an implementation of the "app container spec" [0]. This spec puts Docker, Rocket, and lxc-tools on level playing ground. Despite this apparent acceptance, the market continues to build tooling and platforms around Docker, instead of raw LXC containers. This announcement from Microsoft is just the latest example. If a new product wants to support containers, it needs to support Docker. Docker is benefitting from network effects even though its product is not defensible from a technical standpoint. Docker is signing deals with competing enterprises like Microsoft, Google, and Amazon, because those companies are its customers. The risk for Docker is that these big companies eventually cut Docker out of the equation. They may eventually choose to replace Docker with their own "app container runtime," with features only supported on their own platform. Docker was one of the first companies to capitalize on advantages of containers, probably because they have a seriously talented group of engineers writing their code. But the market has now woken up to these advantages, and Docker is being chased by massive companies with massive resources. I hope they can fend them off and keep the upper hand in the relationship, but unfortunately I think it far more likely that Docker will eventually be cut out of the equation or acquired by one of them. This will result in a fragmentation of container technology as each company rushes to develop their own app runtime engine. Ultimately developers will suffer as platforms divide and silo, increasing developer friction and reducing cloud market competition as users consolidate around the single platform with the most momentum. Eventually, I suspect one company will control 80% of cloud computing. [0] https://github.com/appc/spec/blob/master/SPEC.md |
Others "realised" the value of this later and started improving upon the ideas contained within.
Although I'm sure many might argue that this is the natural conclusion of virtualization.