10 ms·

How is it different than cloudflare workers?

ignoramous 5y ago
Cloudflare Workers is head and shoulders above AWS CloudFront Functions and Lambda@Edge [0], if you can fit your workloads in 50ms (CPU time) or 30ms (IO time). Workers is wayy cheaper, wayy faster [1]. Workers has 1MB script size limit (post compression), so that's there, too, and can run WASM or JS workloads (which CloudFront Functions can't, but Lambda@Edge can). As for AWS Lambda Function URLs: Well, it isn't comparable to Workers at all. But if my use case fits Workers, then that's what I'd would prefer. In fact, I've gone many lengths to make my workload fit Workers. Deno Deploy is another viable alternative. [0] https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/edge-functions.html https://docs.aws.amazon.com/AmazonCloudFront/latest/Develope... [1] dated, but relevant: https://medium.com/@zackbloom/serverless-pricing-and-costs-aws-lambda-and-lambda-edge-169bfb58db75 https://medium.com/@zackbloom/serverless-pricing-and-costs-a...
- vlovich123 5y ago
  Just some small corrections. I think you mean 30s of CPU time for unbound workers? Time spent waiting for i/o can be “infinite”. I think maybe you’re referring to billing where we bill on wall clock time for unbound workers (vs CPU time for bundled workers). For proxied requests, billing even stops once you hand back the Response object. If you need more than 1MB of script size, please reach out to Cloudflare support.
  - ShakataGaNai 5y ago
    OP meant 30/50 ms under the guise of "Workers is wayy cheaper, wayy faster". You can have unbounded workers that do whatever you want. But the cheap Bundled workers need to stay under 50ms https://developers.cloudflare.com/workers/platform/limits/#worker-limits https://developers.cloudflare.com/workers/platform/limits/#w...
    - vlovich123 5y ago
      I was specifically trying to clarify the second half of "fit your workloads in 50ms (CPU time) or 30ms (IO time)". The only time IO time is relevant for Workers is billing of Unbound Workers, not whether your workload fits. The only time-based workload limits for Workers are 50ms of CPU time (Bundled), 30s of CPU time (Unbound), or 15 min (via Unbound Cron Triggers). I thought our Unbound Workers are supposed to also be cheaper as well but I need to double-check that piece. Bundled and Unbound Workers are equally fast.
      - ignoramous 5y ago
        From what I knew, you couldn't have a Bundled Worker wait on IO or sleep for more than 30s. May be it isn't true anymore? For most workloads, I'd reckon that Unbound Workers are about the same cost as Bundled. In fact, Unbound will be ~2x cheaper than Bundled if your average workload completes within 50ms IO or 10ms CPU.
        vlovich123 5y ago
        It's not true now AFAIK [1]. Not sure if it was ever true as it's kind of core to how Workers works, but I've only been here for just over a year. Can't find anything to suggest this was ever the case. As for cost, a Bundled Worker definitely had a price advantage if you have CPU-light but IO-heavy workload. If my math is right then Unbound is cheaper up to roughly 220 ms of wall clock (I used 100M requests as an example). So if it takes > 220ms of time to send the response fully, Unbound will be the same price as Bundled and only get more expensive the longer the response takes. This isn't the RTT time to your origin. It's the total request time. So if you're doing lots of round-trips to origins, proxying WebSocket messages back and forth over a long time, proxying a large response body from somewhere else etc. This gets more complicated since we put in an important optimization that makes Unbound much cheaper if you're just proxying a response without modifying it since billing will stop once you return the Response so now the Unbound Worker has to actually be meaningfully involved in generating the Response body for it to bill until the response finishes sending to your client [2]. [1] https://stackoverflow.com/questions/68720436/what-is-cpu-time-and-wall-time-in-the-context-of-cloudflare-worker-request https://stackoverflow.com/questions/68720436/what-is-cpu-tim... [2] https://blog.cloudflare.com/workers-optimization-reduces-your-bill/ https://blog.cloudflare.com/workers-optimization-reduces-you...

