Yes container images would become portable between systems, but if you hide the underlying system enough under abstraction layers what makes me choose between CoreOS or Docker or the future thing? What's the value difference?
Containers are useful if you have the build systems in source control, but if you don't, you don't know how to rebuild them or what is in them - they become dangerous in that case. They become scary "golden images".
Docker files were already very easy to regenerate things -- and I think interface wise, one of the more compelling wins. If there were other systems it's still likely they would have different provisioners.
It seems the (excuse me for the buzzword) value add then quickly becomes in the people providing management software for Docker, rather than in Docker, and Docker becomes more or less a subcommitee of a standards body.
I'm sure that's NOT true, but it's confusing why they wouldn't want to seek differentiation to me and what this means for valuation purposes.
> but if you hide the underlying system enough under abstraction layers what makes me choose between CoreOS or Docker or the future thing
From the Google/Amazon/Microsoft POV, that's part of the point.
From the CoreOS/Docker POV, the fact that the container technology that the major cloud hosts support is going to define their market whether they participate or not is probably why they have an incentive to participate.
> It seems the (excuse me for the buzzword) value add then quickly becomes in the people providing management software for Docker, rather than in Docker
Docker-the-company is probably going to be one of the "people" providing management support for the new standard container platform. From the advantage of also being one of the players defining the standard, and one of the key implementers of the basic software, which will give them an advantage in implementing management software.
> I'm sure that's NOT true, but it's confusing why they wouldn't want to seek differentiation to me
Sure, they want to seek differentiation. But they probably don't want differentiate themselves as "the vendor of the container technology that isn't backed by any of the major cloud hosts", when there is a container technology that is backed by those hosts.
> "Docker-the-company is probably going to be one of the "people" providing management support for the new standard container platform"
You would think, but it seems Kubernetes, CoreOS, ECS, and Mesos are the obvious picks right now for management stacks. Docker could drop the shiny UI on top of swarm/other soon, sure, and then they could build off the name-recognition, but they are definitely letting everyone have a running start. There's something said for last-mover advantage, but these types of apps are also non-trivial in storage/networking/other areas and somewhat hard to displace.
Obviously I am biased (working on Docker), but I thought I would mention a few facts.
- Today AWS announced they would support Docker Swarm and Compose natively on ECS.
- Last month devops.com surveyed development and ops teams about their usage of containers. Their conclusion was: "While this is still a nascent market, some early leaders did emerge from the responses. Docker Swarm, the orchestration technology from Docker itself, was the clear winner, with nearly 50% of respondents indicating that they planned to investigate Swarm. Close behind were Kubernetes and Mesos."
Personally I think the important part of that quote is "this is still a nascent market". We are the very, very beginning of these sorts of platforms, and nobody really knows what these platforms will evolve to be in a few years. So I really don't think it matters who has the most "market share" of the 0.00001% of IT organizations actually aware of these tools. The innovation is only just getting started.
>Yes container images would become portable between systems, but if you hide the underlying system enough under abstraction layers what makes me choose between CoreOS or Docker or the future thing? What's the value difference?
Obviously tooling and support?
(It's analogous to asking what makes you chose between programming editors since they all edit text files? Or what makes you chose between distros, since they all run Linux and the usual userland)
Bu commoditising the docking point e.g. AWS/Google/Azure to whom rent is paid is not the same as buiding a distro for distribution which will be to the builders particular idiom.
I choose a distro based on the package manager - I'm used to Debian so I generally prefer apt based distros to play with.
I prefer BSD over Linux and plan9 over all of them but the are not fungible.
I do pay my supplier a monthly fee to host my container, and for that the metrics is (bandwidth + speed + storage space) / price
More so asking about business/product value, given Docker's investment levels (congrats on this) and that other companies are seemingly doing container management better and investing more labor here. This seems to leave Docker with (A) DockerHub or (B) a foundation for profit options. Both might be totally valid, but it's unclear.
Sorry for crossing streams.
That standardization makes it easier for the orchestration companies and clouds is obvious. I'm just legitametly curious what this means for Docker, Inc and the business model, since it seems to be seeding the lower end, and they haven't invested in the upper end as much -- Docker itself not being a tremendously large amount of plumbing, and all OSS, it's easy to replicate. So what they have is basically support and the leadership of that community.
As right now, this reads like I'll be able to use everything on Mesos/CoreOS/ECS and just swap out a backend, it's unclear why I would want to pick things from Docker Inc. It's like I get pluggable tooling where all the frontends can speak to backends and the image format is the same -- so it seems differentiation would have to happen at the top in the tooling, which is weird seeing efforts have gone into the bottom end and other companies have done a lot on the top.
Perhaps some messaging to address. Perhaps there's enough funding that this isn't a concern even for the next five years. I don't know, but I'm curious. It's useful to know this to tell where container-land is going, and it's an uncertain time in which management orchestration software to pick for running Docker clouds. (We can probably guess ECS is going to be around, roadmaps of others subject to speculation)
Mostly because I find the evolution of tools in this space interesting.
If you're interested in Docker's opinion on this topic, I recommend that you watch today's keynote. That's where we introduced runC and where we explain why.
They're building a playing field and funding teams in the hopes you will come and buy tickets, popcorn, beer, novelty hats, etc. The value add to them is they have created an entirely new marketplace in which to sell you crap. The value add for you is simply that all the teams will play on the same field.
I'm unclear what value this adds in the end
Yes container images would become portable between systems, but if you hide the underlying system enough under abstraction layers what makes me choose between CoreOS or Docker or the future thing? What's the value difference?
Containers are useful if you have the build systems in source control, but if you don't, you don't know how to rebuild them or what is in them - they become dangerous in that case. They become scary "golden images".
Docker files were already very easy to regenerate things -- and I think interface wise, one of the more compelling wins. If there were other systems it's still likely they would have different provisioners.
It seems the (excuse me for the buzzword) value add then quickly becomes in the people providing management software for Docker, rather than in Docker, and Docker becomes more or less a subcommitee of a standards body.
I'm sure that's NOT true, but it's confusing why they wouldn't want to seek differentiation to me and what this means for valuation purposes.