3 ms·

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

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.
- jkarneges 8y ago
  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.
zackbloom 8y ago
It's worth realizing the multi-tenant nature of Workers happens within a single process, meaning from a cost perspective it's essentially indistinguishable from running your own hardware. It's actually one _less_ VM than if you were managing your own EC2 instances.

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.

jkarneges 8y ago
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.

zackbloom 8y ago

It's worth realizing the multi-tenant nature of Workers happens within a single process, meaning from a cost perspective it's essentially indistinguishable from running your own hardware. It's actually one _less_ VM than if you were managing your own EC2 instances.