HNHacker News
TopNewBestAskShowJobs

potto

24 karma · joined April 15, 2013

Principal DevOps Consultant and Co-founder of Otto Ops LLC
submissionscomments
potto··on Announcing Docker Machine, Swarm, and Compose for Orchestrating Distributed Apps
Have you participated in any other open source projects? All of them with any success in the community (that I can think of) have a monarchy or oligarchy at the head. Anyone may contribute, and a group of committers review and add if the contribution fits the project... who determines what the project and its roadmap? Usually a select few, driven by even fewer or just one. So I don't think it's necessarily unusual that Solomon heads it.

As an aside - I've watched headless projects devolve into anarchy... here's a good read from years ago - http://ariya.blogspot.com/2008/03/common-characteristics-of-...

potto··on Announcing Docker Machine, Swarm, and Compose for Orchestrating Distributed Apps
Why would you have to sign a NDA to create an open source ecosystem around an open source project with an Apache 2.0 license?
potto··on Announcing Docker Machine, Swarm, and Compose for Orchestrating Distributed Apps
While it is scary when a company takes its initial success in the technology scene and uses it to expand into its verticals, this is not quite the same case as the Microsoft analogy...Docker is open source, after all. I think the backlash that CoreOS started with its Rocket / AppContainer announcement ahead of DockerCon has caused some knee-jerk reactions.

Does Docker's expansion into orchestration and clustering endanger CoreOS and maybe other players? Certainly. Is it the same approach? Definitely not. The CoreOS approach to containerization using Docker, and now Rocket, is novel. I haven't considered it for any of the architectures I'm presently building for companies - I prefer to let the operating system do what it does best, and build my services on top using containerization.

I was worried about what Docker's plans for clustering entailed leading up to today. I have been using Mesos for the better part of a year, and see it answering many problems that reach beyond the container model. I think people should do as you suggest, and re-evaluate this on two fronts: 1) Swarm is separate from Docker, so we can continue to deploy Docker through Mesosphere Marathon onto Mesos as we've been doing. 2) Because scheduling is pluggable - as the source code validates for us - we can work in Mesos as we see fit.

As for the proposal, I vote to keep Compose (and the fig codebase ;) ) separate. It will be much easier to add the hooks necessary to do cluster management between Compose and Swarm without risking regressions to Docker.

Also - what has become of the Docker Governance Advisory Board? I think the ratification of a standard / specification would go a long way to solidify trust in the industry (much like CoreOS is trying to do with their App Container proposal).

- Paul