Similar to serverless frameworks/services there is a minimum that you can set, such that you always have a certain number of nodes running.
I also have not used it in production but used it to do some testing of the viability for running some mildly resource intensive tasks. We didn’t end up using it because there was/is not a GCP backend and we didn’t want to add k8s.
We didn’t end up using Oban Pro’s Relay for our particular use case and instead used a Workflow, and PubSub, and then tracked the completion and returns of the workflow steps in the caller and listened for incremental messages on the subscription. Not super elegant, but got the job done of easily allowing multiple people to track the progress.
There’s Oban.Pro.Plugins.DynamicScaler Oban.Pro.Plugins.DynamicScaler — Oban Pro v1.6.0-rc.3 that works with the Oban.Pro.Cloud behaviour.
That might be your best approach for it you use Oban.Pro and the Relay approach.
If you don’t go the Oban Pro route (which I would still suggest. “Boring” architecture is reliable and maintainable architecture) I would steer towards a newer registry approach. I have not used Ra.Registry, but have been following ra for a long time and am very impressed.
I’ve used Horde a great deal, and although it does a great deal very well, once you get into writing your own distribution strategy, you’re going to want a way to reliably test it, and depending on how you do your testing Horde has some disadvantages in that it expects a Horde.DynamicSupervisor’s name to be able to be turned into an atom.
https://github.com/derekkraan/horde/issues/234
It made my testing a little difficult and because of that I’ve usually tried something else first. It’s still a phenomenal library though. I tried to figure out a way to fix it the issue as well, but I never even got to the point where my fix was working let alone worthy of a pull request upstream.
