I don't want to start a debate about a specific vendor but the cost was very high. Leaky serialization of call arguments and results, then hairpinning messages across the internet and back to get to workers. 200ms overhead for a no-op call. There was some observability benefit but it didn't allow for debugger access and had its own special way of packaging code so net add of complexity there too. That's not getting into the induced complexity caused by adding a bunch of RPC boundaries to fit their execution model. All that and using the thing effectively still requires understanding their runtime model. I understand the motivation, but not the technical approach.
Regardless of the vendor, it sounds like you were using the old style model where there is a central coordinator and a shim library that talks to a black box binary.
The style presented in this blog post doesn't suffer from those downsides. It's all done with local databases and pure language libraries, and is completely transparent to the user.
Yeah, the system in the blog post retargeted at Postgres would be a step up from what I've used. I'm still skeptical of the underlying model of message replay for rehydration because it makes reasoning about the changes to the logic ("flows" in the post's terminology) really hard. You have to understand what the runtime is doing as well as how all the previous versions of the code worked, the implications for all the possible states of the cached step results, and how those logs will behave when replayed through the current flow code. I think in all worlds where transactions are necessary a central coordinator is necessary, whether it's an RDMS under a traditional app or something fancier under one of these durable execution things.
In the end I'm left wondering what the net benefit is over say an actor framework that more directly maps to the notion of long-lived state with occasional activity and is easier to test.
All that said some of the vendors have raised hundreds of millions of dollars so someone must believe in the idea.
