Hacker News Reader

Comment by kozikow | Hacker News Reader

I wish that docker would adapt more of a Unix philosophy and focus on doing one thing well. Why does everyone have to compete with everyone rather than create set of tools that work well together?

I see docker-machine and docker-swarm as distractions. Reasons why doing all those other things, instead of focusing on containerisation and packaging may be harm-full for docker itself:

- Bundling-in the orchestration with docker make k8s or Mesos more inclined to fork docker and pull out unnecessary cruft.

- Churning out half-ready features causes Docker to be known as unreliable and leads to posts with titles like this. Such reputation tends to stay long after bugs are fixed. SV-esque launch and iterate works for web apps, but IMO not for back-end software.

View on HN

"In infantry battles, he told us, there is only one strategy: Fire and Motion. You move towards the enemy while firing your weapon. The firing forces him to keep his head down so he can't fire at you. (That's what the soldiers mean when they shout "cover me." It means, "fire at our enemy so he has to duck and can't fire at me while I run across this street, here." It works.) The motion allows you to conquer territory and get closer to your enemy, where your shots are much more likely to hit their target. If you're not moving, the enemy gets to decide what happens, which is not a good thing. If you're not firing, the enemy will fire at you, pinning you down."

From one of Spolky's finest, Fire and Motion: http://www.joelonsoftware.com/articles/fog0000000339.html

"If only the Generals had not been content to fight machine-gun bullets with the breasts of gallant young men, and think that that was waging war."

- Churchill 1931

I want you to think very seriously over this question of poison gas. I would not use it unless it could be shown either that (a) it was life or death for us, or (b) that it would shorten the war by a year.

It is absurd to consider morality on this topic when everybody used it in the last war without a word of complaint from the moralists or the Church. On the other hand, in the last war bombing of open cities was regarded as forbidden. Now everybody does it as a matter of course. It is simply a question of fashion changing as she does between long and short skirts for women.

- Churchill 1944

"War,” writes von Clausewitz, “is an act of violence intended to compel our opponent to fulfil our will…This is the way in which the matter must be viewed, and it is to no purpose, it is even against one’s own interest, to turn away from the consideration of the real nature of the affair because the horror of its elements excites repugnance.”

Supreme excellence consists of breaking the enemy's will, without fighting -- Sun Tzu

This!

This analogy perfectly captures why in software, the second best thing always wins :-) [1]

The utopian 'ideal' systems that can only be built slowly and methodically get crowded out by the systems that start with some scruffy code just keep moving.

[1] UNIX vs Multics, Windows vs OS/2, MongoDB vs ?

In the infantry, we learn "Shoot, move, communicate".

"- Bundling-in the orchestration with docker make k8s or Mesos more inclined to fork docker and pull out unnecessary cruft."

Mesos 1.0 already introduced the universal containerizer, allowing to run many docker images natively without the docker daemon:

https://www.youtube.com/watch?v=rHUngcGgzVM&index=14&list=PL...

http://mesos.apache.org/documentation/container-image/

Because shipping features is king. When a single vendor ships many products, those products are more likely to work well together than with products from other vendors because they were built under the same roof. Better integration = saving time while reducing risk = more time to build and ship features.

The downside, of course, is vendor lock-in. But that's only a problem if a) the vendor stops updating their products, which is unlikely if those products are popular, like Docker, or b) the vendor raises prices beyond what can be justified to remain that vendor's customer. But that's a problem for whoever takes over your project next year, not for you.

I would say that the worst problem is the vendor changing the product in some incompatible way as part of a monetization strategy, so that Product X still exists, but the install-base splits.

Docker Inc. themselves make a big play of the facts that containers have to be standardized to be portable, and the portability is the key value. We could have done a lot of this stuff years ago if the virtualization vendors had a totally portable format for transferring VMs between different systems.

Swarm etc. is part of the monetization strategy - other vendors in the ecosystem have already backed Kubernetes, or MesoSphere, or whatever, and do not want or need this stuff tied to the Docker run-time itself. Fortunately, Docker Inc. can add these without breaking compatibility of images or damaging the core features enough that a fork becomes necessary, but it does create market confusion.

Everyone tries to get the 100% of the orchestration pie. Pie gets smaller as barrier of entry is higher due to the fragmentation.

If those companies would focus on securing position in the pie, rather than owning the whole pie, the pie would grow quicker and thus the absolute returns of each player could be better.

This attitude is destroying their ecosystem. Many integrating authors (not going to name names, but plugins, et al) are feeling the heat and focusing their efforts on Kube and Mesos because Docker will just replace your shit with a half-baked thing in 6 months and everyone will flock to that.

Conversely, it's not been a surprise for those of us embedded in this community for a long time to see Kube and rkt join forces. There are a ton of both technical and political decisions behind this and unfortunately most of the political barriers end in the name Hykes.

As a very well-funded startup, they can't just build tools that do one job. They have to build a complete platform.

Reply on news.ycombinator.com