I know this is an odd question, and I make the bet that this is likely to depend on the scenario or preference.
If I have a set of microservices, lets just generically call them A, B, and C. Each of these is running in its own bod.
If A needs to get access to B and C to handle a request, then I would want to rely on Kubernetes DNS resolution and create a service that will route to B, and another service that would route to C. Let's generically call these ServiceB, and ServiceC.
Right now, I just store the service names in constants defined in the client code that makes the requests.
Based on your own experience, is there a good reason for these to be stored in a config file (or configmap)? I can't imagine them changing much, if at all throughout the lifecycle of the application.
What do you do in your practice, and why?
Based on your own experience, is there a good reason for these to be stored in a config file (or configmap)?
What do you do in your practice, and why?