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

Workers Durable Objects Beta: A New Approach to Stateful Serverless

blog.cloudflare.com

Post reply on HN
Print view View original

41–50 of 98 posts

Re: Workers Durable Objects Beta: A New Approach to Stateful Serverless

#41

Post by reubenbond »

kentonv wrote: post #21
ramchip wrote: post #18

> I'm going to be honest: naming this product was hard, because it's not quite like any other cloud technology that is widely-used today. Perhaps I'm missing something important, but isn't this quite similar to Orleans grains and other distributed actors?

"Actors" was actually one of the names we used internally for a long time (it's still all over the code), but eventually decided against because we found that people familiar with the Actor Model actually expected something a bit different, so it confused them. But yes, the basic idea is not entirely new. For me, Durable Objects derive from my previous work on Sandstorm.io, which in turn really derives from past work…

We (Orleans team) also stopped referring to them as actors some time ago for the same reason. The Orleans papers call them Virtual Actors or Grains. Usually, I describe grains as Distributed Objects.

Re: Workers Durable Objects Beta: A New Approach to Stateful Serverless

#42

Post by kentonv »

toddh wrote: post #32
kentonv wrote: post #26

Earlier quoted context omitted.

Great questions. > how security works? Messages can only be sent to Durable Objects from other Workers. To send a message, you must configure the sending Worker with a "Durable Object Namespace Binding". Currently, we only permit workers on the same account to bind to a namespace. Without the binding, there's no way to talk to Durable Objects in that namespace. > Is there backpressure on message senders? Currently, t…

> Can passivation warmth be controlled? A variant of the cold start problem. How long after all the messages for an object drain is it passivated? Can you keep it pinned in memory? Another question. Can objects contain relationships that are themselves references to other Durable Objects? Say a simple reference, or a list, or DAGs?

The system will evict the live object when it has been idle for some period. If there are connections still open to the object, it won't be evicted (unless it exceeds resource limits, etc.).

As always, "cold starts" with Workers are very fast, usually imperceptible to a human. Also, multiple objects may be hosted in the same isolate; when instantiating in an existing isolate, the only "cold start" overhead is whatever you write in your class constructor.

> Can objects contain relationships that are themselves references to other Durable Objects?

Yes, by storing the object IDs.

Re: Workers Durable Objects Beta: A New Approach to Stateful Serverless

#43

Post by ShockaZ »

vyrotek wrote: post #23

Is this similar to Azure Durable Functions? https://docs.microsoft.com/en-us/azure/azure-functions/durab... From what I understand these features are a nice way to implement a serverless Actor Model. I was surprised to see no reference to it on the CloudFlare page.

I was thinking this is a lot more like Microsoft Orleans:

https://dotnet.github.io/orleans/Documentation/index.html

Re: Workers Durable Objects Beta: A New Approach to Stateful Serverless

#44

Post by kentonv »

reubenbond wrote: post #41
kentonv wrote: post #21

Earlier quoted context omitted.

"Actors" was actually one of the names we used internally for a long time (it's still all over the code), but eventually decided against because we found that people familiar with the Actor Model actually expected something a bit different, so it confused them. But yes, the basic idea is not entirely new. For me, Durable Objects derive from my previous work on Sandstorm.io, which in turn really derives from past work…

We (Orleans team) also stopped referring to them as actors some time ago for the same reason. The Orleans papers call them Virtual Actors or Grains. Usually, I describe grains as Distributed Objects.

Hah, "Grains" is also what we called them in Sandstorm.io.

Re: Workers Durable Objects Beta: A New Approach to Stateful Serverless

#45

Post by Serow225 »

ShockaZ wrote: post #43
vyrotek wrote: post #23

Is this similar to Azure Durable Functions? https://docs.microsoft.com/en-us/azure/azure-functions/durab... From what I understand these features are a nice way to implement a serverless Actor Model. I was surprised to see no reference to it on the CloudFlare page.

I was thinking this is a lot more like Microsoft Orleans: https://dotnet.github.io/orleans/Documentation/index.html

very close to Azure Functions Durable Entities: https://docs.microsoft.com/en-us/azure/azure-functions/durab...

Re: Workers Durable Objects Beta: A New Approach to Stateful Serverless

#46

Post by gavinray »

jacques_chester wrote: post #37

> I'm going to be honest: naming this product was hard, because it's not quite like any other cloud technology that is widely-used today. On a superficial skim it looks like a tuple space; they were heavily researched in the 80s and 90s. JavaSpaces emerged in the late 90s but never took off. Scala folks are keen on Actor models (Lightbend have been using the term "Stateful Serverless" for a while now), as are Erlang…

I have been trying to remember the world "tuple space" for several months, after running across it once and then trying to describe it to a friend.

Thank you, it was bugging me so much.

Re: Workers Durable Objects Beta: A New Approach to Stateful Serverless

#48

Post by toddh »

kentonv wrote: post #42
toddh wrote: post #32

Earlier quoted context omitted.

> Can passivation warmth be controlled? A variant of the cold start problem. How long after all the messages for an object drain is it passivated? Can you keep it pinned in memory? Another question. Can objects contain relationships that are themselves references to other Durable Objects? Say a simple reference, or a list, or DAGs?

The system will evict the live object when it has been idle for some period. If there are connections still open to the object, it won't be evicted (unless it exceeds resource limits, etc.). As always, "cold starts" with Workers are very fast, usually imperceptible to a human. Also, multiple objects may be hosted in the same isolate; when instantiating in an existing isolate, the only "cold start" overhead is whateve…

Are they garbage collected? Do you use tombstones?

Re: Workers Durable Objects Beta: A New Approach to Stateful Serverless

#49

Post by greg-m »

asdev wrote: post #47

are updates to durable objects guaranteed to be exactly once?if an update is sent but the connection between client and object are dropped, how is that handled?

Yes, updates are guaranteed to happen exactly once or not at all.

If the connection drops, the Worker will receive an error and can re-establish its connection to the Durable Object. The update may or may not have been successfully persisted by the Durable Object - just like any other remote database operation where the connection drops before you receive the result back.

Re: Workers Durable Objects Beta: A New Approach to Stateful Serverless

#50

Post by eloff »

_ahs0 wrote: post #3

Demo chat application from the article using Durable Objects: - https://edge-chat-demo.cloudflareworkers.com - A Public Room (to joint test): hackernews - Source: https://github.com/cloudflare/workers-chat-demo Insanely awesome feature add (much needed for truly “serverless” application development). The power to scale here without insane infrastructure headache is amazing. One day some kid is totally going to build…

That already happened, see plentyoffish.com, created by Markus Frind in Vancouver, the first (or first popular anyway) free online dating website. Sold for $575M. No outside funding, and for a long time it was just him and his girlfriend running it, working about 10 hours a week. When he sold it to match.com, they had 75 employees and he was working normal hours.
Post reply on HN