7

I m studying Microservices architecture and I m actually wondering something.

I m quite okay with the fact of using (back) service discovery to make request able on REST based microservices. I need to know where's the service (or at least the front of the server cluster) to make requests. So it make sense to be able to discover an ip:port in that case.

But I was wondering what could be the aim of using service registry / discovery when dealing with AMQP (based only, without HTTP possible calls) ?

I mean, using AMQP is just like "I need that, and I expect somebody to answer me", I dont have to know who's the server that sent me back the response.

So what is the aim of using service registry / discovery with AMQP based microservice ?

Thanks for your help

mfrachet
  • 8,772
  • 17
  • 55
  • 110
  • Interesting question. I had also thought that the MOM worked in a way like a service discovery feature. It provides location transparency and elasticity. The MOM is like a service registry, and all you need to know is the name of service, e.g. the exchange name, and the MOM routes and load balances your message to one of the service providers (consumers) and then get you an answer. Frankly, I didn't get the points provided in the only answer existing today. – Edwin Dalorzo Mar 09 '17 at 17:56

1 Answers1

5

AMQP (any MOM, actually) provides a way for processes to communicate without having to mind about actual IP addresses, communication security, routing, among other concerns. That does not necessarily means that any process can trust or even has any information about the processes it communicates with.

Message queues do solve half of the process: how to reach the remote service. But they do not solve the other half: which service is the right one for me. In other words, which service:

  • has the resources I need
  • can be trusted (is hosted on a reliable server, has a satisfactory service implementation, is located in a country where the local laws are compatible with your requirements, etc)
  • charges what you want to pay (although people rarely discuss cost when it comes to microservices)
  • will be there during the whole time window needed to process your service -- keep in mind that servers are becoming more and more volatile. Some servers are actually containers that can last for a couple minutes.

Those two problems are almost linearly independent. To solve the second kind of problems, you have resource brokers in Grid computing. There is also resource allocation in order to make sure that the last item above is correctly managed.

There are some alternative strategies such as multicasting the intention to use a service and waiting for replies with offers. You may have reverse auction in such a case, for instance.

In short, the rule of thumb is that if you do not have an a priori knowledge about which service you are going to use (hardcoded or in some configuration file), your agent will have to negotiate, which includes dynamic service discovery.

Akira
  • 4,001
  • 1
  • 16
  • 24
  • I'm trying really hard to understand the points in your answer. You see the MOM would offer location transparency, elasticity and load balancing, which are key features of service discovery. I can't quite understand where the "has the resources I need", or "can be trusted", etc, could be an issue here. I can add as many ephemeral docker containers with new consumers, and they will elastically come and go. Using topics I can control aspects like using the closest consumer or the cheapest, and the MOM most likely already offers security features. If could elaborate a bit more it would be awesome – Edwin Dalorzo Mar 09 '17 at 18:01
  • MOM will create an overlay network for you. If you control all processes attached to this overlay network you may not need service registry or discovery. You may simply create a protocol in which you send a broadcast message asking "who can do that for me" and trust the answers. – Akira Mar 09 '17 at 20:21
  • But the question was "in which situation I will benefit from service registry and discovery". One possible answer is related to having no prior trust on all MOM participants. If you cannot or do not want to trust anyone, you can to trust the registry only. If the registry suggests you should use resource A, then you can interact with A. In your example, it seems you control all participants, so having a registry will not provide any additional feature in this regard. – Akira Mar 09 '17 at 20:31
  • But there are other use cases in which having a registry is beneficial. A major one is to minimize the amount of messages circulating your MOM. You do not need to broadcast requests for "who can do that for me". Instead, you can have each new service to declare itself to a central registry saying "I can do X and Y" so if anyone wants X or Y the registry will know which service to recommend. – Akira Mar 09 '17 at 20:33