8 ms·

I think the community really ought to take a good minute to consider, beyond technical reasons, whether it really makes sense to so tightly tie the future of co

by themgt 12y ago

I think the community really ought to take a good minute to consider, beyond technical reasons, whether it really makes sense to so tightly tie the future of computing to a single for-profit company's quickly enlarging platform. Someone below compared this to systemd - it's really more like your entire containerization operating system. And since you run everything via containers, it effectively is your operating system/platform. So, clearly they (and CoreOS, etc.) will want to monetize their container operating system/platforms. But is it really a good idea to build the entire industry's concept and implementation of containers themselves on the back of a single company's implementation, when we know a healthy ecosystem would see a number of companies with competing implementations of container OS with varying degrees of compatibility, and hopefully eventually open standards. I really am beginning to see the CoreOS guys point here - if Docker could have just stuck to running containers and doing that awesome, there would have been space for other companies to build out the ecosystem around that shared interoperable container format. But if Docker is now set on tightly bundling a toolchain for the container operating system around their format, suddenly it looks a lot more like they took a Microsoft embrace-extend-extinguish approach to LXC. And thus the need for Rocket.

numair 12y ago
Docker's overreach seems to resemble the overreach of Joyent in the io.js world. It's really hard to regain trust and momentum once the community starts to question you; in economic terms this would be termed as "a spike in transaction costs." If I were Docker, my next project would be a meetup/presentation/etc explaining how my new initiatives are for the benefit of the community, rather than just self-serving wheel reinvention. This isn't a consumer-facing business; the opinions of concerned developers can make or break them.
- Alupis 12y ago
  > my next project would be a meetup/presentation/etc explaining how my new initiatives... You mean like the conferences they held before they even had a viable product? Docker has stampeded onto the scene with zero competition, and the Parent comment is totally right -- we should take a good minute and consider that we are head-first rushing to implement everywhere a product made and perpetuated by a for-profit company who's end goal is literally to be on every server and be the de facto implementation so that once they start to monetize the product, you will have little choice but to funnel support funds into their company. That's petrifying to me, because it means if realized, my company will be at the whims of Docker, not the other way around. Furthermore, the backlash from the Docker creator himself the other day on the announcement by CoreOS, it really seems Docker never anticipated ever having any competition in this space, and have taken active steps to ensure they are their own custom thing that is not compatible with other existing or future container implementations. Perhaps this will change now, and they will work with CoreOS to clearly define a universal specification for a container which can be portable between any implementation, but signs show they don't feel it's in their company's best interest to do so (and honestly it isn't in their best interest, but it's in the community's best interest for sure).
  - ldlework 12y ago
    > You mean like the conferences they held before they even had a viable product? The conference was awesome and there was plenty to announce at that point. It certainly helped drive home the conceptualization of containerization for many. > we should take a good minute and consider You're right we should consider - except what you're doing is making charges like; "we are head-first rushing", "perpetuated by a for-profit company", "my company will be at the whims of Docker" And other fear in this thread without providing your audience with the context of: - for profit companies backing an innumerable number of major technologies in a variety of fields since technology was a thing - most of the development of Docker happens outside of Docker Inc - the project has an independent governance board - the project has been nothing but the epitome of successful transparent open source If Docker ends up achieving a cohesive ecosystem of holistically designed pieces solving one of the most difficult unsolved problems (a class of problems, really) in modern computing benefiting so many then is it really a problem paying Docker Inc for first class support to all of that? I imagine there are already companies selling support for Docker other than Docker Inc It seems like you're the one imagining there is going to be no competition, honestly.
