sewen

7 ms·

1.
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
2.
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
3.
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
4.
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
5.
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
6.
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
7.
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
8.
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
9.
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
10.
The Anatomy of a Durable Execution Stack from First Principles(restate.dev)
22 points by sewen 2y ago|8 comments
11.
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
12.
by sewen 2y ago
Yes, there is one, have a look at https://restate.dev/cloud/
13.
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
14.
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
15.
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
16.
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
17.
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
18.
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
19.
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
20.
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.
21.
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
22.
by sewen 2y ago
[2] https://martin.kleppmann.com/2015/11/05/database-inside-out-...
23.
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
24.
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
25.
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...
26.
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...
27.
by sewen 2y ago
Never encountered it before, but it looks cool. I think they are trying to solve a related problem. "We can consolidate the work by making a generic log that has networking and syncing built-in. This can be used by developers to make a
28.
by sewen 2y ago
Nice question! Restate is not a log that retains the raw events for a long time - conceptually just until they where processed by the handlers, DB, locking, etc. When you build stateful handlers, the state per key is in the internal DB, and
29.
Every System is a Log: Avoiding coordination in distributed applications(restate.dev)
229 points by sewen 2y ago|155 comments
30.
by sewen 2y ago
A short summary: Complex distributed coordination and orchestration is at the root of what makes many apps brittle and prone to inconsistencies. But we can mitigate much of complexity with a neat trick, building on the fact that every syste

More ›