4 ms·

> 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

> 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 management belongs as a separate layer in front of the worker, so workers are only woken when things happen. And on that note, of course you can use Fanout together with Cloudflare Workers today. At the moment this requires making raw API calls but we plan to update our server libs for CF compatibility soon.

sudhirj 8y ago
> 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 volume discount, I'm trying to figure out a way to make it one or two orders of magnitude cheaper, enough that pricing is no longer relevant. Self hosting Pushpin is an option, but CF might be easier to work with. > 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. The CF edges already hold / passthrough websockets - whether the Workers API is conducive to controlling them is the question, but we know it already allows streaming - doesn't seem like big jump from there. And for my purposes one-way streaming is enough, so might not even need to change the API. And based on the current billing model it seems like only CPU time is billed (?) - so if the socket is waiting most of the time it's still cost effective. And connection management itself would still be outside the scope of the worker - I'm saying the worker's event loop should behave exactly the way it would if I using the streaming feature right now to make a 1000 slow network requests from the worker and streamed the responses out as the worker received them. Only the protocol would change.
- kentonv 8y ago
  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. :)
  - sudhirj 8y ago
    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.
- jkarneges 8y ago
  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.
  - sudhirj 8y ago
    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 <= 10 of the CF version of this https://www.top-ix.org/wp-content/uploads/2016/10/Open-Connect-TOP-IX-January-2017-1.pdf 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.

sudhirj 8y ago

> 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 volume discount, I'm trying to figure out a way to make it one or two orders of magnitude cheaper, enough that pricing is no longer relevant. Self hosting Pushpin is an option, but CF might be easier to work with. > 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. The CF edges already hold / passthrough websockets - whether the Workers API is conducive to controlling them is the question, but we know it already allows streaming - doesn't seem like big jump from there. And for my purposes one-way streaming is enough, so might not even need to change the API. And based on the current billing model it seems like only CPU time is billed (?) - so if the socket is waiting most of the time it's still cost effective. And connection management itself would still be outside the scope of the worker - I'm saying the worker's event loop should behave exactly the way it would if I using the streaming feature right now to make a 1000 slow network requests from the worker and streamed the responses out as the worker received them. Only the protocol would change.

kentonv 8y ago
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. :)
- sudhirj 8y ago
  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.
jkarneges 8y ago
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.
- sudhirj 8y ago
  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 <= 10 of the CF version of this https://www.top-ix.org/wp-content/uploads/2016/10/Open-Connect-TOP-IX-January-2017-1.pdf 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.