hosay123 12y ago
> it looks a lot more like they took a Microsoft embrace-extend-extinguish approach to LXC That's overstating things slightly, since it appears no Docker employee has ever contributed a single line of code to the LXC implementation itself (that would be hard work, rather than bikeshedding userspace tools, after all). The kernel tree contains only one reference to a Docker bug, fixed by a Red Hat employee, while the LXC tree contains a single reference to a Docker bug, fixed by a Canonical employee who looks to be one of the LXC maintainers. The reality is replacing Docker isn't all that hard, as we're now seeing with Rocket. The kernel interfaces aren't tied to it (hell, its clear from Git logs the LXC devs are barely even aware of it). edit: It's simpler to look at Docker and Rocket for what they both are: commercial plays built on the work of others. That work hasn't magically disappeared somewhere, it still exists and is in use (albeit by a slightly less PR/buzz-aware side of the community). A vendor-independent implementation of containers already exists, as it did long before Docker did. If people are serious about seeing the "container ecosystem" flourish, they should be contributing cash, employment offers, or employee time to the real people and projects doing the work (as opposed to publishing upset blog posts and writing fashionable Go code)
- VieElm 12y ago
  I'm pretty sure the CoreOS CTO, Brandon Phillips, has personally made many significant contributions to open source, just check his GitHub[1], and is a Linux kernel developer. He's been an open source contributor for a very long time. [1] https://github.com/philips?tab=repositories https://github.com/philips?tab=repositories
  - hueving 12y ago
    He meant docker doesn't contribute in that context.
- tlrobinson 12y ago
  Just curious, are you doing anything to support the container ecosystem, aside from publishing upset Hacker News comments? I think the strong interest in Docker demonstrates there's a need for a layer on top of LXC. It's open source, so what's the problem?
shingler 12y ago
I don't think there's any danger as long as everything is open and interchangeable, and you can steer clear of Docker (the company) even if you like Docker (the format). So far that's basically the case with all of the Docker projects. Ideally in the future, Docker will become an HTTP for servers, with standardized and competing servers/clients/services. I like the idea of that future. Publically, the Docker folks seem open to it. However, I do see where you're coming from. As a for profit Docker has every incentive (perhaps even fiduciary duty) to pull the good ol' technology bait-and-switch: get Docker on every server, and the create a Kafkaesque technology dilemma to squeeze the dollars out of everyone who bought in. Microsoft's playbook has plenty of tips on how to do this. I guess the only solution as a Docker user is to be hypersensitive to any sign that Docker wants to start locking the technology to the company. When you can imagine the day you can't use Docker (the containers) without Docker (the company), it's time to run the other way fast. But I can't see that day yet, and I hope I never do. And I hope Docker as a company can find a way to grow without using that oldest, sleaziest trick in the book.
- deleted 12y ago
  [deleted]
- Alupis 12y ago
  We should probably note this 'shingler' account was created exactly at the same time this post was submitted to HN, and this is the account's first comment... in support of this article. I'll leave you to decide what that means...
  - shykes 12y ago
    Probably has something to do with this: https://twitter.com/solomonstre/status/540559322070392834 https://twitter.com/solomonstre/status/540559322070392834
    - Alupis 12y ago
      Your post had exactly 5 re-tweets when you posted your comment just now (not exactly an onslaught of new listeners rushing to HN for the first time). Regardless -- Your twitter post came almost 30 minutes after the account above was created and 30 minutes after this article was submitted to HN.
jpetazzo 12y ago
The comparison with systemd is unfair. Docker wants to be "batteries included, but swappable/removable". If you don't like host management, orchestration, build, etc., you can disable that specific component and put another one; and none of those components are strictly necessary. Contrast with systemd, where it's impossible to use anything else, and the attitude of the maintainers is "our way or the highway" when people beg them to continue to support alternatives. Compare Docker to frameworks like Django or Rails, which come with everything you need (templating, ORM, url mapping, etc.) but where each thing is replaceable if you don't like it; versus Rocket which would be like Flask or Sinatra, which are smaller and require to be combined with other things to be useful. Nothing wrong with either approach; but if the comparison is right, we can expect Docker to provide "reasonable defaults", and some people building some specific apps to use Rocket because they just want to run things and they don't need build/orchestration/API/etc (or they need special versions of those components).
- shykes 12y ago
  Jerome don't forget that Django is monolithic. Docker is modular (ie swarm and machine are entirely separate binaries).
  - nostrademons 12y ago
    You can use Django as swappable libraries. I worked on some projects at Google that used Django for the request routing, templates, and helpers, but completely swapped out the ORM for Google's own RPC system. Jinja2 is basically the Django templating language pulled out into its own library; before it existed, people would just use django.template. Some folks just use the ORM and request routing and then stick a JSON serializer on top to send data to an Angular SPA.
