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

Dbos: Durable Workflow Orchestration with Go and PostgreSQL

github.com

Post reply on HN
Print view View original

41–50 of 62 posts

Re: Dbos: Durable Workflow Orchestration with Go and PostgreSQL

#41

Post by vineyardmike »

bjornsing wrote: post #27
KraftyOne wrote: post #13

Earlier quoted context omitted.

Yes, in any durability framework there's still the possibility that a process crashes mid-step, in which case you have no choice but to restart the step. Where DBOS really shines (vs. Temporal and other workflow systems) is a radically simpler operational model--it's just a library you can install in your app instead of a big heavyweight cluster you have to rearchitect your app to work with. This blog post goes into…

> Yes, in any durability framework there's still the possibility that a process crashes mid-step, in which case you have no choice but to restart the step. Golem [1] is an interesting counterexample to this. They run your code in a WASM runtime and essentially checkpoint execution state at every interaction with the outside world. But it seems they are having trouble selling into the workflow orchestration market. Pe…

That still fundamentally suffers the same idempotency problem as any other system. When interacting with the outside world, you, the developer, need to be idempotent and enforce it.

For example, if you call an API (the outside world) to charge the user’s credit card, and the WASM host fails and the process is restarted, you’ll need to be careful to not charge again. This can happen after the request is issued, but before the response is received/processed.

This is no different than any other workflow library or service.

The WASM idea is interesting, and maybe lets you be more granular in how you checkpoint (eg for complex business logic that is self-contained but expensive to repeat). The biggest win is probably for general preemption or resource management, but those are generally wins for the provider not the user. Also, this requires compiling your application into WASM, which restricts which languages/libraries/etc you can use.

Re: Dbos: Durable Workflow Orchestration with Go and PostgreSQL

#42

Post by hmaxdml »

intermerda wrote: post #39
hmaxdml wrote: post #2

Thanks for posting! I am one of the author, happy to answer any question!

I remembered reading about the DBOS paper a while back - https://arxiv.org/abs/2007.11112 . Is this an evolution of that research work? If so, how did an OS for databases morph into a workflow orchestration service?

It is an evolution. The DBOS workflow orchestrator places a DB at the center of your application to handle most of the complicated state management problems.

Re: Dbos: Durable Workflow Orchestration with Go and PostgreSQL

#43

Post by osigurdson »

chc4 wrote: post #4

> Exactly-Once Event Processing This sounds...impossible? If you have some step in your workflow, either you 1) record it as completed when you start, but then you can crash halfway through and when you restore the workflow it now isn't processed 2) record it as completed after you're done, but then you can crash in-between completing and recording and when you restore you run the step twice. #2 sounds like the obvio…

Exactly once is usually just at least once with a unique message ID and dedupe window.

Re: Dbos: Durable Workflow Orchestration with Go and PostgreSQL

#44

Post by osigurdson »

hmaxdml wrote: post #2

Thanks for posting! I am one of the author, happy to answer any question!

Did you consider using NATS? While I haven't tried this deployment model, you can embed it in a go program as a library. If you wanted something really minimal this might be an option.

I use NATS to acheive this type of durable processing. It works well. Of course, idempotent code is needed but I don't think this can be avoided.

Re: Dbos: Durable Workflow Orchestration with Go and PostgreSQL

#45

Post by atombender »

I've played with DBOS and like it, but I have to say the lack of a control plane and UI in the open source version means it may have a hard time competing with Temporal, which provides both.

Being able to see the state of workflows and their histories is a key part of having an application in production. Without a control plane, my understanding is that DBOS can't offer the same kind of failure recovery as Temporal, though it's unclear to me how the "Transact" engine does this.

A big benefit that Temporal's architecture provides is separation of concerns. Temporal can coordinate workflows across many apps, whereas with DBOS each app (as far as I understand it, at least) is a silo managing its own queues.

Re: Dbos: Durable Workflow Orchestration with Go and PostgreSQL

#46

Post by bjornsing »

vineyardmike wrote: post #41
bjornsing wrote: post #27

Earlier quoted context omitted.

> Yes, in any durability framework there's still the possibility that a process crashes mid-step, in which case you have no choice but to restart the step. Golem [1] is an interesting counterexample to this. They run your code in a WASM runtime and essentially checkpoint execution state at every interaction with the outside world. But it seems they are having trouble selling into the workflow orchestration market. Pe…

That still fundamentally suffers the same idempotency problem as any other system. When interacting with the outside world, you, the developer, need to be idempotent and enforce it. For example, if you call an API (the outside world) to charge the user’s credit card, and the WASM host fails and the process is restarted, you’ll need to be careful to not charge again. This can happen after the request is issued, but be…

The challenges around idempotency remain to some extent, yes. But you have that problem even in non-workflow code, so the usual patterns will just work with no extra mental effort from the developer.

Re: Dbos: Durable Workflow Orchestration with Go and PostgreSQL

#47

Post by hmaxdml »

osigurdson wrote: post #44
hmaxdml wrote: post #2

Thanks for posting! I am one of the author, happy to answer any question!

Did you consider using NATS? While I haven't tried this deployment model, you can embed it in a go program as a library. If you wanted something really minimal this might be an option. I use NATS to acheive this type of durable processing. It works well. Of course, idempotent code is needed but I don't think this can be avoided.

We decided to use Postgres because of the relational semantics, the ease of integration with user applications, and it's remarkable popularity

Re: Dbos: Durable Workflow Orchestration with Go and PostgreSQL

#49

Post by hmaxdml »

atombender wrote: post #45

I've played with DBOS and like it, but I have to say the lack of a control plane and UI in the open source version means it may have a hard time competing with Temporal, which provides both. Being able to see the state of workflows and their histories is a key part of having an application in production. Without a control plane, my understanding is that DBOS can't offer the same kind of failure recovery as Temporal,…

DBOS stores all the workflow metadata in postgres, which is readily queryable for observability. We've recently seen a user setup an entire Grafana dashboard to observe their numerous workflows.

A postgres server can host many databases, and multiple applications can use the same server. The same dashboard can be used to monitor them all.

With respect to recovery: A new Transact process will run a round of recovery at startup. Transact also exposes an admin server with a recovery endpoint.

For more elaborate scenarios, we have control plane options commercially available.

Re: Dbos: Durable Workflow Orchestration with Go and PostgreSQL

#50

Post by KraftyOne »

d0100 wrote: post #48

Is there a nice interface to visualize all workers/workflows running like temporal has? Even better if the interface is also embeddable into a go http handler

Yes, there's a full workflow visualization/management interface (not embeddable though): https://docs.dbos.dev/golang/tutorials/workflow-management
Post reply on HN