Workers Durable Objects Beta: A New Approach to Stateful Serverless • Hacker News Board

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

#51

Post by rektide » Mon, Sep 28, 2020, 5:28 PM UTC

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…

It sounds fairly Actor-like to me. There's a bunch of different entities, each is a singular entity that lives somewhere & has it's own state that only it can directly access. These Actors happens to be mobile in Durable Objects. And they are presented more object-like than actor-like, but that seems like a different in name more than difference in nature to me.

Edit: oh, here's @kentonv, capnproto author & cloudflare employee, elsewhere in this discussion:

> Each object is essentially an Actor in the Actor Model sense. It can send messages (fetches, and responses to fetches) to other objects and regular workers. Incoming requests are not blocked while waiting for previous events to complete.

https://news.ycombinator.com/item?id=24617172

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

#52

Post by kentonv » Mon, Sep 28, 2020, 5:32 PM UTC

catern wrote: post #24

Wow, very cool! I didn't see the string "mobile code" in this press release, but that's essentially what this is, right? Automatically moving objects to be near the computation that needs it, is a long-standing dream. It's awesome to see that Cloudflare is giving it a try! Plus, the persistence is clever - I'm guessing that makes the semantics of mobility much easier to deal with. I love the migration to nearby edge…

> Have you given any thought to automatically migrating Durable Objects to end user devices?

We don't have any current plans, but... I was the co-founder of Sandstorm.io before going to Cloudflare, and Durable Objects are very much inspired by parts of Sandstorm's design. So yeah, I've absolutely thought about it. ;)

It would definitely have to be an opt-in thing on the developer's part, due to the security considerations as you mention. But I think the possibilities for solving tricky compliance problems are pretty interesting.

Protip: "Compliance" is how you say "privacy" while sounding like a shrewd business person instead of an activist. ;)

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

#53

Post by kentonv » Mon, Sep 28, 2020, 5:45 PM UTC

toddh wrote: post #48

kentonv wrote: post #42

Earlier quoted context omitted.

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?

No, no GC, at least at present. If you store any durable state, you have to delete it explicitly, or it stays forever.

I am interested in the idea of objects whose IDs are never revealed to the app, but to which references can be stored inside other objects. Then we could do GC... and it would be a true capability system.

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

#54

Post by cgillum » Mon, Sep 28, 2020, 5:45 PM UTC

kentonv wrote: post #28

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.

Possibly. We did not base the design (or name) of Durable Objects on any other product we were aware of (except arguably Sandstorm.io, which was my startup before joining Cloudflare). I haven't looked closely at Azure Durable Functions. We actually did call this product "Actors" internally for a long time, but we found that people who had done previous Actor Model work (e.g. in Erlang) ended up more confused than enl…

Interestingly, Azure's Durable Entities has a similar feature set and similar story of origin (internally called it actors, then switched to "entities" to avoid confusion): https://medium.com/@cgillum/azure-functions-durable-entities...

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

#55

Post by treis » Mon, Sep 28, 2020, 6:20 PM UTC

catern wrote: post #24

Wow, very cool! I didn't see the string "mobile code" in this press release, but that's essentially what this is, right? Automatically moving objects to be near the computation that needs it, is a long-standing dream. It's awesome to see that Cloudflare is giving it a try! Plus, the persistence is clever - I'm guessing that makes the semantics of mobility much easier to deal with. I love the migration to nearby edge…

>Automatically moving objects to be near the computation that needs it, is a long-standing dream. It's awesome to see that Cloudflare is giving it a try!

I'm not sure I see many real world applications for this. It seems to sit in the unhappy middle ground between local device storage and central storage. Local storage is the best performance because you eliminate network issues but then you have to deal with sync/consistency issues. Central storage & processing eliminates sync/consistency issues but can have poor performance due to network. Worker Durable Objects sits in the middle. You trade consistency complications for performance but instead of eliminating the network you're shaving some tens of miliseconds off the RTT. It's a level of performance improvement that essentially no one will notice.

To use their examples:

>Shopping cart: An online storefront could track a user's shopping cart in an object. The rest of the storefront could be served as a fully static web site. Cloudflare will automatically host the cart object close to the end user, minimizing latency.

>Game server: A multiplayer game could track the state of a match in an object, hosted on the edge close to the players.

>IoT coordination: Devices within a family's house could coordinate through an object, avoiding the need to talk to distant servers.

>Social feeds: Each user could have a Durable Object that aggregates their subscriptions.

>Comment/chat widgets: A web site that is otherwise static content can add a comment widget or even a live chat widget on individual articles. Each article would use a separate Durable Object to coordinate. This way the origin server can focus on static content only.

