0

I am in a situation where I can use Service Fabric (locally) but cannot leverage Azure Service Bus (or anything "cloud"). What would be the corollary for queuing/pub-sub? Service Fabric is allowed since it is able to run in a local container, and is "free". Other 3rd party messaging infrastructure, like RabbitMQ, are also off the table (at the moment).

I've built systems using a locally grown bus, built on MSMQ and WCF, but I don't see how to accomplish the same thing in SF. I suspect I can have SF services use a custom ICommunicationListener that exposes msmq, but that would only be available inside the cluster (the way I understand it). I can build an HTTPBridge (in SF) in front of those to make them available outside the cluster, but then I'd lose the lifetime decoupling (client being able to call a service, using queues, even if that service isn't online at the time) since the bridge itself wouldn't benefit from any of the aspects of queuing.

I have a few possibilities but all suffer from some malady that only exists because of SF, locally. Also, the same code needs to easily deploy to full Azure SF (where I can use ASB and this issue disappears) so I don't want to build two separate systems just because of where I am hosting it in some instances.

Thanks for any tips.

Will Comeaux
  • 325
  • 1
  • 14

2 Answers2

1
  1. You can build this yourself, for example like this. This uses a BrokerService that will distribute message-data to subscribed services and actors.
  2. You can also run a containerized queuing platform like RabbitMQ with volumes.

By running the queue system inside the cluster you won't introduce an external dependency.

LoekD
  • 11,402
  • 17
  • 27
1

The problem is not SF, The main issue with your design is that you are coupling architectural requirements to implementations. SF runs on top of VirtualMachines, in the end, the only difference is that SF put the services in those machines, using another solution you would have an Agent Deploying these services in there or doing a Manual deployment. The challenges are the same.

It is clear from the description that the requirement in your design is a need for a message queue, the concept of queues are the same does not matter if it is Service Bus, RabbitMQ or MSMQ. Each of then will have the basic foundations of queues with specifics of each implementation, some might add transactions, some might implement multiple patterns, and so on.

If you design based on specific implementation, you will couple your solution to the implementation and make your solution hard to maintain and face challenges like you described.

Solutions like NServiceBus and Masstransit reduce a lot of these coupling from your code, and if you think these are not enough, you can create your own abstraction. Then you use configurations to tied your business logic to implementations.

Despite the above advice, I would not recommend you using different solutions per environment, because as said previously, each solution has it's own implementations and they might not assimilate to each other, as example, you might face issues in production because you developed against MSMQ on DEV and TEST environments, and when deployed to Production you use ServiceBus, they have different limitations, like message size, retention period and son on.

If you are willing to use MSMQ, you can add MSMQ to the VMs running your cluster and connect from your services without any issue. Take a look into this SO first: How can I use MSMQ in Azure Service Fabric

Diego Mendes
  • 10,631
  • 2
  • 32
  • 36
  • Right. I plan to factor out a "Bus" abstraction so that I can plug in other implementations (one being a "local" bus, living in the corporate network, using available pieces, MSMQ being one). I'd also build an implementation targeting ASB. The point is to deploy/utilize the bus that fits the need (money and "keep my data local") being the two biggest factors I've seen. Thanks for the tip. I will look more into how MSMQ works inside of SF, knowing the limits it imposes. As mentioned, RabbitMQ, nServiceBus and similar middle-ware are verboten - but I am not designing with that limitation. – Will Comeaux Oct 16 '18 at 19:34