3 ms·
I mean- AWS, GCE, and Microsoft are already on board, and AFAICT all the little container centric providers are 100% docker. Who else needs to be convinced?
by krakensden 11y ago
I mean- AWS, GCE, and Microsoft are already on board, and AFAICT all the little container centric providers are 100% docker. Who else needs to be convinced?
- geerlingguy 11y agoThe problem, in my mind, is that as other container formats that have been in the shadows due to Docker's huge mindshare could easily supplant Docker if other major providers start switching their language away from 'Docker containers' to just 'containers' (witness existing language around ECS from Amazon), and pointing to a different format as their de-facto standard. Hosting companies will do what's in their best interest, and competing against an 'official' Docker container hosting solution might be less appealing than telling customers about their own system that uses (what may or may not be) a 'better' container format.
- enos_feedler 11y agoWell the bigger problem is if there becomes multiple container formats and everyone doesn't adopt the same one. Hopefully when everyone talks about "containers" in the future they are referring to OCI compatible ones. I don't think companies should want to lock you in with container formats. The ones that do should die. They should lock you in with services. IBM should lock you into its cloud by making you depend on Watson API, for instance.
- outside1234 11y agoWell, I would say all of those companies are convinced of the open source container engine itself, but much less around Swarm, Compose, and the other components. In particular, Mesos seems super strong in the orchestration/scheduling layer, and its not clear that Docker will be able to dislodge them.
- SEJeff 11y agoI honestly think it solves a different problem. Apple runs Siri on the biggest mesos cluster in the world (pretty much verbatim quote from MesosCon 2015. I was there). Twitter runs clusters over 10k physical nodes. Swarm and compose are cute, but they simply aren't made for that kind of massive scale. The inverse of course, is that they are incredibly easy to setup, and they work for a very large number of workloads reasonably well. I manage mesos clusters as part of $day_job. There is a certain level of setup required and if you don't need the scale, you simply don't need mesos for it. I really see them as complementary in the longer term. Perhaps a swarm mesos framework could be written. It is highly unlikely that Docker will ever do the resource scheduling better than Mesos.
- nickstinemates 11y agoGreat points. There is a swarm/mesos integration whereby the Swarm API is offered to the developer but it uses the Mesos framework to do the scheduling. It works, and there's more to come in terms of demos around the corner.
- SEJeff 11y agoAnd that is the sweet spot where you get the ease of swarm with the scalability of mesos. Win/win
- nickstinemates 11y agoBoth Microsoft and Amazon have deeply integrated Swarm & Compose, with more coming. Both Microsoft and Amazon offer the Docker Subscription service on their respective Marketplaces and have active campaigns to promote them. There are Docker Machine drivers that operate with every major cloud provider, allowing you to spin up new Docker nodes in seconds. And as mentioned elsewhere in the thread, swarm integrates with Mesos and you can imagine any pure resource scheduler/framework can be integrated. Our goal is to provide the Docker experience to developers while being able to target disparate infrastructures, some of which are built purely with Docker and others built with an aggregation of tools.