The performance benefits for the cart, social feed, and chat are irrelevant. Nobody cares if it takes 50 ms longer for any of those things.

IoT coordination is more promising because you want things to happen instantly. Maybe it's worth it here, but people usually have a device on their local network to coordinate these things.

Game server would definitely be an improvement. But these things are more complex than some JS functions and it would be a large effort to make them work with Durable Objects.

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

#56

Post by eastdakota » Mon, Sep 28, 2020, 6:33 PM UTC

treis wrote: post #55

catern wrote: post #24

Wow, very cool! I didn't see the string "mobile code" in this press release, but that's essentially what this is, right? Automatically moving objects to be near the computation that needs it, is a long-standing dream. It's awesome to see that Cloudflare is giving it a try! Plus, the persistence is clever - I'm guessing that makes the semantics of mobility much easier to deal with. I love the migration to nearby edge…

>Automatically moving objects to be near the computation that needs it, is a long-standing dream. It's awesome to see that Cloudflare is giving it a try! I'm not sure I see many real world applications for this. It seems to sit in the unhappy middle ground between local device storage and central storage. Local storage is the best performance because you eliminate network issues but then you have to deal with sync/co…

Regulatory compliance is the killer feature.

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

#57

Post by eastdakota » Mon, Sep 28, 2020, 6:36 PM UTC

kentonv wrote: post #40

pier25 wrote: post #29

If I'm getting this right, it's essentially immediately consistent distributed state for workers. They could have called it simply "Workers State" :) Now in all seriousness, this is super impressive. Congrats to the CF team!

Heh, that is actually a name we considered, and as a name on its own, I like it a lot. But we also needed a name for the individual instances. We also found that the people who "got" the product were the ones who thought of it in terms of object-oriented programming (an object is an instance of a class). So we ended up gravitated towards "objects". But I dunno, naming is hard. "Workers State" may in fact have been a…

Definitely the hardest product to name I can remember.

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

#58

Post by treis » Mon, Sep 28, 2020, 7:11 PM UTC

eastdakota wrote: post #56

treis wrote: post #55

Earlier quoted context omitted.

>Automatically moving objects to be near the computation that needs it, is a long-standing dream. It's awesome to see that Cloudflare is giving it a try! I'm not sure I see many real world applications for this. It seems to sit in the unhappy middle ground between local device storage and central storage. Local storage is the best performance because you eliminate network issues but then you have to deal with sync/co…

Regulatory compliance is the killer feature.

Maybe, but not as they are. If I understand it correctly there's no limits by geography. If the Durable Object is created in country A when a worker from Country B accesses it then that data will be replicated to the worker in Country B.

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

#59

Post by catern » Mon, Sep 28, 2020, 7:23 PM UTC

treis wrote: post #55

catern wrote: post #24

Wow, very cool! I didn't see the string "mobile code" in this press release, but that's essentially what this is, right? Automatically moving objects to be near the computation that needs it, is a long-standing dream. It's awesome to see that Cloudflare is giving it a try! Plus, the persistence is clever - I'm guessing that makes the semantics of mobility much easier to deal with. I love the migration to nearby edge…

>Automatically moving objects to be near the computation that needs it, is a long-standing dream. It's awesome to see that Cloudflare is giving it a try! I'm not sure I see many real world applications for this. It seems to sit in the unhappy middle ground between local device storage and central storage. Local storage is the best performance because you eliminate network issues but then you have to deal with sync/co…

>It seems to sit in the unhappy middle ground between local device storage and central storage.

No, it's strictly better than both. You get the performance of local storage and the ease of programming of central storage.

Pretty much everyone chooses central storage at the moment, so the advantage of mobile objects manifests as performance.

I don't know about you, but I would find it a much nicer experience if when I clicked "Add Item" in a shopping cart on some website, it happened <5ms regardless of the quality of my network connection, while still being shared between different machines and never encountering consistency issues. The current "wait somewhere from half a second to several seconds for each click" is bad UX, even if users have gotten used to it.

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

#60

Post by ocdtrekkie » Mon, Sep 28, 2020, 7:23 PM UTC

phn wrote: post #27

kentonv wrote: post #5

Earlier quoted context omitted.

For those in the beta, it's currently free. We are still working out what pricing will look like post-beta. We realized we need to see how people actually use it and get some feedback before we could settle on the right pricing structure... that's what betas are for.

Thank you for answering. In retrospect my comment looks a bit dry in comparison with the monumental achievement so: Congrats on launching! It's awesome to see Cap'n Proto and sandstorm's legacy living on :)

FWIW, as a community project, Sandstorm also continues to live on! ;) There's been some pretty substantial refactorings going on and a bunch of quality of life fixes, sometimes closing out 5+ year old feature requests.