CODEWITHSUNDEEP
azurecommunicationmicroservicesazure-service-fabric
user1711882
user1711882

Reputation:

Service Fabric flow pattern

For maintaining a vast amount of data in separate tables and databases I've written multiple console applications with different responsibilities. For instance, one application may seed a database, the next may process that new data and the last filters old vs new data. Etc.

Right now the services are run sequential (by hand). Depending on the result of such an application, you might have to run the previous one.

To automate this process-flow, I'm thinking about using Service Fabric as I see that services may commune with one another.
Is a pattern where there's one 'main' service that controls in/output from one services and sends it to the proper one correct? Or am I wildly over/under-thinking the use of the Service Fabric?

Upvotes: 0

Views: 188

Answers (1)

Kiryl
Kiryl

Reputation: 1526

I'd say that Service Fabric is a very flexible and powerful beast to cater many different needs, and you should definitely be able to build the desired architecture.

To create and control the flow, you could consider using SF Actors. You could easily build a pipeline or some sort of a chain where each Actor knows only how to complete its task, what next Actor to call upon the success and whom to complain if something has failed. To avoid having Actors doing long-running and intensive I/O work or something, you could leverage the reminders. For instance, as new portion of input arrives, call another SF service(an actual worker) where the console apps logic is implemented in to start the job, save the task id or any other attribute in actor's state to identify the 'worker', and set the reminder to check the status of the task in-progress. SF provides many different ways for its services to communicate with each other, so you could set up the interaction between Actors and 'workers' with a blink of an eye.

You could also play with GuestExecutables in SF if the console applications of yours have a huge non-trivial logic and you don't want to spend much time migrating the code in the beginning of your crusade.

It's just first thoughts and some very generic design. My point is, the SF is a very good choice when it comes to 'doing' services because of the variety of nice and robust options to handle many different cases.

P.S.

Check out Service Fabric Reliable Services Pipeline design. The discussion pertains to a similar topic and sheds a light on the details that you might find handy.

Upvotes: 0

Related Questions