[realmod]

What a great write up! Looks very promising. Right now, I'm wondering how everything will be priced, especially, the compute-time. Because if the price is low, you would be able to replace a lot of complicated servers with easier and more scalable workers.

According to [0], they will - obviously - charge for both compute-time and storage operations, and with the price of storage operations expected to be around Workers KV. Assuming that compute-time is charged at minimum at-or-higher than Workers Unbound, using workers for chat-rooms and other WebSocket stuff would be unfeasible. Workers Unbound costs $12.50 per MM-GB-sec - given that the server is 128 MB (the current fixed memory size) - the price per-worker-second would be at least $0.0000016 per connected-worker. It could get expensive fast.

[0] https://news.ycombinator.com/item?id=24616775

[kentonv]

We're definitely going to figure out some sort of pricing for WebSockets that doesn't charge full price for idle time, but we haven't nailed it down yet.

[a_imho]

It could get expensive fast.

Also with paid Workers and no stop loss what happens if someone decide to ddos your app? I searched for this and come away with no clear answers.

Also wondering where will Worker KV fit in? From what I gather Durable Objects are strictly superior if pricing will be comparable.

[kentonv]

Workers KV is still better in many use cases. Durable Objects are the right choice when you need strong consistency. KV is the right choice when you want world-wide low latency access to the same data. Note that these two advantages are fundamentally opposed; it is physically impossible to simultaneously have strong consistency and worldwide low-latency access to a single piece of data. So, this will always be a trade-off.

Note that you could build KV on top of Durable Objects, by implementing your own caching and replication in application logic running in Durable Objects. On the other hand, you can't implement Durable Objects on top of KV; once you've lost strong consistency, it's hard (impossible?) to get it back. So in that sense, Durable Objects are "strictly superior". But in a practical sense, you probably don't really want to do the work to implement your own KV store on top of Durable Objects; it's probably better to just use KV.

[Scarbutt]

What's the size limit of a single 'Durable Object' ?

[kentonv]

There's no hard limit, but given that a single durable object is single-threaded, storing a huge amount of data in a single object may make it hard to access that data. Also, the system may be less likely to migrate huge objects to move them closer to their users. So, we recommend aiming for small, fine-grained objects, kilobytes to megabytes in size. But there's nothing fundamentally preventing an object from growing to multiple gigabytes.

[eastdakota]

We don’t charge for malicious traffic like DDoS. Compares favorably to other cloud providers who do.

[a_imho]

It is reassuring to hear that, could this feature in the docs somewhere? For example when I'm researching this issue this is what comes up as the first result.

https://community.cloudflare.com/t/how-to-protect-cloudflare...

Workers Free Tier fail modes are straightforward and preferable for some of the scenarios I would use them for, but KV is only enabled by using Bundled.

[nmjohn]

You don't charge for worker invocations on a L7 DDoS? How do you determine which requests to charge for and which to not charge for?

Or is the claim your DDoS protection is good and accurate enough that there are 0 worker invocations to charge for because they all get blocked?

[kentonv]

We aim to block attack traffic. If we fail to block an attack and you get charged for it, file a support request to ask for a credit.

[brabel]

From what I understand after going through the docs, KV is currently the only way to store data in Workers, and Durable Objects are going to be the new alternative.

KV is eventually consistent, appropriate for low-value data that is read a lot , written infrequently... Durable Objects will provide consistency, at the cost of not having the very low latency of KV because it has to run in a single location instead of on the edges. So there seems to be room for both solutions.

About DDOS, I believe Cloudfare is a leader in ddos-protection, so I would hope they include protection in all their Workers (pls someone correct me if I'm wrong).