Communication between Service Fabric Applications

Question

We have grouped different functionalities in different Service Fabric Applications. Each Service Fabric Application is responsible for a set of functionalities within a certain scope(e.g. News, Blogging, User are all separate Applications). Different teams can work on those functionality scopes.

Each Application has a public REST API, like /users or /news or /blogs. So the public website can call these endpoints and retrieve/post information.

However, many times these Applications need to communicate with each other. But what is the best way to set this up? There are 2 ways to go as far as I can see now:

• Create a new HTTP endpoint on each Application which is only for use internally(using its own IP port which is not published publicly). Loosely coupled.
• Use RPC calls (but this will create a 'hard' link between Applications). Strongly coupled.

For now I think the separate HTTP endpoint would be the way to go, but I wonder if RPC calls are better? Is it, from a design philosophy, allowed to use RPC calls between Applications? Or would this bring me into trouble when an Application is updated and the interface has changed?

Or is there another pattern to use here?

Answer 1

For sure, you will have to rewrite something when you will change signature of your services or add something new. So, in both cases you will have to touch the code that is changed and the calling code.

The problem with RPC is that you need to have this interface accessible in any place you would like to use the service. So you can't actually independently upgrade services. HTTP communication could solve this issue.

But with HTTP communication you need to write pretty complicated code, which will lead to:

• places for new bugs
• difficulties with understanding the logic and architecture for new people
• probably you will need tesst and somebody will have to maintain them
• you will need to think about how to enroll updates — which service should be updated first

Yes, you are becoming free from dependencies(not completely as for me), but amount of work and maintenance rises a little as well. And RPC is cheap and simple.

I would use HTTP over RPC only in case where upgrading service separately is critical and upgrade of any service should not stop or affect work of any other.