Making Serverless Orchestration 25x Faster
dbos.dev
dbos.dev
In my mind, the key value proposition of orchestration is that it is a solution for business processes where various parts have different owners. The fact that you need to tightly couple the logic for all your various states in DBOS sounds like it’s solving, at best, a partial part of the problem in my opinion.
Maybe the idea is that those who are using those other languages may have other workarounds already?
In either sense, its alot.
(Aside: The backend has plenty of bad languages. For example Python is considered a backend language but is considerably worse than most languages in speed, ergonomics, transitive dependencies, and so on... )
Toolchain weight, integration cost, ease of building DSLs, error message quality ... All those things matter when choosing a language to be embedded as a DSL into another system.
I wasn't really making a comment on that though but rather on overall popularity of TS vs Java, which is mostly just about the influence of the echo chamber and how that distorts peoples perception of what is out there.
Once your product reaches a wider audience you may notice that the balance is different but that doesn't mean that if you had chosen what makes sense for the wider audience (e.g. java) in the first iteration you'd be necessarily at a better place now. Perhaps you wouldn't never get to the place of worry how to please the masses because you product wouldn't have had any success in the first selection environment
I'd love to hear from folks who have experience using things like Beam or Spark. I've if the biggest pain points I've encountered is that there are definitely dozens of "mature" products to solve this problem that all different slightly in their setup and tradeoffs
You might find Azure's Durable Functions right up your alley. With durable functions you can break away workflows into activities which are invoked from orchestrator functions or other activities like regular functions, but the runtime handles the orchestration and state machine updates.
> Workflows provide the following reliability guaranteees:
> 1. They always run to completion.
You can’t guarantee that.
> 2 […] Regardless of what failures occur during a workflow's execution, it executes each of its transactions once and only once.
“Executed” is the wrong word here, if the database goes down half way through a transaction it’s neither executed zero times nor once.
> 3. Communicators execute at least once but are never re-executed after they successfully complete. If a failure occurs inside a communicator, the communicator may be retried
That’s not what at-least-once means? In 2. “execute” means “run to completion” but here the logic only works if it means “try”.
> Workflows must be deterministic: if called multiple times with the same inputs, they should always do the same thing.
Deterministic is the wrong word here, the correct word is idempotent. e.g. A simple counting function is deterministic but not idempotent.
For the last point, we'll clarify we mean that the code of the workflow function must be deterministic. For example, a workflow shouldn't make an HTTP GET request and use its result to determine what to do next, even though that's technically idempotent. Instead, it should make the HTTP request in a communicator (https://docs.dbos.dev/tutorials/communicator-tutorial) so its output can be saved and reused during recovery if necessary.
This "increasingly" has been in wide use for ages. Personally I was doing it in the 90s
Infinitely slower if you don’t use typescript though lol.
DBOS Cloud hosts and executes DBOS Transact apps/workflows a la (AWS Lambda+Step Functions). So it is apples:apples. Functionally, DBOS Cloud is like Lambda and Step Functions in one.
I am probably the farthest from a fan of serverless but I have developed some appreciation for all the tech that went into it and have found some good use-cases for serverless and serverless like things.
The one I am most bullish on is serverless at the edge. Edge compute is too expensive when provisioned the traditional way (as static reserved memory + CPU etc) and the kind of tasks you want to do at the edge (request manipulation, early AuthZ, etc) are amenable to serverless requirements/limitations. Cloudflare Workers is what I am primarily familiar with but I imagine Lambda@Edge and Fastly's solution are similar.
Is serverless dead? No. But the hype around building whole apps on Lambda and that actually being good is.