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

11–20 of 33 posts

Re: Making Serverless Orchestration 25x Faster

#11

Post by jpgvm »

bnchrch wrote: post #9
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... )

It's a lot but Java is still king. The SV bubble seems to forget just how dominant Java is in backend software (well until they get a job at FANG and realise Java never left the building).

Re: Making Serverless Orchestration 25x Faster

#12

Post by dangoodmanUT »

robertlagrant wrote: post #10
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

Temporal is great until it's not XD

Re: Making Serverless Orchestration 25x Faster

#15

Post by jpgvm »

localfirst wrote: post #13

is it just me or am i seeing less and less serverless showing up in roles? seems like there was a big rush during the hype around 2021, and people went back to ec2/kubernetes

That is because that is exactly what happened. It was tried, people went too far and tried to build entire applications in FaaS and it was largely unsuccessful. Cue a bunch of migrations onto k8s to contain costs and get back control over process lifetime, better integration with existing monitoring/tracing, etc, etc.

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.

Re: Making Serverless Orchestration 25x Faster

#16

Post by nogridbag »

dangoodmanUT wrote: post #12
robertlagrant wrote: post #10

Earlier quoted context omitted.

I always thought Temporal[0] would be a brilliant choice for that sort of durable processing. [0] https://temporal.io

Temporal is great until it's not XD

Care to elaborate or link to your thoughts? Temporal has always been on my radar. I wanted to do a deeper dive, but the cost seems pretty high for the managed service.

Re: Making Serverless Orchestration 25x Faster

#17

Post by chipdart »

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…

> This seems really cool. I've just been running into scenarios where this kind of durable execution is really helpful.

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.

Re: Making Serverless Orchestration 25x Faster

#18

Post by FpUser »

>"Increasingly, developers are using reliable workflows to help build applications. Reliable workflows are programs that always run to completion–if they’re interrupted, they automatically resume from where they left off."

This "increasingly" has been in wide use for ages. Personally I was doing it in the 90s

Re: Making Serverless Orchestration 25x Faster

#19

Post by secondrow »

hxboo wrote: post #5

Is it comparing apples to apples? DBOS looks more like Spring than AWS Lambda imo.

It depends what part of DBOS you're looking at. DBOS Transact is the framework (TypeScript) used to develop apps/workflows such as those in the benchamrk.

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.

Re: Making Serverless Orchestration 25x Faster

#20

Post by ithkuil »

jpgvm wrote: post #11
bnchrch wrote: post #9

Earlier quoted context omitted.

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

It's a lot but Java is still king. The SV bubble seems to forget just how dominant Java is in backend software (well until they get a job at FANG and realise Java never left the building).

Raw popularity is not the only parameter.

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.

Post reply on HN