Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: DBOS Java – Postgres-Backed Durable Workflows

github.com

Post reply on HN
Print view View original

51–59 of 59 posts

Re: Show HN: DBOS Java – Postgres-Backed Durable Workflows

#51

Post by hmaxdml »

purrcat259 wrote: post #41
KraftyOne wrote: post #8

Earlier quoted context omitted.

There's an observability and workflow management UI: https://docs.dbos.dev/java/tutorials/workflow-management You can view your workflows and queues, search/filter them by any number of criteria, visualize graphs of workflow steps, cancel workflows, resume workflows, restart workflows from a specific step--everything you'd want. Currently, this is available as a managed offering (Conductor - https://docs.dbos.dev/pro…

I was super interested in DBOS but I had to back out when I figured that the observability isn't self hostable yet :(, so I'm chuffed to hear its coming! Whats the best way to hear about it when it does? Maybe newsletter I can register to or something.

one way is to follow https://www.linkedin.com/company/dbos-inc for updates

Re: Show HN: DBOS Java – Postgres-Backed Durable Workflows

#52

Post by KraftyOne »

ivanr wrote: post #49
KraftyOne wrote: post #47

Earlier quoted context omitted.

Thanks for the great questions! 1. Yes, currently versioning is either automatically derived from a bytecode hash or manually set. The intended upgrade mechanism is blue-green deployments where old workflows drain on old code versions while new workflows start on new code versions (you can also manually fork workflows to new code versions if they're compatible). Docs: https://docs.dbos.dev/java/tutorials/workflow-tut…

> versioning Here's an example of a common long-running workflow: SaaS trials. Upon trial start, create a workflow to send the customer onboarding messages, possibly inspecting the account state to influence what is sent, and finally close the account that hasn't converted. This will usually take 14-30 days, but could go for months if manually extended (as many organisations are very slow to move). I think an "escape…

> versioning

Yes, something like that is needed, we're working on building a good interface for it.

> transactional enqueueing

But it is safe as long as it's done inside a DBOS workflow. If the connection is lost (process crashes, etc.) after the transaction but before the child is enqueued, the workflow will recover from the last completed step (the transaction) and then proceed to enqueue the child. That's part of the power of workflows--they provide atomicity across transactions.

Re: Show HN: DBOS Java – Postgres-Backed Durable Workflows

#53

Post by ivanr »

KraftyOne wrote: post #52
ivanr wrote: post #49

Earlier quoted context omitted.

> versioning Here's an example of a common long-running workflow: SaaS trials. Upon trial start, create a workflow to send the customer onboarding messages, possibly inspecting the account state to influence what is sent, and finally close the account that hasn't converted. This will usually take 14-30 days, but could go for months if manually extended (as many organisations are very slow to move). I think an "escape…

> versioning Yes, something like that is needed, we're working on building a good interface for it. > transactional enqueueing But it is safe as long as it's done inside a DBOS workflow. If the connection is lost (process crashes, etc.) after the transaction but before the child is enqueued, the workflow will recover from the last completed step (the transaction) and then proceed to enqueue the child. That's part of…

> > transactional enqueueing > But it is safe as long as it's done inside a DBOS workflow.

Yes, but I was talking about the point at which a new workflow is created. If my transaction completes but DBOS disappears before the necessary workflows are created, I'll have a problem.

Taking my trial example, the onboarding workflow won't have been created and then perhaps the account will continue to run indefinitely, free of charge to the user.

Re: Show HN: DBOS Java – Postgres-Backed Durable Workflows

#54

Post by KraftyOne »

rfonseca wrote: post #40
KraftyOne wrote: post #37

Earlier quoted context omitted.

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.

(disclaimer: I work at Microsoft, but am not directly involved with Durable Functions) 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…

Yes, agree the correspondence is close, the primary difference is in form factor and not in underlying guarantees (but form factor matters! Building this as a library was technically tricky, but unlocks a lot of use cases). Reading the Orleans and early durable functions papers in grad school (and many of your papers) was definitely helpful in our journey.

Re: Show HN: DBOS Java – Postgres-Backed Durable Workflows

#55

Post by KraftyOne »

ivanr wrote: post #53
KraftyOne wrote: post #52

Earlier quoted context omitted.

> versioning Yes, something like that is needed, we're working on building a good interface for it. > transactional enqueueing But it is safe as long as it's done inside a DBOS workflow. If the connection is lost (process crashes, etc.) after the transaction but before the child is enqueued, the workflow will recover from the last completed step (the transaction) and then proceed to enqueue the child. That's part of…

> > transactional enqueueing > But it is safe as long as it's done inside a DBOS workflow. Yes, but I was talking about the point at which a new workflow is created. If my transaction completes but DBOS disappears before the necessary workflows are created, I'll have a problem. Taking my trial example, the onboarding workflow won't have been created and then perhaps the account will continue to run indefinitely, free…

Looking at the trial example, the way I would solve it is that when the user clicks "start trial", that starts a small synchronous workflow that first creates a database entry, then enqueues the onboarding workflow, then returns. DBOS workflows are fast enough to use interactively for critical tasks like this.

Re: Show HN: DBOS Java – Postgres-Backed Durable Workflows

#59

Post by hazn »

KraftyOne wrote: post #48
hazn wrote: post #44

I remember reading that restate.dev is a 'push' based workflow and therefore works well with serverless workflows: https://news.ycombinator.com/item?id=40660568 what is your input on these two topics? aka pull vs push and working well with serverless workflows

The Restate model depends on a long-running external orchestrator to do the "pushing". However, that comes with downsides--you have to operate that orchestrator and its data store in production (and it's a single point of failure) and you have to rearchitect your application around it. DBOS implements a simpler library-based architecture where each of your processes independently "pulls" from a database queue. To mak…

thanks! hope you have a great weekend
Post reply on HN