Docker does follow the Unix philosophy: it's just that it's a unix-like collection of tools rather than a single tool.
Under the hood Docker is made of many small components which you can use separately if you want: containerd, runC, libnetwork, SwarmKit, HyperKit, VPNKit, DataKit, Compose, Machine, Notary, etc.
The 'docker' cli gives you a nicely integrated interface to all these components but you can use them separately too.
I don't think splitting a project up into libraries is what the philosophy describes. If I filter out the 1600+ issue in the Docker project right now, I can see many related to Swarm. Your users now inherit all of the bugs and necessary features of swarm even if they're only interested in using Docker on a single host. The Unix philosophy would also not commend the amount of duplicate effort that the Docker team is pouring into swarm when the problem of clustering have already been tackled by other companies and teams. One unix tool does not develop half of another unix tool, it just uses that other tools and relies upon the experience and expertise of the community. No, If Docker grows a sub tool to solve every problem, it no longer qualifies as meeting the requirements of the philosophy, and it certainly doesn't reap the benefits of compose-ability at the user level. I vote for separate tools and freedom of choice any day over one giant, precomposed tool. I think it's also discouraging that we will now see swarm slowly grow all the features of its competitors, when that engineering effort could have gone elsewhere. To summarize: Don't reinvent, prefer choice to lock in, composition is at the user level, not the tool level (libraries don't count). Plugins were a great step forward, built in swarm was a step backward.
It's the idea popularized by git. Use one namespace and you have related commands that lives under one roof. Compare that with postgressql which installs a bunch of generic names on the top-level (e.g. createddb) which is annoying.
The thing I would be concerned about is bloat. I enjoy and leverage dockers' fast boot up and lightweight containers. I hope they stay focused on this.
Docker's trying to lock in on enterprise customers. This has nothing to do with programming, and everything to do with encouraging lock in. I've lost a lot of faith in Docker. I thought they really cared about bringing containers to developers and fostering an ecosystem, but here we see them trying to oust out sysops competitors. Why compete in the container space when Docker wants to be the king of everything? Why put your trust in Docker as a developer when it's the enterprise they're after? There's still so many improvements to be made to the developer experience, still so many problems to be solved, but Docker is only interested in getting paid by the corporations that could care less. So no, the docker engine shouldn't be defining services and clustering. They touted plugins last year as the answer to extensibility, but of course now we're locked in to their idea of clustering. What their idea of a service is. If I were the Kubernetes team, I would be warning others about Dockers voraciousness. No one is safe as long as there is money to be had.
You can either have a bunch of different tools that do their own little thing and do them well and need a bunch of perl scripts and sysadmins on call to actually do anything useful, or you can have one large tool that does one meaningful thing and, by virtue of being one tool, does it well.
The UNIX philosophy is fine, it's just slowly escaping from the people who misunderstood it. (Oddly enough UNIX kernels have always been fine, partly because of the bikeshed principle, and partly because experimentally, doing a bunch of tiny things well doesn't actually get you a working OS.)
That I can agree with, but I still feel like there is a reasonable line to be drawn between application containerization and coordination and load-balancing of networked services.
My understanding is it follows the 'plumbing and porcelain' pattern; behind the scenes there are lots of small commands that do one thing and one thing well (the plumbing) and one command that acts as a wrapper over all these commands to keep things simple (the porcelain).
