3 ms·

Without service discovery, you end up generating configuration all over the place just to wire together your services, letting everybody know about which IP add

Without service discovery, you end up generating configuration all over the place just to wire together your services, letting everybody know about which IP address and port where - super tedious. Add in multi-tenancy, and you're in a bunch of pain. Now try and take that setup and deploy it on-prem for customers that can't use cloud services - you rapidly want something to abstract away the cluster and its wiring at the address allocation level.

firebacon 8y ago
I'm not sure I understand this. You have a product that is split into many different components, and when you deploy this product to a customer site, each component runs on different hosts, so you have a bunch of wiring up of service addresses to do for every deployment? Could something like mDNS be a lightweight solution to that problem? And also I am genuinely curious how kubernetes would solve that. When you install kubernetes on all of these machines, don't you have to manually do the configuration for that either? So isn't it just choosing to rather configure kubernetes instead of your own application for each deployment? If it is that much simpler to setup a kubernetes cluster than your app, maybe the solution is to put some effort into the configuration management part of your product?
- kross 8y ago
  I'm not sure you understand the value k8s proposes based on your comments throughout this entire thread. Managing many nodes is the reason orchestration software exists. Your suggestion to "put some effort into configuration management" is effectively naive, homegrown orchestration. Build or buy? That's the same argument - except k8s is free and available from many providers.
- shaklee3 8y ago
  Kubernetes service Discovery is just dns, so it sounds like you're doing the same thing, but by exiting CNAMEs.
  - clhodapp 8y ago
    Ah, if you look under the covers, Kubernetes service discovery is actually kernel-space virtual load balancers running on each node in your cluster. The DNS record just points to the "load balancer".

firebacon 8y ago

I'm not sure I understand this. You have a product that is split into many different components, and when you deploy this product to a customer site, each component runs on different hosts, so you have a bunch of wiring up of service addresses to do for every deployment? Could something like mDNS be a lightweight solution to that problem? And also I am genuinely curious how kubernetes would solve that. When you install kubernetes on all of these machines, don't you have to manually do the configuration for that either? So isn't it just choosing to rather configure kubernetes instead of your own application for each deployment? If it is that much simpler to setup a kubernetes cluster than your app, maybe the solution is to put some effort into the configuration management part of your product?

kross 8y ago
I'm not sure you understand the value k8s proposes based on your comments throughout this entire thread. Managing many nodes is the reason orchestration software exists. Your suggestion to "put some effort into configuration management" is effectively naive, homegrown orchestration. Build or buy? That's the same argument - except k8s is free and available from many providers.
shaklee3 8y ago
Kubernetes service Discovery is just dns, so it sounds like you're doing the same thing, but by exiting CNAMEs.
- clhodapp 8y ago
  Ah, if you look under the covers, Kubernetes service discovery is actually kernel-space virtual load balancers running on each node in your cluster. The DNS record just points to the "load balancer".