I really wish you guys would change the name since the product has moved so far away from the goals and concepts in the original publication. :). I love the product and what you are doing -- it's definitely needed and valuable.
What is the original publication?
Show HN: DBOS Java – Postgres-Backed Durable Workflows
31–40 of 59 posts
Re: Show HN: DBOS Java – Postgres-Backed Durable Workflows
#32I like dbos architecture much more than temporal since it is much easier to operate on small team. But dbos doesn't have opensource release of web ui, which is most critical part for a workflow management tool. Since competitor have all of itself opensource I don't think dbos will have a chance.
Re: Show HN: DBOS Java – Postgres-Backed Durable Workflows
#33I was trying to think of a use case for this and I was reminded of a Sun Microsystems demo (yes I'm that old) I saw. The paused a JVM and "slept" it, then kicked up on another machine almost instantly, all over the network. Was a pretty cool party trick, but then they did it when an HTTP request came in (Serverless was invented a LONG time ago!). I kinda wonder if this could be used for that?
Re: Show HN: DBOS Java – Postgres-Backed Durable Workflows
#34The Java version looks pretty danged cool paging through the some of the code. I was trying to think of a use case for this and I was reminded of a Sun Microsystems demo (yes I'm that old) I saw. The paused a JVM and "slept" it, then kicked up on another machine almost instantly, all over the network. Was a pretty cool party trick, but then they did it when an HTTP request came in (Serverless was invented a LONG time…
Re: Show HN: DBOS Java – Postgres-Backed Durable Workflows
#35I like dbos architecture much more than temporal since it is much easier to operate on small team. But dbos doesn't have opensource release of web ui, which is most critical part for a workflow management tool. Since competitor have all of itself opensource I don't think dbos will have a chance.
Re: Show HN: DBOS Java – Postgres-Backed Durable Workflows
#36Re: Show HN: DBOS Java – Postgres-Backed Durable Workflows
#37Peter, how does this compare to Azure Durable Functions? (Say, for the sake of argument, that you are comparing the Python version of both) Are there things that fundamentally you can do in one and not in the other?
Re: Show HN: DBOS Java – Postgres-Backed Durable Workflows
#38I like dbos architecture much more than temporal since it is much easier to operate on small team. But dbos doesn't have opensource release of web ui, which is most critical part for a workflow management tool. Since competitor have all of itself opensource I don't think dbos will have a chance.
We'll be releasing self-hostable Conductor (the web UI) soon--stay tuned!
Re: Show HN: DBOS Java – Postgres-Backed Durable Workflows
#39The Java version looks pretty danged cool paging through the some of the code. I was trying to think of a use case for this and I was reminded of a Sun Microsystems demo (yes I'm that old) I saw. The paused a JVM and "slept" it, then kicked up on another machine almost instantly, all over the network. Was a pretty cool party trick, but then they did it when an HTTP request came in (Serverless was invented a LONG time…
I wonder if my Solaris 7 cert is still good...
Re: Show HN: DBOS Java – Postgres-Backed Durable Workflows
#40Peter, how does this compare to Azure Durable Functions? (Say, for the sake of argument, that you are comparing the Python version of both) Are there things that fundamentally you can do in one and not in the other?
The main difference is that this is a library you can install and use in any application anywhere, while Durable Functions is (as I understand it) primarily for orchestrating serverless functions in Azure.
Being a library is a pretty interesting feature! Correct, Durable Functions allows you to write task-parallel orchestrations of task-parallel 'activities' (which are stateless functions), and these orchestrations are fully persistent and resilient, like DBOS executions. It also has the concept of 'Entities', which are named objects (of a type you define) that "live forever", and serialize all method invocations, which are the only way to change their private state. These are also persistent. The Netherite paper [1], section 2, describes this model well.
So, there seems to be a pretty close correspondence between DBOS steps and DF activities, and between workflows and orchestrations. I don't know what the correspondence is to DF entities is in the DBOS model.
[1] https://www.microsoft.com/en-us/research/wp-content/uploads/...