- 23david 12y ago
  Systemd is a fair comparison. Systemd is a modular system, and it's also possible to not install different components if you want. Most of the components aren't strictly necessary. I think your community is begging you to continue to support alternatives. You just aren't listening.
jacques_chester 12y ago
> And thus the need for Rocket. Actually, I'm going to say: thus the need for Cloud Foundry. I work for Pivotal Labs and I'm secondment to the CF Buildpacks team, so I'm biased. And this shouldn't be construed as official opinion, it's just mine. Cloud Foundry is led by Pivotal, but we run it openly. Anyone can follow our repos[1][2] and our Tracker projects. The entire platform is being signed over into an independent Foundation with more than 30 paid members[3] (including Docker Inc). The whole project is being written the Pivotal Labs way. Everything is TDD, everything is pair programmed. If I had to bet a company on a platform, I'd bet it on us. We're building the first and only truly independent, truly open source, truly open core, truly multi-company PaaS that is available. You can buy support and hosting from us, IBM, HP and a series of mid-tier providers right now. You can do it in the public cloud or in a disconnected datacentre. Oh, and we're going to have baked-in Docker support with our next-gen executor (Diego), in addition to Warden system we developed before Docker was released. [1] https://github.com/cloudfoundry/ https://github.com/cloudfoundry/ [2] https://github.com/cloudfoundry-incubator/ https://github.com/cloudfoundry-incubator/ [3] http://cloudfoundry.org/about/index.html#the-cloud-foundry-foundation http://cloudfoundry.org/about/index.html#the-cloud-foundry-f...
biot 12y ago
> if Docker could have just stuck to running containers Do you argue the same for Amazon with AWS? They should have just stuck to running VMs on EC2 backed by S3? Amazon should not have added databases, scaling, load balancing, caching, DNS, email, search, analytics, etc. and left that up to the community to provide? Do you argue that Amazon has taken an embrace-extend-extinguish approach to AWS?
- 23david 12y ago
  AWS started as an open-source community project boasting contributions from over 650 contributors? Recent post by Docker CEO Golub: There are over 650 contributors (95% of whom do not work for Docker, Inc.). http://blog.docker.com/2014/11/docker-governance-advisory-board-output-of-first-meeting/ http://blog.docker.com/2014/11/docker-governance-advisory-bo...
  - biot 12y ago
    That's a non-sequitur. Are you trying to suggest a relationship between an open-source project with many contributors and a requirement to avoid building a complete platform? If so, could you provide an argument behind your statement?
  - njs12345 12y ago
    If you looked at volume of commits it might tell a different story - I'd imagine commits by contributor would follow a power law, so you might well have a project where 5% of the contributors made more than 50% of the commits, for example.
    - shykes 12y ago
      Take a look at the article, there is detailed comparative data on volume, response time, merge rate, split by Docker inc employees and non-employees.
- jon_dahl 12y ago
  A lot of people have this fear. Amazon is a quickly expanding platform with a growing level of lock-in and immense power. This isn't good for the ecosystem - a dominant company can charge a premium, and choice is good. Full disclosure: I say this as a founder of a higher-level cloud service (Zencoder) that Amazon decided to compete with head-on. We're doing just fine, thanks (growing quickly, differentiated product), but Amazon is aggressively expanding upstream and is going to continue to do so.
