sewen

7 ms·

1.
by sewen 11d ago
Hmmm, that feels not very nice, tbh. I have big respect for what Maxim and the team built, and both systems are essentially open and free (publish code and are free to use).
2.
by sewen 12d ago
Sorry, but this is incorrect (Restate founder here) (1) You can model the equivalent of local activities and activities that run on other workers in Restate. A local activity is a step in the workflow function. An activity supposed to run o
3.
by sewen 12d ago
That's fair, but they are also a great fit for Restate. For example, Replit migrated their whole coding agent from Temporal over to Restate, a pretty big setup.
4.
by sewen 12d ago
I guess the confusion is that it doesn't have to be one single persistent stream. While the durable function does fast work and adds steps, it pushes it through a stream. When a wait point comes, it closes and replays on resumption (ty
5.
by sewen 11mo ago
We tried building a scalable and resilient cloud coding agent with @restatedev for workflows, @modal for sandboxes, @vercel for compute, and GPT-5 / Claude as the LLM. Think a mini version of cursor background agents or Lovable, with a
6.
by sewen 1y ago
I just realized I missed an important part: The primary durability for the bulk of the state comes from S3 (or similar object store). The periodic snapshots give you like an automatic frequent backup mechanism for free, which in itself is a
7.
by sewen 1y ago
Indeed, the persistence layer is sensitive, and we do take this pretty serious. All data is persisted via RocksDB. Not only the materialized state of invocations and journals, but even the log itself uses RocksDB as the storage layer for se
8.
by sewen 1y ago
afaik, with Temporal you deploy workers. When a workflow calls an activity, the activity gets added to a queue, and the workers pull activities from queues. In Restate, there are no workers like that. The durable functions (which contain th
9.
by sewen 1y ago
Here is a comparison to Temporal, maybe that helps with a comparison to those systems as well? https://news.ycombinator.com/item?id=43511814
10.
by sewen 1y ago
There are a few dimensions where this is different. (1) The design is a fully self-contained stack, event-driven, with its own replicated log and embedded storage engine. That lets it ship as a single binary that you can use without depende
11.
by sewen 1y ago
The way we think about durable execution is that it is not just for long-running code, where you may want to suspend and later resume. In those cases, low-latency implementations would not matter, agreed. But durable execution is immensely
12.
by sewen 1y ago
All of the Restate co-founders com from various stages of Apache Flink. Restate is in many ways a mirror image to Flink. Both are event-streaming architectures, but otherwise make a lot of contrary design choices. (This is not really helpfu
13.
by sewen 1y ago
Thank you for the kind words! The storage engine is pretty tightly integrated with the log, but the programming model allows you to attach quasi arbitrary state to keys. So see whether this fits your use case, would be great to better under
14.
The Anatomy of a Durable Execution Stack from First Principles(restate.dev)
22 points by sewen 2y ago|8 comments
15.
by sewen 2y ago
The post discusses the design considerations when building a durable execution runtime from the ground up. The goal is a highly-available, transactional, scalable, and low latency runtime in a self-contained binary that scales from laptop t
16.
by sewen 2y ago
Yes, there is one, have a look at https://restate.dev/cloud/
17.
by sewen 2y ago
This is certainly building on principles and ideas from a long history of computer science research. And yes, there are moment where you go "oh, we implicitly gave up xyz (i.e., causal order across steps) when we started adopting archi
18.
by sewen 2y ago
Great question: The Virtual Objects in Restate are much like actors. They are somewhat inspired by Orleans [1], and you could call them virtual stateful actors. They blend with the durable execution for processing messages with multiple dur
19.
by sewen 2y ago
Temporal is related, but I would say it is a subset of this. If you only consider appending results of steps of a handler, then you have something like Temporal. This here uses the log also for RPC between services, for state that outlives
20.
by sewen 2y ago
You can catch these errors and handle them in a common try/catch manner, and because the results of `ctx.run` are recorded in the log, this is deterministic and reliable
21.
by sewen 2y ago
I can see where some of that could be written more clearly. To elaborate: - We mean using one log across different concerns like state a, communication with b, lock c. Often that is in the scope of a single entity (payment, user, session, e
22.
by sewen 2y ago
Some clarification on what "one log" means here: - It means using one log across different concerns like state a, communication with b, lock c. Often that is in the scope of a single entity (payment, user, session, etc.) and thus
23.
by sewen 2y ago
Yes, we are assuming a log that picks linearizability at the cost of availability under partitions. Like most logs do, including Kafka, Pulsar, RedPanda, etc. The application state is defined by the log here, and the log drives retries&#x2F
24.
by sewen 2y ago
Yes, exactly right. One log per logical entity, here "payment ID". The way our open source project implements that is with a partitioned log and indexes at key-granularity, so it is like virtually a log per key.
25.
by sewen 2y ago
There is nothing to coordinate for the application, because, yes, the log coordinates everything. But not globally, on the level of a single event handler execution, or a single key. That has been proven to scale well - the way we implement
26.
by sewen 2y ago
[2] https://martin.kleppmann.com/2015/11/05/database-inside-out-...
27.
by sewen 2y ago
That blog post is a great read as well. Truely, the log abstraction [1] and "Turning the DB inside out" [2] have been hugely influential. In a way this article here suggests to extend that (1) from a log that represents data (upse
28.
by sewen 2y ago
I assume CSP is communicating sequential processes? Interesting analogy - in a way it is doing something CSP-like in a distributed app/service architecture with the all the different processes and components that are there. The shared
29.
by sewen 2y ago
That gist is correct - I would add that the log needs a few specific properties and conceptually be the shared log for state, communication, execution scheduling. The next step is the, how do you make this usable in practice...
30.
by sewen 2y ago
Haha, no, but maybe all the AI-generated contents out there is starting to train me to write in a similar style...

More ›