5 ms·

For those companies i recommend rancher... It's kubernetes under the hood but a lot is stuff is abstracted away..

cryptica 7y ago
I'm also a fan of Rancher. Especially the newer versions. It significantly simplifies the process of spawning up and managing a Kubernetes cluster. I do think that Kubernetes is overkill if you just want to spawn a couple of server instances. But if you want to build a complex system which scales and you happen to have experienced developers on the team who understand how to build scalable systems and who have experience with Kubernetes then you'd be foolish not to use K8s IMO. That said, having that specific talent and experience on the team is critical or else you're just wasting your time and money with K8s - And that talent is very hard to find. There is no point building some complex architecture for Kubernetes if that architecture is not designed to scale linearly from the ground up. Kubernetes can allow you to operate highly scalable systems easily and elegantly, but simply using Kubernetes doesn't itself guarantee in any way that your systems will be scalable and will benefit from K8s at all (aside from pretty UI). Very few people can build systems that scale and also meet business requirements.
je42 7y ago
I worked at company with k8s+rancher, and was constantly bumping into rancher specific issues. I am not sure if rancher is really worth the effort.
colecut 7y ago
So docker runs a bunch of system services but abstracts them away... And kubernetes runs docker but abstracts that away... and rancher runs kubernetes but abstracts that away.. Should I just wait a year for something that lets me use rancher without knowing anything about it?
- rumanator 7y ago
  The problem of infrastructure is that low level interfaces are always consumed by higher-level interfaces. And if you want to run a process, but you want to distribute the apps and run them as process containers, and you want to run them in an automatically configurable cluster of COTS computers communicating through a virtual private network... Don't you understand where and why are there abstractions? If anything, having people naively complain about how things are layered and abstracted is a testament of the huge success of the whole teck stack, because complainers formed such a simple mental model of how to distribute, configure, run, and operate collections of heterogeneous services communicating through a virtual network that they simply have no idea of the challenge of implementing a workable system that does half of this. But with docker+kubernetes it only takes a click, so it must be trivial right?
  - colecut 7y ago
    I haven't used kubernetes, but it must be a very difficult click if another tool (Rancher) exists to make it easier. I understand why abstractions exist, but the amount abstractions in the chain I mentioned is amusing to me.
    - root_axis 7y ago
      Why is it amusing? Do you find the amount of abstraction between the CPU and a browser similarly amusing? That judgement seems arbitrary. The reason why an abstraction is created is because it's sometimes helpful to have complexity managed automatically if full control of the complexity is not necessary for your needs, your reaction seems to suggest "kubernetes doesn't need to be so complex", but I am not sure if you really believe that. I can understand the "kubernetes may not be the best engineering decision for your needs" argument, but that's a different argument from kubernetes is too complex.
      - colecut 7y ago
        I suppose amusement is arbitrary. This comment chain started with: "Having been at a company that was starting to move things to Kubernetes, when it had absolutely no reason to, I can say that it was being done because: 1) the developers wanted to be able to say they knew how to use Kubernetes... " Someone responded by saying "For those companies i recommend rancher... It's kubernetes under the hood but a lot is stuff is abstracted away.." So if you dont need Kubernetes, and are just using it to learn Kubernetes, you should throw an additional tool on top of Kubernetes, that abstracts away Kubernetes? I'm sorry, that is amusing to me. Some abstractions are necessary. Some aren't.
        root_axis 7y ago
        I said the judgement is arbitrary, not the amusement. > Some abstractions are necessary. Some aren't. It just seems bizarre to me that you can suggest that the abstraction is unnecessary when you also claim to have never used the tool. What makes you think it's unnecessary?

I'm also a fan of Rancher. Especially the newer versions. It significantly simplifies the process of spawning up and managing a Kubernetes cluster. I do think that Kubernetes is overkill if you just want to spawn a couple of server instances. But if you want to build a complex system which scales and you happen to have experienced developers on the team who understand how to build scalable systems and who have experience with Kubernetes then you'd be foolish not to use K8s IMO. That said, having that specific talent and experience on the team is critical or else you're just wasting your time and money with K8s - And that talent is very hard to find. There is no point building some complex architecture for Kubernetes if that architecture is not designed to scale linearly from the ground up. Kubernetes can allow you to operate highly scalable systems easily and elegantly, but simply using Kubernetes doesn't itself guarantee in any way that your systems will be scalable and will benefit from K8s at all (aside from pretty UI). Very few people can build systems that scale and also meet business requirements.

je42 7y ago

I worked at company with k8s+rancher, and was constantly bumping into rancher specific issues. I am not sure if rancher is really worth the effort.

colecut 7y ago

So docker runs a bunch of system services but abstracts them away... And kubernetes runs docker but abstracts that away... and rancher runs kubernetes but abstracts that away.. Should I just wait a year for something that lets me use rancher without knowing anything about it?

rumanator 7y ago
The problem of infrastructure is that low level interfaces are always consumed by higher-level interfaces. And if you want to run a process, but you want to distribute the apps and run them as process containers, and you want to run them in an automatically configurable cluster of COTS computers communicating through a virtual private network... Don't you understand where and why are there abstractions? If anything, having people naively complain about how things are layered and abstracted is a testament of the huge success of the whole teck stack, because complainers formed such a simple mental model of how to distribute, configure, run, and operate collections of heterogeneous services communicating through a virtual network that they simply have no idea of the challenge of implementing a workable system that does half of this. But with docker+kubernetes it only takes a click, so it must be trivial right?
- colecut 7y ago
  I haven't used kubernetes, but it must be a very difficult click if another tool (Rancher) exists to make it easier. I understand why abstractions exist, but the amount abstractions in the chain I mentioned is amusing to me.
  - root_axis 7y ago
    Why is it amusing? Do you find the amount of abstraction between the CPU and a browser similarly amusing? That judgement seems arbitrary. The reason why an abstraction is created is because it's sometimes helpful to have complexity managed automatically if full control of the complexity is not necessary for your needs, your reaction seems to suggest "kubernetes doesn't need to be so complex", but I am not sure if you really believe that. I can understand the "kubernetes may not be the best engineering decision for your needs" argument, but that's a different argument from kubernetes is too complex.
    - colecut 7y ago
      I suppose amusement is arbitrary. This comment chain started with: "Having been at a company that was starting to move things to Kubernetes, when it had absolutely no reason to, I can say that it was being done because: 1) the developers wanted to be able to say they knew how to use Kubernetes... " Someone responded by saying "For those companies i recommend rancher... It's kubernetes under the hood but a lot is stuff is abstracted away.." So if you dont need Kubernetes, and are just using it to learn Kubernetes, you should throw an additional tool on top of Kubernetes, that abstracts away Kubernetes? I'm sorry, that is amusing to me. Some abstractions are necessary. Some aren't.
      - root_axis 7y ago
        I said the judgement is arbitrary, not the amusement. > Some abstractions are necessary. Some aren't. It just seems bizarre to me that you can suggest that the abstraction is unnecessary when you also claim to have never used the tool. What makes you think it's unnecessary?