4 ms·

If I only have GKE clusters, what does Rancher mainly offer on top of that?

by amq 8y ago

platz 8y ago
i.e. do i need an abstraction layer over my orchestrator? Somewhat reminiscent of the early 2000's fad to abstract over databases when in reality folks never 'swap out the db' on real projects.
- adictator 8y ago
  You may still have the same DB product, but you do swap out the db for dev, testing etc. Matter of fact, we swap out the db to locally hosted mysql or postgres for development & use Oracle only in prod. The overhead I think is that our sql's are fairly standard & do not use any proprietary features of any single db.
- shengliang 8y ago
  At Rancher we don't really want to introduce another level of abstraction on top of Kubernetes. You are right there's no value in doing that. Kubernetes is already the orchestration standard that most people are willing to use and most infrastructure vendors are willing to support. Rancher just tries to make it easier to manage lots of Kubernetes clusters.
- gm-conspiracy 8y ago
  "fad to abstract over databases" cough Is it not called an ORM?
  - icebraining 8y ago
    Some can be used for that, but it's not their main purpose. Not all ORMs are database-independent (the one we use uses postgres-specific features), and conversely, if you just need independence you're probably better off using something lighter.
V99 8y ago
(Rancher employee) A few of the top of my head... - UI for managing all the major resources (that isn't read-only or "insert large properly-formatted yaml file here") - Access control integration to other systems like AD - Grouping multiple namespaces into "Projects" and doing RBAC and Secret definition/assignment at that level instead of duplicating yourself for every namespace - You only have GKE clusters today but if tomorrow you want something on Amazon or your company acquires a team with existing stuff in Azure you can still have one place to manage it

If I only have GKE clusters, what does Rancher mainly offer on top of that?

by amq 8y ago

If I only have GKE clusters, what does Rancher mainly offer on top of that?

i.e. do i need an abstraction layer over my orchestrator? Somewhat reminiscent of the early 2000's fad to abstract over databases when in reality folks never 'swap out the db' on real projects.

adictator 8y ago
You may still have the same DB product, but you do swap out the db for dev, testing etc. Matter of fact, we swap out the db to locally hosted mysql or postgres for development & use Oracle only in prod. The overhead I think is that our sql's are fairly standard & do not use any proprietary features of any single db.
shengliang 8y ago
At Rancher we don't really want to introduce another level of abstraction on top of Kubernetes. You are right there's no value in doing that. Kubernetes is already the orchestration standard that most people are willing to use and most infrastructure vendors are willing to support. Rancher just tries to make it easier to manage lots of Kubernetes clusters.
gm-conspiracy 8y ago
"fad to abstract over databases" cough Is it not called an ORM?
- icebraining 8y ago
  Some can be used for that, but it's not their main purpose. Not all ORMs are database-independent (the one we use uses postgres-specific features), and conversely, if you just need independence you're probably better off using something lighter.

V99 8y ago

(Rancher employee) A few of the top of my head... - UI for managing all the major resources (that isn't read-only or "insert large properly-formatted yaml file here") - Access control integration to other systems like AD - Grouping multiple namespaces into "Projects" and doing RBAC and Secret definition/assignment at that level instead of duplicating yourself for every namespace - You only have GKE clusters today but if tomorrow you want something on Amazon or your company acquires a team with existing stuff in Azure you can still have one place to manage it