Next week I’ll be participating in the inaugural Cloud Field Day put on by Stephen Foskett and his merry band of Tech Field Day folk in Silicon Valley. As is my usual practice, I like to spend some time preparing for these events and learning a little about the companies presenting.
I’m already aware of Docker, but I can’t say I’m particularly familiar with them. Learning more about the details at Tech Field Day Extra at VMworld 2016 last week was certainly useful, and I look forward to getting deeper into things.
I also recently discussed Docker and containers on several episodes of The Eigencast. In episode 020, Red Hat’s Lars Herrmann and I discussed how the container image format isn’t the part of Docker that most interests me. It’s the way the technology acts as a forcing function for the people and process of organisations who adopt containers as a deployment method.
Immutable deployment units forces developers to completely rebuild everything whenever something in their application changes, which help to keep production in sync with development. Containers aren’t required to make this happen, but they make it easier because the technology enforces discipline, rather than depending on humans to have discipline. Humans suck at discipline, as I can personally attest.
The processes used for container-based application development also decouple teams from one another in specific, known ways. Again, this is completely possible if IT teams have the required skills and discipline, but guess what? They don’t. Containers fixes this issue, and also makes the solution portable across organisations. This is great for scale. Imagine if every organisation had its own programming language, instead of there being relatively few standard ones like C, Java, Python, etc.
Externally imposed standards force organisations to use a specific set of tools and processes instead of allowing them to have choice. All that choice has resulted in both poorly implemented systems (ITIL anyone?) or analysis paralysis as organisations constantly try to figure out what the best option is, instead of adopting a process of continuous improvement where things constantly get better incrementally.
The critical issue for Docker is that their way is just one way to achieve this overall goal, and there are plenty of competitors (e.g. Kubernetes) who would love to take over. Docker the container standard is one thing, but Docker the commercial entity is quite another. To remain viable, Docker the company will need to find a way to get people to pay for what has so far been given away for free.
It’s possible they could become the VMware of the new container-based world, but is that thinking big enough? Or is more modest commercial success enough? Will the investors who have so far tipped over $180 million into the company settle for anything less than a massive payoff? Will Docker manage to find an ongoing source of revenue big enough to justify this sort of investment?
Pingback: CFD1 Prep: Docker - Tech Field Day