Stream: interviews

Topic: 636: The era of durable execution

Logbot (Apr 10 2025 at 22:57):

Stephan Ewen, Founder and CEO of Restate.dev joins the show to talk about the coming era of resilient apps, the meaning of and what it takes to achieve idempotency, this world of stateful durable execution functions, and when it makes sense to reach for this tech. :link: https://changelog.fm/636

Daniel Buckmaster (Apr 11 2025 at 07:48):

Just started listening! Keen for this. There was previous discussion around this topic: https://changelog.zulipchat.com/#narrow/stream/453512-general/topic/What.20trending.20tech.20are.20you.20most.20bullish.20on.3F/near/490607287

Matt Johnson (Apr 11 2025 at 13:56):

In the first five minutes, I knew I was going to love this episode. The conversation diving into explaining the concept of idempotency was great to hear called out rather than just glossed over. It is such a useful concept to understand, but not always easy to grasp and apply. I’ve utilized similar concepts applied to managing system resources and configuration management with Terraform and Ansible where it’s important to ensure the expected result even when events are repeated. It’s nice to see the significant impact these same principles provide when applied in other areas than the ones I have familiarity with.

cevado (Apr 11 2025 at 21:05):

I might be biased here, from working with Elixir for so long... but the entire episode gave me vibes of you have built an erlang thing, and when Jerod mentioned Elixir just caught him off guard. :joy:
Excelent episode, and it's great that is a tool that you can self host and is source available. But the same way as temporal I think it just doesn't appeal for me the same way it would appeal to others.

Ron Waldon-Howe (Apr 11 2025 at 21:42):

There was an Oxide and Friends episode on distributed sagas that's sort of related: https://oxide-and-friends.transistor.fm/episodes/the-saga-of-sagas

Tim Uckun (Apr 11 2025 at 21:49):

I don't know why Erlang didn't take over the world. I guess back when it started getting into the mainstream it had some performance problems with strings or something. That article is brilliant though. I know I have built complex systems and then said "I should have done it in erlang"

Ron Waldon-Howe (Apr 11 2025 at 22:39):

You can achieve similar reliability in Go if you never mutate anything, and only use channels to pass values between go funcs (no sharing values between them otherwise)
Otherwise, for efficient and safe concurrency, really nothing beats Erlang/Elixir, Swift, or Rust
Or Pony :) https://www.ponylang.io/

Daniel Buckmaster (Apr 12 2025 at 01:17):

@cevado it's a fun article but it doesn't really paint a compelling picture to me... I would sincerely really love to understand the Erlang way, but maybe I just haven't worked on the kinds of systems which need it?

Maybe resisting the microservices hype has insulated me from the worst of the problems. We still run our company on a PHP monolith with a Redis job queue and a few tightly-scoped side services. I'm not saying that's better than using Erlang, just that maybe I'm not well placed to understand the problems the post describes :/

cevado (Apr 12 2025 at 12:22):

@Daniel Buckmaster the article is just for fun but I guess it highlights what the erlang vm really is:

• An asynchronous, message-based runtime.
• Supervision trees for fault-tolerant processes.
• Lifecycle management for dynamic workers.
• APIs for synchronous and asynchronous calls.
• Live introspection tools for debugging.
• A distributed message inbox (that still isn’t quite sharded right).

when I worked with ruby and started working with elixir I had the same feeling. "I just don't need it all". the thing clicked to me when I realized that I stopped reaching for external tools and just relied on what's already available on the VM.
when your runtime provide you the basics of atomic execution, location transparency, communication abstractions that are cluster aware, easy to handle clusterization, self recovery and everything else that comes with erlang vm you just delay more definitive and impactfull architectural decisions. this means you end up having more time to bake in your solution, see it evolving as your app scales up and do the choices that is a big compromise over your entire system architecture later.
it's like what Sandi Metz says on this talk about the wrong abstraction. sometimes you need to give time for the right abstraction to show up, now imagine that applied to the distributed systems architecture. it makes the life of the engineer and reasoning about what you're doing more simple. just as an example in the past 3 jobs that i worked, we reached for redis once, and it was to coordinate something between a go application and the elixir application.
but for sure it's a double edged sword, you shouldn't get in love with the smart solution that you've built, when you have a architectural decision screaming to be made, it's good to extract it out, make it available to other parts/applications of your system.

Tim Uckun (Apr 12 2025 at 22:21):

In my case I had to build several micro services around a rails monolith. Some were because I wanted better performance, some were because I had to have many persistent connections, some were for background tasks and scheduled tasks, and I also leveraged some SAAS apps from Amazon. Of course apps that monitored all this and reacted when things went wrong.

When it was all said and done there were several languages at play, a few databases etc. I think Erlang would have been able to handle all of that in a uniform and and comfortable way.

Having said all that I wasn't an expert at Erlang having just dabbled in it for fun and of course nobody else in the company knew erlang and I had no idea where I would hire erlang programmers from.

This was all more than a decade ago. Today I might have reached for go maybe but back then go was pretty new and didn't have much mindshare.

Ron Waldon-Howe (Apr 13 2025 at 05:09):

Tim Uckun said:

Having said all that I wasn't an expert at Erlang having just dabbled in it for fun and of course nobody else in the company knew erlang and I had no idea where I would hire erlang programmers from.

This is probably the most important factor in stack choice, and overlooked because it's social and not technical

Joe (Apr 15 2025 at 01:20):

RE: naming of “durable functions” from the end of the episode.

What about Durable Executions, DEX for short? Has a nice ring :smile:

Tim Uckun (Apr 15 2025 at 22:02):

I think the product should be named "function orchestration" which is what it really is. Tagline "kubernetes for your functions"

Ron Waldon-Howe (Apr 16 2025 at 00:25):

Hehe, when teaching PaaS to UI folks, I often say "kubernetes is React for compute/network resources"

Tim Uckun (Apr 16 2025 at 22:22):

Make a backronym for FORT Function Orchestration (for) Resilient (Restartable?) Transactions

Andrew O'Brien (Apr 30 2025 at 13:52):

Ron Waldon-Howe said:

There was an Oxide and Friends episode on distributed sagas that's sort of related: https://oxide-and-friends.transistor.fm/episodes/the-saga-of-sagas

That whole episode I was just waiting for someone to bring up the comparison.

Last updated: Jun 28 2025 at 12:32 UTC