I'm building a microservices architecture that requires microservices to communicate with each other. Searching Google has led me to believe that gRPC is the preferred method for achieving this. However, all the tutorials seem to hard-code RPC server addresses, which seems antithetical to the microservices architecture. When I search Google for how to avoid hard-coding addresses the results tend to involve API gateways, service discovery, load balancers, gRPC middleware, meshes, or some combination thereof. Is it really that involved to implement or is there a simple de facto solution that I'm missing? If it is that involved, is there an advantage to using that over something like RabbitMQ RPC?

Edit: To clarify, I used "de facto" to refer to a technology that the gRPC team specifically endorses or maintains for this purpose. I've struck it out because I think it was conveying the wrong connotation.

  • 1
    If you're going to downvote this question, please leave a comment explaining why, otherwise you're not helping OP ask better questions in the future. Regarding this specific question, the answers provided are exactly what I was looking for. Thank you to the community members that took it seriously.
    – alan
    Commented Jul 19, 2020 at 22:40

2 Answers 2


gRPC is certainly a popular choice, though I would balk at referring to any particular paradigm as unequivocally the best in an area as diverse as microservices.

The various means you list (gateways, service discovery, etc.) would be the best ways to minimize dependency upon the exact location of a given service. Which one is the best would depend a little more context than is provided here.

The pattern of using messaging to communicate between microservices is less common, but perfectly valid and may well be preferred depending on what your more specific requirements are.

Researching patterns is also a good time to check assumptions. You may not have the problems that things like gRPC, service gateways, discovery, meshes, etc. solve and, if not, you might be better off building a monolith, at least to start. It has been observed (https://www.martinfowler.com/bliki/MonolithFirst.html for starters) that many microservice-first efforts fail, but the success rate is higher for existing monoliths being refactored.

  • Thanks @Michael, this is very helpful!
    – alan
    Commented Jul 19, 2020 at 22:21

gRPC is a communication protocol. it needs to have the address of the target server just as you need server address for Http, FTP, SMTP and other protocols. so there should be something that can provide your service the address of other services. You need service discovery system (SD). There are two that are often used for this purpose:

  • ZooKeeper: used by Kafka and other big systems
  • Consul: new kid on the block
  • Redis: some use it as SD system but it's really a cache server not recommended as SD.

Your every service, even if there are multiple instances of the same service for load balancing, as soon as it starts has to register itself with the service discovery. The service discovery maintains a service directory much like unix paths with names against the IP address. so your services can have different IP addresses each time but same name.

your service, when it wants to query the other service, needs to have the target address. it will query the SD- for instance zookeeper, by a name. the zookeeper will return a target IP address that you can then use in your gRPC for communication.

  • Thanks @Simple Fellow. I hadn't heard of Consul or people using Redis for service discovery.
    – alan
    Commented Jul 19, 2020 at 22:24
  • 1
    @alan DNS sufficies. But: management of it doesn't scale, and it isn't that flexible either (for the purpose of discovering microservices). Which is why consul and other "service discovery" middleware is used. Consul builds on DNS, for example, managing it for you ... (to the level at which I understand it ...)
    – davidbak
    Commented Jul 20, 2020 at 5:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.