github.com
Would love to hear your thoughts and feedback!
- Why would someone use this instead of Airflow/Cadence/Temporal/Databuilderframework?
- What does this look like when it's used? Most frameworks provide some kind of example project, you should too.
- Related, but more specifically, what does the `IDataStore` interface contract mean? Beyond the two functions that I have to implement, are there any considerations related to the overall performance/scalability/durability of the system? Would it make sense to use a disk-backed store, or Redis, or Postgres?
- How do I observe the system? Which workflows are running, which have failed, what the current state is, etc. Are there metrics? Logs?
All of this is based on the assumption you want people to adopt this framework. If it's just a cool side project, that's fine too, but you should probably try to set that expectation in the README.
> Airflow/Cadence/Temporal/Databuilderframework?
Which don't really think about modelling non-centralized things.
This of course doesn't mean they're not useful, it's just that they don't have what I believe is a good long-term value proposition.
I'm incredibly biased because I'm working on programmatic, real-time modelling of distributed systems with https://github.com/purpleidea/mgmt/
I've noted all of these and I'll modify the README to include them. Thank you for taking the time to go through in such detail :)
Given that the current state of a workflow:
- is inherently invisible
- all we can really check in the DB is if, for a workflow, the available data contains the target data;
how would I address observability concerns?
This is a function of a lack of workflow states due to the lower levels of abstraction it operates on. User defined workflow states would do the trick, but I suppose that would take writing some more code after integrating the framework.
The current pitch, which is "this is a workflow orchestration framework that does not allow for any monitoring or observability" is a complete non-starter. You may want to consider how other projects keep track of workflow state and allow for it to be instrumented.
On a side note, you will at some point in time have to deal with multi version workflows. I know that this is one feature that limits wide adoption of an orchestrator.
Thanks for sharing your work Deepak, you have some pretty extensive documentation! Funnily enough, the Golang framework is almost a clone of https://github.com/flipkart-incubator/databuilderframework (another orchestration engine in Java).
This is another HN post that extensively covers almost every major orchestrator in the market: https://news.ycombinator.com/item?id=24216317
As for multi version workflows, I suppose that will have to be a tradeoff between maintaining somewhat redundant code or adding workflows as WorkflowV1 and WorkflowV2 and stitching together relevant steps in respective versions (reduces redundancy to some extent but won't eliminate)
Would also love to see some examples.
Concerns I’ve had to deal with in the past (if these are solved, examples would go a long way):
- max queue size between elements is important. Don’t want the database reader role to outrun the workers, but also never want them desaturated
- some dynamic limits for local to a role (limit DB readers to limit connection pool) and global (how much cpu and memory share does a job need before starting)
- with control on the database reader yourself, i think you should be able to find a way around saturation/desaturation?
- again, the fairly certain you can limit DB readers in the DataStore interface you pass to the orchestrator. I'll think about the cpu and memory share and if there's a way to expose that.
A major concern I've always had with workflow orchestrators is the versioning of workflows. Think about long running workflows (>2 days). If you change your workflow logic, what happens to the existing ones that haven't completed yet?
Everyone handles this differently, and I've been thinking about a generic way to do this. Thoughts?
—-
Source: https://docs.github.com/en/repositories/managing-your-reposi...