kordless 12y ago
> tie the future of computing to a single for-profit company's quickly enlarging platform The 'future' of compute is ubiquitous trustworthy compute for all. A federation where no one entity controls a pool of power over a given layer of the stack. The layers that run on top of that layer will continue to divide and stratify themselves, as it always has been. They will also assuredly be owned by someone or something. My vote is the something.
girvo 12y ago
> I really am beginning to see the CoreOS guys point here - if Docker could have just stuck to running containers and doing that awesome, there would have been space for other companies to build out the ecosystem around that shared interoperable container format. It blows my mind that on Hacker News of all places, people are suggesting that the Docker folk should not compete because it might upset some other companies. That's crazy.
- lclarkmichalek 12y ago
  Well, they did throw quite an embarrassing tantrum when CoreOS decided to compete with them. I don't think that Docker shouldn't compete, but it would be nice to see a little more separation between the various components.

by themgt 12y ago

numair 12y ago

Docker's overreach seems to resemble the overreach of Joyent in the io.js world. It's really hard to regain trust and momentum once the community starts to question you; in economic terms this would be termed as "a spike in transaction costs." If I were Docker, my next project would be a meetup/presentation/etc explaining how my new initiatives are for the benefit of the community, rather than just self-serving wheel reinvention. This isn't a consumer-facing business; the opinions of concerned developers can make or break them.

Alupis 12y ago
> my next project would be a meetup/presentation/etc explaining how my new initiatives... You mean like the conferences they held before they even had a viable product? Docker has stampeded onto the scene with zero competition, and the Parent comment is totally right -- we should take a good minute and consider that we are head-first rushing to implement everywhere a product made and perpetuated by a for-profit company who's end goal is literally to be on every server and be the de facto implementation so that once they start to monetize the product, you will have little choice but to funnel support funds into their company. That's petrifying to me, because it means if realized, my company will be at the whims of Docker, not the other way around. Furthermore, the backlash from the Docker creator himself the other day on the announcement by CoreOS, it really seems Docker never anticipated ever having any competition in this space, and have taken active steps to ensure they are their own custom thing that is not compatible with other existing or future container implementations. Perhaps this will change now, and they will work with CoreOS to clearly define a universal specification for a container which can be portable between any implementation, but signs show they don't feel it's in their company's best interest to do so (and honestly it isn't in their best interest, but it's in the community's best interest for sure).
- ldlework 12y ago
  > You mean like the conferences they held before they even had a viable product? The conference was awesome and there was plenty to announce at that point. It certainly helped drive home the conceptualization of containerization for many. > we should take a good minute and consider You're right we should consider - except what you're doing is making charges like; "we are head-first rushing", "perpetuated by a for-profit company", "my company will be at the whims of Docker" And other fear in this thread without providing your audience with the context of: - for profit companies backing an innumerable number of major technologies in a variety of fields since technology was a thing - most of the development of Docker happens outside of Docker Inc - the project has an independent governance board - the project has been nothing but the epitome of successful transparent open source If Docker ends up achieving a cohesive ecosystem of holistically designed pieces solving one of the most difficult unsolved problems (a class of problems, really) in modern computing benefiting so many then is it really a problem paying Docker Inc for first class support to all of that? I imagine there are already companies selling support for Docker other than Docker Inc It seems like you're the one imagining there is going to be no competition, honestly.

hosay123 12y ago

> it looks a lot more like they took a Microsoft embrace-extend-extinguish approach to LXC That's overstating things slightly, since it appears no Docker employee has ever contributed a single line of code to the LXC implementation itself (that would be hard work, rather than bikeshedding userspace tools, after all). The kernel tree contains only one reference to a Docker bug, fixed by a Red Hat employee, while the LXC tree contains a single reference to a Docker bug, fixed by a Canonical employee who looks to be one of the LXC maintainers. The reality is replacing Docker isn't all that hard, as we're now seeing with Rocket. The kernel interfaces aren't tied to it (hell, its clear from Git logs the LXC devs are barely even aware of it). edit: It's simpler to look at Docker and Rocket for what they both are: commercial plays built on the work of others. That work hasn't magically disappeared somewhere, it still exists and is in use (albeit by a slightly less PR/buzz-aware side of the community). A vendor-independent implementation of containers already exists, as it did long before Docker did. If people are serious about seeing the "container ecosystem" flourish, they should be contributing cash, employment offers, or employee time to the real people and projects doing the work (as opposed to publishing upset blog posts and writing fashionable Go code)

