Reputation: 508
At the moment we have a Genetic Algorithm (GA
) that runs quite a while, and I thought we could distribute it using Fabric
because theoretically it fits nicely as a microservice
. This is my first try at Fabric.
How should we do it ? Should we have a stateful service that runs and aggregates other actors tasks ? It's kinda similar to this project: https://github.com/Azure-Samples/service-fabric-dotnet-data-streaming-websockets
I'm not really sure how to go and there is not much documented on this subjects. This GA is really extensive and our goal is to distribute it's calculations.
Upvotes: 2
Views: 439
Reputation: 1716
In general I think Service Fabric can accommodate a long-running, distributed genetic algorithm like you describe, and would be a reasonable solution.
You would likely use SF actors to represent candidate solutions in your population, and also (as you describe) a SF reliable service to perform data aggregation, manage the population and generations, etc.
The choice of whether to use stateful vs. stateless actors/services largely depends on whether you want (or need) to manage state yourself (say, if you're integrating with a custom datastore) or if you're okay with SF managing state on your behalf. A "stateless" SF service can still have durable state... you are simply responsible for managing it yourself.
The nice thing about using SF is that it formally separates the logic + state of your solution from the low-level resource management needed to execute it. You define your application in code and separately configure a SF cluster with whatever resources you wish, and SF takes care of distributing the work efficiently and reliably across the cluster. Certainly you can do that yourself but its challenging to do correctly.
Sounds like a fun problem... best of luck!
Upvotes: 1
Reputation: 3975
I implemented a basic genetic algorithm app with Service Fabric as an app building exercise. Not sure if my approach is the best way to do things for your scenario, but I can describe what I did.
My app consisted of only actors, both stateful and stateless. I had a Processor stateful actor which provided all the management tasks and drove the algorithm. Because it was stateful, it maintained the history of all the genetic state across each of the generations that were produced. I also had a FitnessEvalTask stateless actor. This task was simply responsible for evaluating the fitness of an entity. Its input was the gene representation and its output was the fitness value. The idea was that you'd be spinning up instances of this actor at a high rate and they'd be distributed appropriately. The Processor app, being responsible for driving the algorithm, would create the necessary instances of the FitnessEvalTask actors and provide their input and have them report back with their fitness values and do the necessary processing afterwards. My client process, just a simple console app, would communicate with the Processor actor to initiate the algorithm and perform any necessary management tasks.
Upvotes: 1