> You simply write your workflow as a TypeScript function
Infinitely slower if you don’t use typescript though lol.
Making Serverless Orchestration 25x Faster
21–30 of 33 posts
Re: Making Serverless Orchestration 25x Faster
#22Earlier 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).
Is there data to support this viewpoint? I've heard it often, but it always seems to lean on anecdata or caveats that the concrete datasets out there have blind spots (which is plausible, but certainly not a given). And those concrete datasets don't usually tend to put Java near the top for professional usage, or any metric for that matter.
Re: Making Serverless Orchestration 25x Faster
#23> 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…
Author here--can you break that down a little more? A DBOS workflow can call out to external APIs using communicator functions (https://docs.dbos.dev/tutorials/communicator-tutorial), so it works well with other loosely-coupled services.
Re: Making Serverless Orchestration 25x Faster
#24Earlier quoted context omitted.
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.
True. Though the last time Stonebraker tried this (VoltDB) they did lean on Java for DB side custom logic.
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.
Re: Making Serverless Orchestration 25x Faster
#25These docs don’t fill me with confidence. That’s… weird given who’s behind the project. What gives?
> 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.
Re: Making Serverless Orchestration 25x Faster
#26Earlier quoted context omitted.
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.
True. Though the last time Stonebraker tried this (VoltDB) they did lean on Java for DB side custom logic. 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.
The eco chamber is real but it cuts both ways: if you want your product to be successful you need a first wave of adopters and their echo chamber will shape your product through their feedback.
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
Re: Making Serverless Orchestration 25x Faster
#27is 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
I think people realized that they had ultimately reinvented PHP and sometimes a stateful app server is just fine for your 100 req/day app.
Re: Making Serverless Orchestration 25x Faster
#28Earlier quoted context omitted.
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.
Good concept, buggy implementation. That’s not ok for a distributed system that glues together important pieces of your product.
Re: Making Serverless Orchestration 25x Faster
#29These docs don’t fill me with confidence. That’s… weird given who’s behind the project. What gives? > 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…
Author here--thanks for the feedback! We'll update the docs to clarify the first three points assume that the database and application always restart and return online if they go offline.
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.
Re: Making Serverless Orchestration 25x Faster
#30is 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 t…
Not to mention, if your app is horizontally large, and depending on how it's configured, cold starts can really kill your overall performance.