4 ms·

In the following paragraph, the author considers and appears to reject that solution: >Maybe the combination of operators and Helm charts covers this, but I do

In the following paragraph, the author considers and appears to reject that solution: >Maybe the combination of operators and Helm charts covers this, but I don’t think that will cut it. Then we’re forcing developers to learn about two other things in addition to Kubernetes. Even if it’s just increasing the vocabulary and installing a new command line tool, it’s extra effort and thought. These things need to be first-class citizens and part of the Kubernetes out-of-the-box experience. They need to be accessible via kubectl.

justinjlynn 8y ago
So, instead of keeping cross-cutting concerns separate and permitting them to evolve separately, the author wants K8S to become more complex, because they'd rather learn one more complex thing than multiple simpler things? Seems legit. I mean, why should I install multiple libraries? Why can't glibc wash my car? Will glibc collapse under the weight of it's own complexity -- even though it can't wash my car like I want it to?
- dominotw 8y ago
  I think more charitable interpretation is that kuberbetes should be designed in such a way that these tools are a natural part of it. Think of active record being part of rails. Sure you can use rails without ar but that doesn't make sense.
  - justinjlynn 8y ago
    Using Ruby on Rails without ActiveRecord does make sense for a number of applications. For example, an edge caching API which uses Redis on the backend. Helm is a package manager for K8S but it isn't the package manager for K8S, which is probably why it's kept separate. ActiveRecord was the ORM for Rails, before it was extracted and called "ActiveRecord" as a separate thing. Helm, however, is coming from the opposite direction -- and until it becomes something you can't use K8S without, then I'm happy to see them kept separate.

4 ms·

In the following paragraph, the author considers and appears to reject that solution: >Maybe the combination of operators and Helm charts covers this, but I do

by hyperrail 8y ago

justinjlynn 8y ago
So, instead of keeping cross-cutting concerns separate and permitting them to evolve separately, the author wants K8S to become more complex, because they'd rather learn one more complex thing than multiple simpler things? Seems legit. I mean, why should I install multiple libraries? Why can't glibc wash my car? Will glibc collapse under the weight of it's own complexity -- even though it can't wash my car like I want it to?
- dominotw 8y ago
  I think more charitable interpretation is that kuberbetes should be designed in such a way that these tools are a natural part of it. Think of active record being part of rails. Sure you can use rails without ar but that doesn't make sense.
  - justinjlynn 8y ago
    Using Ruby on Rails without ActiveRecord does make sense for a number of applications. For example, an edge caching API which uses Redis on the backend. Helm is a package manager for K8S but it isn't the package manager for K8S, which is probably why it's kept separate. ActiveRecord was the ORM for Rails, before it was extracted and called "ActiveRecord" as a separate thing. Helm, however, is coming from the opposite direction -- and until it becomes something you can't use K8S without, then I'm happy to see them kept separate.