KraftyOne

9 ms·

121.
by KraftyOne 2y ago
(DBOS co-founder here) From a DBOS perspective, the biggest differences are that DBOS runs in-process instead of on an external server, and DBOS lets you write worklflows as code instead of explicit DAGs. I'm less familiar with Hatche
122.
by KraftyOne 2y ago
(DBOS co-founder here) DBOS embeds durable execution into your app as a library backed by Postgres, whereas Restate provides durable execution as a service. In my opinion, this makes DBOS more lightweight and easier to integrate into an exi
123.
Making Apps Durable with 10x Less Code(dbos.dev)
3 points by KraftyOne 2y ago|0 comments
124.
The New Three-Tier Application(dbos.dev)
1 points by KraftyOne 2y ago|0 comments
125.
by KraftyOne 2y ago
Tables getting too big hasn't been a concern in practice because information on completed workflows can easily be GC'ed.
126.
by KraftyOne 2y ago
Yeah, this definitely requires splitting state-impactful activity into its own function. That's good practice anyways, though I understand it might be a pain in large codebases. Regional tags are definitely an interesting alternative!
127.
by KraftyOne 2y ago
Agreed, if you can do something completely synchronously while responding to an HTTP request, you should. But often you can't! Then, durable execution helps you manage the complexity of async processing.
128.
by KraftyOne 2y ago
DBOS solves this problem by storing state in Postgres, which is really good at coordinating multiple copies of the same service. Essentially, Postgres does the hard parts of external orchestration, letting you work with a simple library abs
129.
by KraftyOne 2y ago
This is a great answer, and yes, those are critical aspects of durable execution. Maybe I should write a follow-on post that goes into more detail...
130.
by KraftyOne 2y ago
Thanks! DBOS is simpler not because it ignores complexity, but because it uses Postgres to deal with complexity. And Postgres is a very powerful tool for building reliable systems!
131.
by KraftyOne 2y ago
Yes, that's totally fair. Usually, a step is a meaningful unit of work, such as a API call that performs an external state modification. Because each step is a fair chunk of work, and the overhead is just one write per step, this scale
132.
by KraftyOne 2y ago
That's exactly what this model is! The @Step decorator is for external state modifications. Then @Workflows orchestrate steps. The example shows the simplest possible external state modification--a print to the terminal. Steps can be
133.
by KraftyOne 2y ago
That's really interesting! It does seem that this is identically semantically to the library approach (as the logic your interpreter adds around steps could also be added by decorators) but is completely automatic. Which is great if t
134.
Durable execution should be lightweight(dbos.dev)
65 points by KraftyOne 2y ago|44 comments
135.
On The Eve of Superintelligence(ankitg.me)
3 points by KraftyOne 2y ago|1 comments
136.
by KraftyOne 2y ago
Generally we recommend against retroaction--the assumed model is that every workflow finishes on the code version it started. This is managed automatically in our hosted version (DBOS Cloud) and there's an API for self-hosting: https:
137.
by KraftyOne 2y ago
Great question! A workflow should be deterministic: if called multiple times with the same inputs, it should invoke the same steps with the same inputs in the same order. But steps don't have be deterministic, they can invoke LLMs, th
138.
by KraftyOne 2y ago
That's a really good question! Because DBOS is backed by Postgres, it scales as well as Postgres does, so 10K+ steps per second with a large database server. That's good for most workloads. Past that, you can split your workload i
139.
by KraftyOne 2y ago
It's not recommended--the assumed model is that every workflow finishes on the code version it started. This is managed automatically in our hosted version (DBOS Cloud) and there's an API for self-hosting: https://docs.
140.
by KraftyOne 2y ago
Got it! What specifically are you looking for? If you launch multiple DBOS instances connected to the same Postgres database, they'll automatically form a distributed task queue, dividing new work as it arrives on the queue. If you&#
141.
by KraftyOne 2y ago
Yes, if your workflow interacts with multiple external systems and you need it to fully back out and clean up after itself after a step fails, you'll need backup steps--this is basically a saga pattern. Where DBOS helps is in ensuring
142.
by KraftyOne 2y ago
That work is done by the decorators! They wrap around your functions and store the execution state of your workflows in Postgres, specifically: - Which workflows are executing - What their inputs were - Which steps have completed - What th
143.
by KraftyOne 2y ago
That's definitely worth considering! The core algorithms can work with any data store. That said, we're focused on Postgres right now because of its incredible support and popularity.
144.
by KraftyOne 2y ago
Yeah, the arguments and return values of steps have to be serializable to JSON. For versioning, each workflow is tagged with the code version that ran it, and we recommend recovering workflows on an executor running the same code version as
145.
by KraftyOne 2y ago
The state can be stored in any Postgres instance, either locally or in any cloud. For code, here's the bare minimum code example for a workflow: class Example { @DBOS.step() static async step_one() { ... } @D
146.
Show HN: DBOS TypeScript – Lightweight Durable Execution Built on Postgres(github.com)
77 points by KraftyOne 2y ago|49 comments
147.
How Unfair Is the Coin: Lessons from Building a Biotech Startup(ankitg.me)
3 points by KraftyOne 2y ago|0 comments
148.
The software you need for holiday overdecoration(dbos.dev)
209 points by KraftyOne 2y ago|61 comments
149.
by KraftyOne 2y ago
For separation of concerns/isolation, DBOS does all its bookkeeping in a separate Postgres database from your app database (documented here: https://docs.dbos.dev/explanations/system-tables ). And yes, you can abso
150.
by KraftyOne 2y ago
Building a complex stateful system will always be hard, but workflows as an abstraction have two big benefits: 1. Automatic handling of any transient failures or service interruptions/crashes/restarts. Transient failures in steps

More ›