Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Restate – Low-latency durable workflows for JavaScript/Java, in Rust

restate.dev

Post reply on HN
Print view View original

31–40 of 112 posts

Re: Show HN: Restate – Low-latency durable workflows for JavaScript/Java, in Rust

#31

Post by p10jkle »

delusional wrote: post #28
yaj54 wrote: post #21

how do tools like this handle evolving workflows? e.g., if I have a "durable worklflow" that sleeps for a month and then performs its next actions, what do I do if I need to change the workflow during that month? I really like the concept but this seems like an issue for anything except fairly short workflows. If I keep my data and algorithms separate I can modify my event handling code while workflows are "active."

Conceptually I think the only thing these tools add on to the mental model of separation of data and logic is that they also store the name of next routine to call. The name is late bond, so migration would amount to switching out the implementation of that procedure.

not necessarily - we store the intermediary states of your handler, so it can be replayed on infrastructure failures. if the handler changes in what it does, those intermediary states (the 'journal') might no longer match this. the best solution is to route replayed requests to the version of the code that originally executed the request, but: 1. many infra platforms dont allow you to execute previous versions 2. after some duration (maybe just minutes), executing old code is dangerous, eg because of insecure dependencies.

Re: Show HN: Restate – Low-latency durable workflows for JavaScript/Java, in Rust

#32

Post by delusional »

p10jkle wrote: post #25
yaj54 wrote: post #21

how do tools like this handle evolving workflows? e.g., if I have a "durable worklflow" that sleeps for a month and then performs its next actions, what do I do if I need to change the workflow during that month? I really like the concept but this seems like an issue for anything except fairly short workflows. If I keep my data and algorithms separate I can modify my event handling code while workflows are "active."

I wrote two blog posts on this! It's a really hard problem https://restate.dev/blog/solving-durable-executions-immutabi... https://restate.dev/blog/code-that-sleeps-for-a-month/ The key takeaways: 1. Immutable code platforms (like Lambda) make things much more tractable - old code being executable for 'as long as your handlers run' is the property you need. This can also be achieved in Kubernetes with some clever con…

> Immutable code platforms (like Lambda) make things much more tractable

My job is admittedly very old-school, but is that actually doable? I dont think my stakeholders would accept a version of "well we can't fix this bug for our current customers, but the new ones wont have it". That just seems like a chaos nobody wants to deal with.

Re: Show HN: Restate – Low-latency durable workflows for JavaScript/Java, in Rust

#33

Post by pavel_pt »

delusional wrote: post #28
yaj54 wrote: post #21

how do tools like this handle evolving workflows? e.g., if I have a "durable worklflow" that sleeps for a month and then performs its next actions, what do I do if I need to change the workflow during that month? I really like the concept but this seems like an issue for anything except fairly short workflows. If I keep my data and algorithms separate I can modify my event handling code while workflows are "active."

Conceptually I think the only thing these tools add on to the mental model of separation of data and logic is that they also store the name of next routine to call. The name is late bond, so migration would amount to switching out the implementation of that procedure.

Restate also stores a deployment version along with other invocation metadata. FaaS platforms like AWS Lambda make it very easy to retain old versions of your code, and Restate will complete a started invocation with the handlers that it started with. This way, you can "drain" older executions while new incoming requests are routed to the latest version.

You still have to ensure that all versions of handler code that may potentially be activated are fully compatible with all persisted state they may be expected to access, but that's not much different from handling rolling deployments in a large system.

Re: Show HN: Restate – Low-latency durable workflows for JavaScript/Java, in Rust

#34

Post by p10jkle »

rubyfan wrote: post #29

There’s a lot of jargon in this, is there a lay person explanation of what problem this solves?

Our goal is to make it easier to write code that handles failures - failed outbound api calls, infrastructure issues like a host dying, problems talking between services. The primitive we offer is that we guarantee that your handlers always run to completion (whether to a result or a terminal error)

The way we do that is by writing down what your code is doing, while its doing it, to a store. Then, on any failure, we re-execute your code, fill in any previously stored results, so that it can 'zoom' back to the point where it failed, and continue. It's like a much more efficient and intelligent retry, where the code doesn't have to be idempotent.

Re: Show HN: Restate – Low-latency durable workflows for JavaScript/Java, in Rust

#35

Post by delusional »

p10jkle wrote: post #31
delusional wrote: post #28

Earlier quoted context omitted.

Conceptually I think the only thing these tools add on to the mental model of separation of data and logic is that they also store the name of next routine to call. The name is late bond, so migration would amount to switching out the implementation of that procedure.

not necessarily - we store the intermediary states of your handler, so it can be replayed on infrastructure failures. if the handler changes in what it does, those intermediary states (the 'journal') might no longer match this. the best solution is to route replayed requests to the version of the code that originally executed the request, but: 1. many infra platforms dont allow you to execute previous versions 2. aft…