VieElm 12y ago
I'm pretty sure the CoreOS CTO, Brandon Phillips, has personally made many significant contributions to open source, just check his GitHub[1], and is a Linux kernel developer. He's been an open source contributor for a very long time. [1] https://github.com/philips?tab=repositories https://github.com/philips?tab=repositories
- hueving 12y ago
  He meant docker doesn't contribute in that context.
tlrobinson 12y ago
Just curious, are you doing anything to support the container ecosystem, aside from publishing upset Hacker News comments? I think the strong interest in Docker demonstrates there's a need for a layer on top of LXC. It's open source, so what's the problem?

shingler 12y ago

I don't think there's any danger as long as everything is open and interchangeable, and you can steer clear of Docker (the company) even if you like Docker (the format). So far that's basically the case with all of the Docker projects. Ideally in the future, Docker will become an HTTP for servers, with standardized and competing servers/clients/services. I like the idea of that future. Publically, the Docker folks seem open to it. However, I do see where you're coming from. As a for profit Docker has every incentive (perhaps even fiduciary duty) to pull the good ol' technology bait-and-switch: get Docker on every server, and the create a Kafkaesque technology dilemma to squeeze the dollars out of everyone who bought in. Microsoft's playbook has plenty of tips on how to do this. I guess the only solution as a Docker user is to be hypersensitive to any sign that Docker wants to start locking the technology to the company. When you can imagine the day you can't use Docker (the containers) without Docker (the company), it's time to run the other way fast. But I can't see that day yet, and I hope I never do. And I hope Docker as a company can find a way to grow without using that oldest, sleaziest trick in the book.

deleted 12y ago
[deleted]
Alupis 12y ago
We should probably note this 'shingler' account was created exactly at the same time this post was submitted to HN, and this is the account's first comment... in support of this article. I'll leave you to decide what that means...
- shykes 12y ago
  Probably has something to do with this: https://twitter.com/solomonstre/status/540559322070392834 https://twitter.com/solomonstre/status/540559322070392834
  - Alupis 12y ago
    Your post had exactly 5 re-tweets when you posted your comment just now (not exactly an onslaught of new listeners rushing to HN for the first time). Regardless -- Your twitter post came almost 30 minutes after the account above was created and 30 minutes after this article was submitted to HN.

jpetazzo 12y ago

The comparison with systemd is unfair. Docker wants to be "batteries included, but swappable/removable". If you don't like host management, orchestration, build, etc., you can disable that specific component and put another one; and none of those components are strictly necessary. Contrast with systemd, where it's impossible to use anything else, and the attitude of the maintainers is "our way or the highway" when people beg them to continue to support alternatives. Compare Docker to frameworks like Django or Rails, which come with everything you need (templating, ORM, url mapping, etc.) but where each thing is replaceable if you don't like it; versus Rocket which would be like Flask or Sinatra, which are smaller and require to be combined with other things to be useful. Nothing wrong with either approach; but if the comparison is right, we can expect Docker to provide "reasonable defaults", and some people building some specific apps to use Rocket because they just want to run things and they don't need build/orchestration/API/etc (or they need special versions of those components).

shykes 12y ago
Jerome don't forget that Django is monolithic. Docker is modular (ie swarm and machine are entirely separate binaries).
- nostrademons 12y ago
  You can use Django as swappable libraries. I worked on some projects at Google that used Django for the request routing, templates, and helpers, but completely swapped out the ORM for Google's own RPC system. Jinja2 is basically the Django templating language pulled out into its own library; before it existed, people would just use django.template. Some folks just use the ORM and request routing and then stick a JSON serializer on top to send data to an Angular SPA.
23david 12y ago
Systemd is a fair comparison. Systemd is a modular system, and it's also possible to not install different components if you want. Most of the components aren't strictly necessary. I think your community is begging you to continue to support alternatives. You just aren't listening.