Cloudflare Workers is head and shoulders above AWS CloudFront Functions and Lambda@Edge [0], if you can fit your workloads in 50ms (CPU time) or 30ms (IO time). Workers is wayy cheaper, wayy faster [1]. Workers has 1MB script size limit (post compression), so that's there, too, and can run WASM or JS workloads (which CloudFront Functions can't, but Lambda@Edge can). As for AWS Lambda Function URLs: Well, it isn't comparable to Workers at all. But if my use case fits Workers, then that's what I'd would prefer. In fact, I've gone many lengths to make my workload fit Workers. Deno Deploy is another viable alternative. [0] https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/edge-functions.html https://docs.aws.amazon.com/AmazonCloudFront/latest/Develope... [1] dated, but relevant: https://medium.com/@zackbloom/serverless-pricing-and-costs-aws-lambda-and-lambda-edge-169bfb58db75 https://medium.com/@zackbloom/serverless-pricing-and-costs-a...

vlovich123 5y ago
Just some small corrections. I think you mean 30s of CPU time for unbound workers? Time spent waiting for i/o can be “infinite”. I think maybe you’re referring to billing where we bill on wall clock time for unbound workers (vs CPU time for bundled workers). For proxied requests, billing even stops once you hand back the Response object. If you need more than 1MB of script size, please reach out to Cloudflare support.
- ShakataGaNai 5y ago
  OP meant 30/50 ms under the guise of "Workers is wayy cheaper, wayy faster". You can have unbounded workers that do whatever you want. But the cheap Bundled workers need to stay under 50ms https://developers.cloudflare.com/workers/platform/limits/#worker-limits https://developers.cloudflare.com/workers/platform/limits/#w...
  - vlovich123 5y ago
    I was specifically trying to clarify the second half of "fit your workloads in 50ms (CPU time) or 30ms (IO time)". The only time IO time is relevant for Workers is billing of Unbound Workers, not whether your workload fits. The only time-based workload limits for Workers are 50ms of CPU time (Bundled), 30s of CPU time (Unbound), or 15 min (via Unbound Cron Triggers). I thought our Unbound Workers are supposed to also be cheaper as well but I need to double-check that piece. Bundled and Unbound Workers are equally fast.
    - ignoramous 5y ago
      From what I knew, you couldn't have a Bundled Worker wait on IO or sleep for more than 30s. May be it isn't true anymore? For most workloads, I'd reckon that Unbound Workers are about the same cost as Bundled. In fact, Unbound will be ~2x cheaper than Bundled if your average workload completes within 50ms IO or 10ms CPU.
      - vlovich123 5y ago
        It's not true now AFAIK [1]. Not sure if it was ever true as it's kind of core to how Workers works, but I've only been here for just over a year. Can't find anything to suggest this was ever the case. As for cost, a Bundled Worker definitely had a price advantage if you have CPU-light but IO-heavy workload. If my math is right then Unbound is cheaper up to roughly 220 ms of wall clock (I used 100M requests as an example). So if it takes > 220ms of time to send the response fully, Unbound will be the same price as Bundled and only get more expensive the longer the response takes. This isn't the RTT time to your origin. It's the total request time. So if you're doing lots of round-trips to origins, proxying WebSocket messages back and forth over a long time, proxying a large response body from somewhere else etc. This gets more complicated since we put in an important optimization that makes Unbound much cheaper if you're just proxying a response without modifying it since billing will stop once you return the Response so now the Unbound Worker has to actually be meaningfully involved in generating the Response body for it to bill until the response finishes sending to your client [2]. [1] https://stackoverflow.com/questions/68720436/what-is-cpu-time-and-wall-time-in-the-context-of-cloudflare-worker-request https://stackoverflow.com/questions/68720436/what-is-cpu-tim... [2] https://blog.cloudflare.com/workers-optimization-reduces-your-bill/ https://blog.cloudflare.com/workers-optimization-reduces-you...