Live data from Hacker News

Workers Durable Objects Beta: A New Approach to Stateful Serverless

blog.cloudflare.com

61–70 of 98 posts

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

#61
post #40
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…

From a pragmatic point of view the idea seems to be allowing stateful workers. Objects seems more like an implementation detail.

Anyway, thanks again for working on this. I'm sure I'm going to use those once they come out of beta!

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

#62
post #58

Earlier quoted context omitted.

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.

No, that's not correct. The worker in country B will end up sending a message to the Durable Object which will still be located in Country A. An object only exists in one place at a time.

We are working on automatic migration, where if we noticed the object was more-frequently accessed in country B than in country A, then it gets moved to country B. But, that's a performance optimization, and it will be straightforward to implement policies on top of that to restrict certain objects to migrate only within certain political regions.

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

#63
post #59
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…

>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…

[deleted]

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

#64
post #59
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…

>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…

>You get the performance of local storage

Durable workers are still a network call over the internet. That is orders of magnitudes slower than using local storage in the browser.

>when I clicked "Add Item" in a shopping cart on some website, it happened You're not going to get that level of performance. All edge storage does is saves you the time it takes a packet to go from the edge to the server. For example, I'm in Atlanta and the Hacker news server is in San Diego. This is my traceroute:

1 LEDE.lan (192.168.1.1) 12.652 ms 12.596 ms 12.561 ms

2 96.120.5.9 (96.120.5.9) 32.606 ms 32.604 ms 32.581 ms

3 68.85.68.85 (68.85.68.85) 34.831 ms 34.821 ms 34.792 ms

4 96.108.116.41 (96.108.116.41) 34.762 ms 34.730 ms 34.706 ms

5 ae-9.edge4.Atlanta2.Level3.net (4.68.38.113) 39.613 ms 64.603 ms 57.149 ms

6 ae-0-11.bar1.SanDiego1.Level3.net (4.69.146.65) 89.310 ms 66.298 ms 76.021 ms

7 M5-HOSTING.bar1.SanDiego1.Level3.net (4.16.110.170) 75.982 ms 69.094 ms 79.199 ms

The last hop in Atlanta before hitting the backbone has a round trip time of ~35ms and the first in San Diego is ~75ms. So everything else equal, if HN was served from a edge location I'd save 40ms on a page load. Ultimately 40 ms doesn't matter because it's not something that the end user can perceive.

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

#65
post #55
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…

> 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.

I think this is missing a few points:

1. Yeah they do. If your shopping cart responds 50ms faster when someone clicks "add to cart", you will see a measurable benefit in revenue.

2. It's actually a lot more than 50ms. A chat app built on a traditional database -- in which a message arriving from one user is stored to the database, and other users have to poll for that message -- will have, at best, seconds of latency, and even that comes at great expense (from polling). The benefit from Durable Objects is not just being at the edge but also being a live coordination point at which messages can be rebroadcast without going through a storage layer.

3. Yes, some databases have built-in pub/sub that avoids this problem and may even be reasonably fast, but using Durable Objects is actually much easier and more flexible than using those databases.

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

#66
post #64
post #59

Earlier quoted context omitted.

>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…

>You get the performance of local storage Durable workers are still a network call over the internet. That is orders of magnitudes slower than using local storage in the browser. >when I clicked "Add Item" in a shopping cart on some website, it happened You're not going to get that level of performance. All edge storage does is saves you the time it takes a packet to go from the edge to the server. For example, I'm i…

> Durable workers are still a network call over the internet.

Getting the request to the object involves traversing the internet. Once there, actually talking to storage is extremely fast compared to classical monolithic databases. The key is that application code gets to run directly at the storage location.

Most applications need to do multiple round trips to storage to serve any particular request, which is where the costs add up.

> Ultimately 40 ms doesn't matter because it's not something that the end user can perceive.

In ~2005 when I started at Google, I learned that they had done a study that found that every millisecond of latency shaved off the time it took to serve search results would add $1M in annual revenue.

Users may not perceive 40ms in isolation, but they do perceive a web site "feeling" slower if every request takes 40ms longer.

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

#69
post #68

What is the size limits for a durable object? The read/write limit per second? That usually the first things I want to know about my cloud primitives... (Credits for at-least being clear about consistency which is always my very first question)

Well, this is kind of like asking the throughput of an individual Worker instance. It doesn't really matter, because the system automatically spins up as many as you need, and so the overall throughput is effectively unlimited.

For Durable Objects, applications should aim to make their objects as fine-grained as they reasonably can, so that the limits on one object are not likely to matter. Meanwhile, the total capacity across all objects is effectively unlimited.

Anyway, we don't have numbers for these questions yet. This is an early beta and we still have a lot of low-hanging fruit optimization to do.

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

#70
post #22
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…

*or her’s

Thank you for policing other's language. Wouldn't want to stifle discussion with a micro aggression.
Post reply on HN