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

Introducing Workers KV

blog.cloudflare.com

Post reply on HN
Print view View original

91–100 of 103 posts

Re: Introducing Workers KV

#91

Post by kjeetgill »

biesnecker wrote: post #80
steego wrote: post #32

Earlier quoted context omitted.

I had to upvote you just because I plan on getting some mileage out the phrase "YOLO last write wins." It has just the right amount of snark to remind junior developers to not trivialize or discount the value of consistency.

And it's really "YOLO last write recorded wins," because who knows what order anything arrives in.

"yolo a latter write probably wins ... I guess?"

Seriously, if you're new to that domain go read:

https://aphyr.com/posts/333-serializability-linearizability-...

https://aphyr.com/posts/313-strong-consistency-models

Re: Introducing Workers KV

#92

Post by jkarneges »

sudhirj wrote: post #88
jkarneges wrote: post #86

Earlier quoted context omitted.

> Fanout.io gets this right, but would be nice to have cheaper alternatives / make it a commodity. Hi! Fanout founder here. I’m glad you like our way of doing things. If you need better pricing for high volume we are always willing to discuss. I’m not sure you’d want to maintain a WebSocket inside of a CF worker. At least I can’t see that helping with cost. Execution time limits would get you too. IMO connection mana…

> Hi! Fanout founder here. I’m glad you like our way of doing things. If you need better pricing for high volume we are always willing to discuss. Hi! Wasn't expecting you to show up like this. Re. pricing for high volume, I'm sure enterprises and publishers could afford it, I'm trying to see if it's possible to offer free or very cheap service to individuals with large audiences. So not so much that I want a high vo…

Oh interesting, I didn't realize CF Workers metered by actual CPU usage and not just clock time. That would certainly make a difference in the expected cost.

Even still, handling millions of simultaneous connections, with each connection in its own worker in a multi-tenant execution environment in order to save money sounds crazy. :) The operating cost (and thus the price) of a purpose-built system like ours should be lower than that of a generalized system. I think your easiest path is to just tell us your preferred pricing model.

Re: Introducing Workers KV

#93

Post by adrianmonk »

zackbloom wrote: post #69
adrianmonk wrote: post #58

Earlier quoted context omitted.

The shopping cart is still stored somewhere, but when the user has cleared their cookies, etc., what information do you have that will let you it's their shopping cart so you can find it again? There's a (K,V) pair somewhere, but in order to get V, you need K, which you've lost.

It would work just as most shopping carts do I imagine. You could store a session id in a cookie, and then use the data in KV to map that session id to a user account (if they're logged in) and their cart. So you would have a namespace full of sessions, and a namespace full of carts. You could also store carts by session id until they're logged in, and then store the carts by account id when they are.

> You could store a session id in a cookie

But the person you responded to asked what happens after "I clear my local storage/cookies". So you don't have access to the session id. It was in a cookie that is now gone.

Re: Introducing Workers KV

#94

Post by sudhirj »

jkarneges wrote: post #92
sudhirj wrote: post #88

Earlier quoted context omitted.

> Hi! Fanout founder here. I’m glad you like our way of doing things. If you need better pricing for high volume we are always willing to discuss. Hi! Wasn't expecting you to show up like this. Re. pricing for high volume, I'm sure enterprises and publishers could afford it, I'm trying to see if it's possible to offer free or very cheap service to individuals with large audiences. So not so much that I want a high vo…

Oh interesting, I didn't realize CF Workers metered by actual CPU usage and not just clock time. That would certainly make a difference in the expected cost. Even still, handling millions of simultaneous connections, with each connection in its own worker in a multi-tenant execution environment in order to save money sounds crazy. :) The operating cost (and thus the price) of a purpose-built system like ours should b…

Depends on how you look at it. The way I see it I would be quite reasonable to start a few droplets / instances in every region Digital Ocean / AWS support and have websockets terminate there. I'd could even assume this is what Fanout/comparable service is currently doing.

From the cloudflare side I'd assume that each edge has 1 > n https://www.top-ix.org/wp-content/uploads/2016/10/Open-Conne... . Imagine CF had 100s to 1000s of these at every edge - they could/would then offer either DO sized droplets or AWS Fargate sized containers at every edge with CF load balancing, and we could be installing Pushpin on every edge. And it wouldn't sound odd. This seems like it's just a logistics problem - it's not inconceivable that 2020 / 2023 birthday week will announce this. (@CF you should totally call each droplet/instance a 'Flare')

In the meantime the Workers seems like a way to offer highly controlled computing on these edges - but other than the tighter control of the executing environment I see no difference from the scenario mentioned above. So if all the load balancing, connection handling and deployment pieces are already in place, I think we can and should try to use it for any possible use case that we would have used regular servers for.

Re: Introducing Workers KV

#95

Post by sudhirj »

kentonv wrote: post #89
sudhirj wrote: post #88

Earlier quoted context omitted.

> Hi! Fanout founder here. I’m glad you like our way of doing things. If you need better pricing for high volume we are always willing to discuss. Hi! Wasn't expecting you to show up like this. Re. pricing for high volume, I'm sure enterprises and publishers could afford it, I'm trying to see if it's possible to offer free or very cheap service to individuals with large audiences. So not so much that I want a high vo…

I actually have an open PR to add WebSocket endpoint support to CF Workers (so a Worker can act as a WebSocket client or server, instead of just a proxy). The main hangup though is that we need to figure out how to charge for long-lived connections. We obviously don't want to apply the normal time limits in this case. Hopefully we'll find time to work through this soon. :)

