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

Making Serverless Orchestration 25x Faster

dbos.dev

Post reply on HN
Print view View original

1–10 of 33 posts

Re: Making Serverless Orchestration 25x Faster

#2

Post by mind-blight »

This seems really cool. I've just been running into scenarios where this kind of durable execution is really helpful. I've been doing basic things with RabbitMQ plus a job server, but there are definitely limitations.

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

Re: Making Serverless Orchestration 25x Faster

#4

Post by plandis »

> You simply write your workflow as a TypeScript function which calls your steps, implemented in other TypeScript functions. The framework automatically instruments each step to record its output in the database after executing.

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.

Re: Making Serverless Orchestration 25x Faster

#6

Post by alanyilunli »

Pardon my naivety but why was Typescript chosen as the interface for writing transactional workflows? I can't help but think that a backend language that is more popular for those use-cases would be more relevant.

Maybe the idea is that those who are using those other languages may have other workarounds already?

Re: Making Serverless Orchestration 25x Faster

#8

Post by Zambyte »

alanyilunli wrote: post #6

Pardon my naivety but why was Typescript chosen as the interface for writing transactional workflows? I can't help but think that a backend language that is more popular for those use-cases would be more relevant. Maybe the idea is that those who are using those other languages may have other workarounds already?

The overlap for the target audience of TypeScript and "serverless" systems seems much larger than the overlap of the target audience of "backend languages" and "serverless"

Re: Making Serverless Orchestration 25x Faster

#9

Post by bnchrch »

alanyilunli wrote: post #6

Pardon my naivety but why was Typescript chosen as the interface for writing transactional workflows? I can't help but think that a backend language that is more popular for those use-cases would be more relevant. Maybe the idea is that those who are using those other languages may have other workarounds already?

I think the naivety lies in underestimating how many backend systems are written in Typescript, and how large of the developer population knows / uses TS.

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... )

Re: Making Serverless Orchestration 25x Faster

#10

Post by robertlagrant »

mind-blight wrote: post #2

This seems really cool. I've just been running into scenarios where this kind of durable execution is really helpful. I've been doing basic things with RabbitMQ plus a job server, but there are definitely limitations. 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 p…

I always thought Temporal[0] would be a brilliant choice for that sort of durable processing.

[0] https://temporal.io

Post reply on HN