3 ms·

I agree that running kubernetes ourselves does actually serve our own interests. But I still think it's much more of a slippery slope than alternative solutions

I agree that running kubernetes ourselves does actually serve our own interests. But I still think it's much more of a slippery slope than alternative solutions (being that some of them are not developed with the intention to eventually get you to use the hosted version)

kross 8y ago
What are the alternatives of which you speak? Which part of kubernetes is "developed with the intention to eventually get you to use the hosted version"? Offering software for free, software that is widely adopted cannot be based on the motivations you propose, unless there is a grand conspiracy of cloud providers for which I am unaware.
- firebacon 8y ago
  > Which part of kubernetes is "developed with the intention to eventually get you to use the hosted version"? I believe it's all of it. Why else would they spend money on building and promoting it?
  - kross 8y ago
    So it is evil unless I can prove otherwise? Your straw man has been exposed. https://en.m.wikipedia.org/wiki/Straw_man https://en.m.wikipedia.org/wiki/Straw_man
    - firebacon 8y ago
      You don't have to prove anything. Nobody is on trial here, I hope :)
  - cheriot 8y ago
    I see a semblance to their original motivations in building chrome. By making the web as a whole more competitive, it made google's offerings more competitive (more ad surfaces, more gmail users, less OS lockin). Actually winning the browser war isn't necessary. For a huge number or organizations, the cloud isn't a meaningful option because the switching costs are astronomical. Kubernetes, otoh, means someone that chooses on prem today actually has a migration path later. Google benefits hugely from that path just existing.
- tobbyb 8y ago
  LXC on which Docker was based always had a much more sensible container model and contrary to the pervasive misinformation by the devops ecosystem is far easier to use. It supports a standard OS environment and does not enforce the use of layers so users don't have to deal with single process non standard OS environment which removes half the complexity. We are working on a project, Flockport, that supports LXC and provides an app store, orchestration, networking, distributed storage, service discovery and HA. So there are attempts to explore simpler alternatives.
humbleMouse 8y ago
I have the same question as the other commentor - what are the alternitives? Docker compose? Apache Mesos? Can you please explain what you think a better solution is? I am honestly curious to know.

kross 8y ago

What are the alternatives of which you speak? Which part of kubernetes is "developed with the intention to eventually get you to use the hosted version"? Offering software for free, software that is widely adopted cannot be based on the motivations you propose, unless there is a grand conspiracy of cloud providers for which I am unaware.

firebacon 8y ago
> Which part of kubernetes is "developed with the intention to eventually get you to use the hosted version"? I believe it's all of it. Why else would they spend money on building and promoting it?
- kross 8y ago
  So it is evil unless I can prove otherwise? Your straw man has been exposed. https://en.m.wikipedia.org/wiki/Straw_man https://en.m.wikipedia.org/wiki/Straw_man
  - firebacon 8y ago
    You don't have to prove anything. Nobody is on trial here, I hope :)
- cheriot 8y ago
  I see a semblance to their original motivations in building chrome. By making the web as a whole more competitive, it made google's offerings more competitive (more ad surfaces, more gmail users, less OS lockin). Actually winning the browser war isn't necessary. For a huge number or organizations, the cloud isn't a meaningful option because the switching costs are astronomical. Kubernetes, otoh, means someone that chooses on prem today actually has a migration path later. Google benefits hugely from that path just existing.
tobbyb 8y ago
LXC on which Docker was based always had a much more sensible container model and contrary to the pervasive misinformation by the devops ecosystem is far easier to use. It supports a standard OS environment and does not enforce the use of layers so users don't have to deal with single process non standard OS environment which removes half the complexity. We are working on a project, Flockport, that supports LXC and provides an app store, orchestration, networking, distributed storage, service discovery and HA. So there are attempts to explore simpler alternatives.

humbleMouse 8y ago

I have the same question as the other commentor - what are the alternitives? Docker compose? Apache Mesos? Can you please explain what you think a better solution is? I am honestly curious to know.