1

TLDR; Is there a AMQP equivalent inside Service Fabric for Stateless services for communication between microservices?

I am building an application which contains multiple microservices.

For starters this application will have microservices locked behind API gateway. This API Gateway is publicly accessible from either my web application or through an URL provided by the Gateway.

Reason why I am explaining this? Microservices will be able to communicate with each other, and can be used by developers to hook up whatever they want. From this post, I understood a REST interface is useful for exposing your service to the public, while using AMQP (Advanced Messaging Query Protocol) to request things from your database or other services. From this post I understood that AMQP is the preferred method of communication between services due to it being fully async.

So, based on this I am looking for an implementation where my microservices have A REST interface and will use AMQP to query the data that is being requested through the REST interface.

Since I am using Service Fabric and reinventing the wheel is a waste of time, I got curious whether Service Fabric comes with an "out-of-the-box" solution for AMQP or not. I have seen the IReliableCollection come by, but the documentation gave me the impression it was restricted to stateful services (I forgot to mention my services are stateless)

Many thanks.

Improve this question
3
  • What benefits does adding AMQP to your architecture provide?
    – Robert Harvey
    Jul 10, 2017 at 16:26
  • The benefits would be that I am executing long running tasks which I don't want the user to cancel halfway through. If I understand it correctly a REST API expects the user to wait from issuing to result, otherwise a cancellation-token gets passed from the browser into my REST API. This design originates from BULK requests, where a user can issues multiple requests in one go, which brings me to point two. Since the user can issue multiple requests, rather than them being executed synchronous, AMQP would allow them to be executed individually (if im correct).
    – Bart de Ruijter
    Jul 11, 2017 at 8:11
  • Service Fabric Reliable Services can be executed asynchronously, without waiting for them to return. Service Fabric Reliable Actors can do the same thing using an Actor Model. Read Service remoting with Reliable Services and Introduction to Service Fabric Reliable Actors.
    – Robert Harvey
    Jul 11, 2017 at 15:31

1 Answer 1

Reset to default
2

No, Service Fabric doesn't provide any messaging mechanism to communicate with reliable services. In practice, reliable services (stateful and stateless) are basically processes running doing nothing until you tell them to do something. You are responsible to create the mechanism to allow a service from receiving requests to do work (with remoting, REST, messaging...). Service Fabric only provides you the basis of how to implement this mechanism which is the ICommunicationListener.

If you want asynchronous communication between services, you could use, for example, Azure Service Bus and use a ready made communication listener.

Now, using messaging doesn't fully solve your problem of having long running processes, as starting a long running process can be done synchronously as well (you could call your service with REST for example, and the service could return immediately with an OK and start the long running process so that the client is not synchronously waiting). The main problem with long running processes is normally how to communicate back to the client that the process has completed. Note that being stateless services, you cannot poll the service to get the status of the process as the request could go to a different instance of the service (and it would go against the design rules of stateless services anyway).

If your scenario is two microservices talking to each other, you have several options to communicate back the results. If you are ok introducing a circular dependency, then you could simply do a REST call from A to B to start the process and a REST call from B to A to communicate the completion.

If you use messaging, you could create a mechanism to allow Replies, without introducing a circular dependency, for example, by sending the Reply Queue as part of the original message (or message properties in ASB). This way your service B doesn't have to know anything about the caller.

I hope it makes sense.

Improve this answer

Your Answer

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

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