jacques_chester 12y ago

> And thus the need for Rocket. Actually, I'm going to say: thus the need for Cloud Foundry. I work for Pivotal Labs and I'm secondment to the CF Buildpacks team, so I'm biased. And this shouldn't be construed as official opinion, it's just mine. Cloud Foundry is led by Pivotal, but we run it openly. Anyone can follow our repos[1][2] and our Tracker projects. The entire platform is being signed over into an independent Foundation with more than 30 paid members[3] (including Docker Inc). The whole project is being written the Pivotal Labs way. Everything is TDD, everything is pair programmed. If I had to bet a company on a platform, I'd bet it on us. We're building the first and only truly independent, truly open source, truly open core, truly multi-company PaaS that is available. You can buy support and hosting from us, IBM, HP and a series of mid-tier providers right now. You can do it in the public cloud or in a disconnected datacentre. Oh, and we're going to have baked-in Docker support with our next-gen executor (Diego), in addition to Warden system we developed before Docker was released. [1] https://github.com/cloudfoundry/ https://github.com/cloudfoundry/ [2] https://github.com/cloudfoundry-incubator/ https://github.com/cloudfoundry-incubator/ [3] http://cloudfoundry.org/about/index.html#the-cloud-foundry-foundation http://cloudfoundry.org/about/index.html#the-cloud-foundry-f...

biot 12y ago

> if Docker could have just stuck to running containers Do you argue the same for Amazon with AWS? They should have just stuck to running VMs on EC2 backed by S3? Amazon should not have added databases, scaling, load balancing, caching, DNS, email, search, analytics, etc. and left that up to the community to provide? Do you argue that Amazon has taken an embrace-extend-extinguish approach to AWS?

23david 12y ago
AWS started as an open-source community project boasting contributions from over 650 contributors? Recent post by Docker CEO Golub: There are over 650 contributors (95% of whom do not work for Docker, Inc.). http://blog.docker.com/2014/11/docker-governance-advisory-board-output-of-first-meeting/ http://blog.docker.com/2014/11/docker-governance-advisory-bo...
- biot 12y ago
  That's a non-sequitur. Are you trying to suggest a relationship between an open-source project with many contributors and a requirement to avoid building a complete platform? If so, could you provide an argument behind your statement?
- njs12345 12y ago
  If you looked at volume of commits it might tell a different story - I'd imagine commits by contributor would follow a power law, so you might well have a project where 5% of the contributors made more than 50% of the commits, for example.
  - shykes 12y ago
    Take a look at the article, there is detailed comparative data on volume, response time, merge rate, split by Docker inc employees and non-employees.
jon_dahl 12y ago
A lot of people have this fear. Amazon is a quickly expanding platform with a growing level of lock-in and immense power. This isn't good for the ecosystem - a dominant company can charge a premium, and choice is good. Full disclosure: I say this as a founder of a higher-level cloud service (Zencoder) that Amazon decided to compete with head-on. We're doing just fine, thanks (growing quickly, differentiated product), but Amazon is aggressively expanding upstream and is going to continue to do so.

kordless 12y ago

> tie the future of computing to a single for-profit company's quickly enlarging platform The 'future' of compute is ubiquitous trustworthy compute for all. A federation where no one entity controls a pool of power over a given layer of the stack. The layers that run on top of that layer will continue to divide and stratify themselves, as it always has been. They will also assuredly be owned by someone or something. My vote is the something.

girvo 12y ago

> I really am beginning to see the CoreOS guys point here - if Docker could have just stuck to running containers and doing that awesome, there would have been space for other companies to build out the ecosystem around that shared interoperable container format. It blows my mind that on Hacker News of all places, people are suggesting that the Docker folk should not compete because it might upset some other companies. That's crazy.

lclarkmichalek 12y ago
Well, they did throw quite an embarrassing tantrum when CoreOS decided to compete with them. I don't think that Docker shouldn't compete, but it would be nice to see a little more separation between the various components.