Nice! My 2 cents would be to charge a cheap rate for idling time and the regular rate for CPU execution. Or maybe use bandwidth as a proxy for CPU usage and an overall connection time charge.

Re: Introducing Workers KV

#96

Post by jkarneges »

sudhirj wrote: post #94
jkarneges wrote: post #92

Earlier quoted context omitted.

Oh interesting, I didn't realize CF Workers metered by actual CPU usage and not just clock time. That would certainly make a difference in the expected cost. Even still, handling millions of simultaneous connections, with each connection in its own worker in a multi-tenant execution environment in order to save money sounds crazy. :) The operating cost (and thus the price) of a purpose-built system like ours should b…

Depends on how you look at it. The way I see it I would be quite reasonable to start a few droplets / instances in every region Digital Ocean / AWS support and have websockets terminate there. I'd could even assume this is what Fanout/comparable service is currently doing. From the cloudflare side I'd assume that each edge has 1 > n https://www.top-ix.org/wp-content/uploads/2016/10/Open-Conne... . Imagine CF had 100s…

To me there's a big difference between a compute host (VM/containers) and a function host in this context.

Running Pushpin on a bunch of compute instances means being able to operate at maximum performance with minimal impact between tenants. Compared to FaaS, I believe the difference in resource usage should be so significant that any provider of a shared-Pushpin service would be able to win on price.

I'm also still not quite sure how a FaaS-based push system would actually work since there's the problem of getting data around among the workers. You don't want a million workers polling a DB. I suppose you could integrate a messaging/queuing system with your workers, and each worker keeps a long-lived connection with the queuing system. But if you do this, you'll have barely built a push system at all. Instead you'll be dependent upon a millions-connection-capable queuing system, and your workers will simply be doing data conversion between two connections. And of course the queuing system would live outside of the FaaS, provided by someone for a cost.

Re: Introducing Workers KV

#97

Post by rita3ko »

manigandham wrote: post #17
zackbloom wrote: post #7

Earlier quoted context omitted.

The question I would ask is: once you have the ability to run code and store data on the network itself (which Cloudflare effectively is), why do you need an origin at all?

You work for Cloudflare so that's a fun question but realistically there are still plenty of limitations. The script size, number of routes, KV consistency, write limits, and simple get/put API, etc. It can work for simple apps but there's a long way to go before any serious enterprise system will be hosted entirely on a FaaS system like Workers.

If you’re having trouble with script size and route limitations, would love to chat. We’re working on providing more flexibility in that realm. rita at cloudflare.

Re: Introducing Workers KV

#98

Post by kentonv »

zackmorris wrote: post #87
noelwelsh wrote: post #24

Holy return of tuple spaces! Are there any features for controlling consistency, or is it just YOLO last write wins?

For anyone curious about this, it probably all comes down to an atomic compare and swap request: https://en.wikipedia.org/wiki/Compare-and-swap It might be straightforward to do this with an ETag like Firebase: https://firebase.googleblog.com/2017/07/introducing-conditio... Not sure what this would require on their backend though.

Yes, you'll be able to use etags with if-match for optimistic concurrency. When reading and writing from a Worker, if you do a get() followed by a put() on the same key in the context of the same request, we'll take care of the if-match automatically under the hood, so the put() fails if there was a concurrent write.

(This logic is not quite in production yet but should be within a week or two.)

Re: Introducing Workers KV

#99

Post by kentonv »

panic wrote: post #90
zackbloom wrote: post #85

Earlier quoted context omitted.

Put the target channel name and a message id at the front of each key and you can use a tuple space for IPC.

What I mean is: can a process block until a particular key appears, then resume execution after receiving the associated value? That's the main differentiating feature of a tuple space, and it wasn't clear to me whether this system supports that or not (or even has a concept of a process).

No, that's not supported at present, but that's an interesting idea.

Workers don't have the concept of processes. The unit of compute is an individual event -- e.g. handling an individual HTTP request. So we'd have to augment it a bit, but we can probably come up with something useful.

Re: Introducing Workers KV

#100

Post by kentonv »

zhobbs wrote: post #67
ryanworl wrote: post #2

Are you planning on releasing any of the architectural details behind this service? If you’re truly replicating to every PoP that’s quite a fan-out and I can see why you’re limited to 1 write per second per key!

I was wondering if it is lazily replicated to PoPs via KV gets. Would be interested in clarification on that though.

At present, yes, lazy propagation. But we're also exploring ways to do proactive propagation where desirable.
Post reply on HN