6 ms·

And it begins. The birth of a company with a direct conflict of interest in making Kubernetes so simple to use/administer that you don't need to pay another com

by hueving 10y ago

And it begins. The birth of a company with a direct conflict of interest in making Kubernetes so simple to use/administer that you don't need to pay another company for 'enterprise support'. This happens quite frequently with open source infrastructure. Keep an eye on them to push back against improvements that directly conflict with their company's "enterprise sauce".

ktamiola 10y ago
That indeed might be an issue in a long run. In reverse order we can see this story paralleled by MongoDB.
101km 10y ago
The overall stewards and interests behind Kubernetes have a greater interest in making it simple to use and administer. It isn't quite there yet but things are improving on that front all the time and will be significantly better for newbies in a few more versions. In other words, it is getting there, don't worry about it.
- hueving 10y ago
  True, but I've seen enough of it now that open source politics should almost be a field to major in. :) It's never blatant, it's always calls for seemingly good things like extra pluggable points to make sure we don't favor particular solutions. Then it's making sure that any decision is brought to a huge vote by a giant committee that spends weeks arguing about if it's something they should even decide on, etc. Ultimately there are ways to do immense damage to open source communities with small well placed "concerns" that seed doubt. Usually it's a mailing list post (or github issue) with some grand question like "Is X something Kubernetes should really be doing?" followed by bullet points outlining other unrelated issues that "we should be focusing on" and to "leave X up to other tools because the solutions are a matter of taste and therefore there is no right solution."
paukiatwee 10y ago
I think this is different from other company in the sense that they dont own Kubernetes. It is unlike, for example, Influxdata that they own InfluxDB and dont integrate clustering capability into open source edition.
Perceptes 10y ago
Note that this is just some people who helped start the project when they were at Google, and both of them have since left. Kubernetes is managed by the Cloud Native Computing Foundation, and a very large number of companies are involved in managing the project's direction with an open governance model. There are diverse enough interests already that there isn't really any risk of one company's interests driving the project off course in a way that's harmful for the larger Kubernetes community.
- gtirloni 10y ago
  Like OpenStack?
  - josh2600 10y ago
    God, I don't think I've ever groaned audibly while reading a comment like this before on HN. It's totally correct and true and apt, but I hope it's wrong over the long term. I'm hopeful k8 won't go the way of openstack because the problem domain is simpler and more well defined, but I'll be damned if I ever believe a "diverse" group of enterprises with shared interests can reliably produce good software. Fool me once, shame on me. Fool me twice, shame on the standards committee.
    - brazzledazzle 10y ago
      I feel like openstack will end up being the subject of an interesting book that will explore all the ways it ended up screwing itself despite (or perhaps because of) corporate sponsorhip.
  - stonith 10y ago
    K8s has a significantly more solid base today than OpenStack did upon its public release by NASA. It was barely functional, and gained the ascendency by virtue of Eucalyptus somehow managing to be even worse.
  - praveenster 10y ago
    OpenStack has begun to feel more of a vendor marketplace with each of them trying to see if you can adopt their flavor. It looks somewhat similar to the large number of the Linux distros that were popular about 10 years ago, except that these are much more opinionated and have serious vendor lock-in possibilities since it relates to enterprise. Kubernetes, on the other hand feels like a harmonious and homogeneous solution to a specific problem.
treffer 10y ago
1. There is already a company doing that, among other things: CoreOS 2. There is usually not a "natural" conflict for companies that started out of open source projects 3. A full kubernetes deploy is already hard I'm actually quite happy that we will now see Heptio and CoreOS pushing for boxed kubernetes deploys. Multiple entities pushing an open source core is usually a good thing.
- hueving 10y ago
  >Multiple entities pushing an open source core is usually a good thing No, it's not that cut and dry. Depending on their product, they end up pushing the core to be more pluggable and extensible to make it work better with their product and have places to add secret sauce. Any company that sells support benefits from more complexity because they compete by gaining expertise. Any company that makes a product for it benefits from fewer features in the open source version.
jondubois 10y ago
Kubernetes will help reduce the number of engineers needed to maintain large systems. This is the beginning of the end for the DevOps engineering career - There will still be DevOps jobs left but they won't pay as much.
- FatalBaboon 10y ago
  Maybe for companies that employ many devopses, but most of my clients already have only one or two. That is, me with eventually a junior that I'm getting up to speed so he can take my place. Furthermore, the "run" part is only a fraction of the job, the whole pilgrimage from developers' code to a production-ready container is most of the work, and that's very client-specific. For example, I will always have a high-paying job at making workflows that help ensuring average developers cannot send bad code in production, that they are reviewed etc. Kubernetes is great because the "run" part was really the low-hanging fruit. A container is a container, and setting up routing, provisioning etc is very generic and boring.
jbeda 10y ago
I'm the CTO and I actually agree with you. We need to continue to make it easier to use. We want to set up Heptio so that motivations are aligned. When integrating something like Kubernetes with existing systems and processes there will always be opportunity for additional systems and support that aren't easily built in the open. Often times these aren't fun things and so are harder to get critical mass in the open. The first part of our plan is to help fill usability gaps for Kubernetes in the open. This will grow the pie and expand our standing in the community. Commercially we will filling gaps unique to large companies around integration with existing systems and managing ops and dev relationships. Specifics here will have to wait until product is ready. In general we have a value around "Honest Technology". We want to build products that just work and do what it says on the tin.
pm90 10y ago
Not necessarily. Kafka started at LinkedIn and the founders left to found confluent. They've been pretty good about keeping stuff open source.
pjmlp 10y ago
The reason it happens so frequently, it that developers eventually realise that consulting is the only way to get sustainable source of income for FOSS and big corporations are usually the only ones willing to pay for it.