I was of course just thinking about the "front" of the execution, when you're sleeping for 2 days and you want to switch out a future step. Switching out logic that has already been committed is a harder problem. That's a goo point.

> after some duration (maybe just minutes), executing old code is dangerous, eg because of insecure dependencies.

Could you elaborate on that? My understanding is that all of this tech builds on actions being retried in an "eventually consistent" manner. That would seem to clash with this argument.

Re: Show HN: Restate – Low-latency durable workflows for JavaScript/Java, in Rust

#36

Post by sewen »

A few links worth sharing here:

- Blog post with an overview of Restate 1.0: https://restate.dev/blog/announcing-restate-1.0-restate-clou...

- Restate docs: https://docs.restate.dev/

- Discord, for anyone who wants to chat interactively: https://discord.com/invite/skW3AZ6uGd

Re: Show HN: Restate – Low-latency durable workflows for JavaScript/Java, in Rust

#37

Post by fire_lake »

p10jkle wrote: post #34
rubyfan wrote: post #29

There’s a lot of jargon in this, is there a lay person explanation of what problem this solves?

Our goal is to make it easier to write code that handles failures - failed outbound api calls, infrastructure issues like a host dying, problems talking between services. The primitive we offer is that we guarantee that your handlers always run to completion (whether to a result or a terminal error) The way we do that is by writing down what your code is doing, while its doing it, to a store. Then, on any failure, we…

This assumes that the APIs work this way?

What if the first call is to get a resource that expires and then the last call fails?

Now it will retry but with an expired resource (first call is saved).

Re: Show HN: Restate – Low-latency durable workflows for JavaScript/Java, in Rust

#38

Post by p10jkle »

delusional wrote: post #32
p10jkle wrote: post #25

Earlier quoted context omitted.

I wrote two blog posts on this! It's a really hard problem https://restate.dev/blog/solving-durable-executions-immutabi... https://restate.dev/blog/code-that-sleeps-for-a-month/ The key takeaways: 1. Immutable code platforms (like Lambda) make things much more tractable - old code being executable for 'as long as your handlers run' is the property you need. This can also be achieved in Kubernetes with some clever con…

> Immutable code platforms (like Lambda) make things much more tractable My job is admittedly very old-school, but is that actually doable? I dont think my stakeholders would accept a version of "well we can't fix this bug for our current customers, but the new ones wont have it". That just seems like a chaos nobody wants to deal with.

I don't personally believe this immutability property should be used for handlers that run for more than say 5 minutes. Any longer than that, I'd suggest the use of delayed calls, which explicitly will serialise the handler arguments instead of saving the whole journal. I agree executing code that is even just an hour old is unacceptable in almost all cases.

Obviously you can still sleep for a month, but I really see no way to make such a handler safely updatable without editing the code to branch on versions, which can become a mess really quick (but good for getting out of a jam!)

Re: Show HN: Restate – Low-latency durable workflows for JavaScript/Java, in Rust

#39

Post by corytheboyd »

p10jkle wrote: post #34
rubyfan wrote: post #29

There’s a lot of jargon in this, is there a lay person explanation of what problem this solves?

Our goal is to make it easier to write code that handles failures - failed outbound api calls, infrastructure issues like a host dying, problems talking between services. The primitive we offer is that we guarantee that your handlers always run to completion (whether to a result or a terminal error) The way we do that is by writing down what your code is doing, while its doing it, to a store. Then, on any failure, we…

What if the code was changed by the time it is retried? I imagine it would have to throw away its memorized instructions, and because the code isn’t idempotent…

Re: Show HN: Restate – Low-latency durable workflows for JavaScript/Java, in Rust

#40

Post by p10jkle »

delusional wrote: post #35
p10jkle wrote: post #31

Earlier quoted context omitted.

not necessarily - we store the intermediary states of your handler, so it can be replayed on infrastructure failures. if the handler changes in what it does, those intermediary states (the 'journal') might no longer match this. the best solution is to route replayed requests to the version of the code that originally executed the request, but: 1. many infra platforms dont allow you to execute previous versions 2. aft…

I was of course just thinking about the "front" of the execution, when you're sleeping for 2 days and you want to switch out a future step. Switching out logic that has already been committed is a harder problem. That's a goo point. > after some duration (maybe just minutes), executing old code is dangerous, eg because of insecure dependencies. Could you elaborate on that? My understanding is that all of this tech bu…

> Could you elaborate on that?

What I mean is that executing a software artifact from, lets say, a month ago, just to get month-old business logic, is extremely dangerous because of non-business-logic elements. Maybe it uses the old DB connection string, or a library with a CVE. Its a 'hack' to address old code versions in order to get the business logic that a request originally executed on - a hack that I feel should be used for minutes, not eve hours.

Post reply on HN