by hueving 10y ago

ktamiola 10y ago

That indeed might be an issue in a long run. In reverse order we can see this story paralleled by MongoDB.

101km 10y ago

The overall stewards and interests behind Kubernetes have a greater interest in making it simple to use and administer. It isn't quite there yet but things are improving on that front all the time and will be significantly better for newbies in a few more versions. In other words, it is getting there, don't worry about it.

hueving 10y ago
True, but I've seen enough of it now that open source politics should almost be a field to major in. :) It's never blatant, it's always calls for seemingly good things like extra pluggable points to make sure we don't favor particular solutions. Then it's making sure that any decision is brought to a huge vote by a giant committee that spends weeks arguing about if it's something they should even decide on, etc. Ultimately there are ways to do immense damage to open source communities with small well placed "concerns" that seed doubt. Usually it's a mailing list post (or github issue) with some grand question like "Is X something Kubernetes should really be doing?" followed by bullet points outlining other unrelated issues that "we should be focusing on" and to "leave X up to other tools because the solutions are a matter of taste and therefore there is no right solution."

paukiatwee 10y ago

I think this is different from other company in the sense that they dont own Kubernetes. It is unlike, for example, Influxdata that they own InfluxDB and dont integrate clustering capability into open source edition.

Perceptes 10y ago

Note that this is just some people who helped start the project when they were at Google, and both of them have since left. Kubernetes is managed by the Cloud Native Computing Foundation, and a very large number of companies are involved in managing the project's direction with an open governance model. There are diverse enough interests already that there isn't really any risk of one company's interests driving the project off course in a way that's harmful for the larger Kubernetes community.

gtirloni 10y ago
Like OpenStack?
- josh2600 10y ago
  God, I don't think I've ever groaned audibly while reading a comment like this before on HN. It's totally correct and true and apt, but I hope it's wrong over the long term. I'm hopeful k8 won't go the way of openstack because the problem domain is simpler and more well defined, but I'll be damned if I ever believe a "diverse" group of enterprises with shared interests can reliably produce good software. Fool me once, shame on me. Fool me twice, shame on the standards committee.
  - brazzledazzle 10y ago
    I feel like openstack will end up being the subject of an interesting book that will explore all the ways it ended up screwing itself despite (or perhaps because of) corporate sponsorhip.
- stonith 10y ago
  K8s has a significantly more solid base today than OpenStack did upon its public release by NASA. It was barely functional, and gained the ascendency by virtue of Eucalyptus somehow managing to be even worse.
- praveenster 10y ago
  OpenStack has begun to feel more of a vendor marketplace with each of them trying to see if you can adopt their flavor. It looks somewhat similar to the large number of the Linux distros that were popular about 10 years ago, except that these are much more opinionated and have serious vendor lock-in possibilities since it relates to enterprise. Kubernetes, on the other hand feels like a harmonious and homogeneous solution to a specific problem.

treffer 10y ago

1. There is already a company doing that, among other things: CoreOS 2. There is usually not a "natural" conflict for companies that started out of open source projects 3. A full kubernetes deploy is already hard I'm actually quite happy that we will now see Heptio and CoreOS pushing for boxed kubernetes deploys. Multiple entities pushing an open source core is usually a good thing.

hueving 10y ago
>Multiple entities pushing an open source core is usually a good thing No, it's not that cut and dry. Depending on their product, they end up pushing the core to be more pluggable and extensible to make it work better with their product and have places to add secret sauce. Any company that sells support benefits from more complexity because they compete by gaining expertise. Any company that makes a product for it benefits from fewer features in the open source version.

jondubois 10y ago

Kubernetes will help reduce the number of engineers needed to maintain large systems. This is the beginning of the end for the DevOps engineering career - There will still be DevOps jobs left but they won't pay as much.

FatalBaboon 10y ago
Maybe for companies that employ many devopses, but most of my clients already have only one or two. That is, me with eventually a junior that I'm getting up to speed so he can take my place. Furthermore, the "run" part is only a fraction of the job, the whole pilgrimage from developers' code to a production-ready container is most of the work, and that's very client-specific. For example, I will always have a high-paying job at making workflows that help ensuring average developers cannot send bad code in production, that they are reviewed etc. Kubernetes is great because the "run" part was really the low-hanging fruit. A container is a container, and setting up routing, provisioning etc is very generic and boring.

jbeda 10y ago

I'm the CTO and I actually agree with you. We need to continue to make it easier to use. We want to set up Heptio so that motivations are aligned. When integrating something like Kubernetes with existing systems and processes there will always be opportunity for additional systems and support that aren't easily built in the open. Often times these aren't fun things and so are harder to get critical mass in the open. The first part of our plan is to help fill usability gaps for Kubernetes in the open. This will grow the pie and expand our standing in the community. Commercially we will filling gaps unique to large companies around integration with existing systems and managing ops and dev relationships. Specifics here will have to wait until product is ready. In general we have a value around "Honest Technology". We want to build products that just work and do what it says on the tin.

pm90 10y ago

Not necessarily. Kafka started at LinkedIn and the founders left to found confluent. They've been pretty good about keeping stuff open source.

pjmlp 10y ago

The reason it happens so frequently, it that developers eventually realise that consulting is the only way to get sustainable source of income for FOSS and big corporations are usually the only ones willing to pay for it.