For reference - Lambda functions used to billed at 100ms intervals. My Node.Js function usually only takes 37-40ms to run. So this is a pretty good advancement for cost savings.
- Chris, Serverless@AWS
Cloudflare Workers has the right pricing model. They only charge for CPU time and not wall time. They also do not charge for bandwidth.
> Lots of sub 100ms workloads...
AWS Lambda (or Lambda at Edge), as it stands, is 10x more expensive for sub 50ms workloads (Workers does allow upto 100ms for the 99.9th percentile) that can fit 128MB RAM.
https://medium.com/@zackbloom/serverless-pricing-and-costs-a...
I don't know the infra costs of operating lambda, but my guess is that it's far from CPU-dominated.
I would not be surprised if the Cloudflare pricing model is making a tradeoff to make CPU-bound workloads pay for more of the infra than the rest. It's a valid trade-off to make as a business offering, and it might be feasible given the mixture of workloads. Whether it's the right way is debatable. Whether this model can be tanked by an army of actors taking advantage of CPU-insensitive pricing remains to be seen, or is an acceptable risk that you can take (which you can observe and protect against).
https://developers.cloudflare.com/workers/platform/limits
Workers aren't the same as lambdas, they are a super slim JS environments. At 50ms max runtime most browsers won't even start, let alone fetch and process a page.
Then there are more specialized browser-testing providers like LambdaTest.com and BrowserStack.com
Care to expand on that? What exactly do you mean by "things are way more different"?
https://developers.cloudflare.com/workers/platform/limits
It's a quick Google. 128MB max memory, 6 concurrent out going connections max, 1MB code size limit. The use case here is a subset of what AWS Lambda can handle. The supported languages also differ (only things that have a JS / wasm conversion for Cloudflare Workers).
I haven't looked deeply, so please correct me if I'm wrong, but I understand there's also restrictions on the built-in APIs available [1] and npm packages supported for NodeJS.
I would assume some of the above contributes to the price difference.
1 - https://developers.cloudflare.com/workers/runtime-apis/web-s...
Second, for sub 50ms workloads [0], Workers is absolutely a superior solution to API Gateway + Lambda or Cloudfront + Lambda at Edge if the workloads can fit 128MB RAM and package/compile to 1MB JavaScript or WASM executables, in terms of cost, speed, latency, ease of development etc
[0] For Workers, 50ms is all CPU time and that is definitely not the case with Lambda which may even charge you for the time it takes to setup the runtime to run the code and time spent doing Network IO and bandwith and RAM and vCPUs and what not.
It's like going to a restaurant that uses bottled water instead of tap water, and they dont provide an answer as to what the benefits of bottled water are
On Lambda you get a full environment inside an OS container. On CloudFlare you get a WASM process.
The Lambda model is more compatible which can be a real benefit.
Besides the fact that Cloudflare's part of the Bandwidth Alliance with GCP and other infrastructure providers from which AWS is conspicuously absent, Cloudflare's also slowly but surely building a portfolio of cloud services.
Cloudflare's alliance with other infrastructure providers mean Cloudflare's platform isn't really limited to "API" workloads. This is discounting the fact that Cloudflare recently announced Workers Unlimited for workloads that need to run longer (upto 30mins) though then they do charge for bandwidth.
Otherwise it's just "AWS said, Cloudflare said"
Not sure about this, most use cases of Lambda use other resources and do not exist in a vacuum. Comparison should be made using complete systems not only parts.
Is there fine print on this? Can I put 100TB / mo through their caching servers at the lowest $20 price tier?
Any word on whether we'll also see this change on L@E billing?
-Harlan, the ex-intern
If this also covers lambda@edge, this will save us quite some money.
Someone from AWS once commented to me that "if you're ever having to manage a pool rather than letting us manage it, that's a gap in our services".
Thanks! It's been a fun/interesting 4 years in this space :)
Edit: You're spending like 80ms on cold-start of your lambda function, plus network overhead. If you can spare that, you can likely spare the half a millisecond for the 999,900 cycles you're complaining about.
I've never used Lambda, but any time I have a function that I need to run in response to some event or perodically (that's what Lambda is, right?), it's set up in a background worker specifically because it's long and slow, as anything fast can be done synchronously without the overhead.
For longer tasks, spinning up an EC2 or Beanstalk instance is probably the way to go.
As for what to use it for, we used it in our application (deployed to Netlify which uses Lambda under the hood) where lambdas operated like a 'proxy' to various 3rd party API suppliers (Commercetools, Adyen, some age verification service), and those too would use a lambda function to ping back at us (e.g. when payment was confirmed). Worked pretty well, although in retrospect I would've preferred a 'normal', monolithic server to do the same thing.
For some people. Those cost savings are made up somewhere else. Ultimately, Amazon is not a loss leader.
It matters close to 0.
You might only drop videos in once a week, but when you do you want to run some code against them. There are plenty of distributed workflow reasons to run long running Lambdas infrequently rather than spinning up and down an EC2 instance.
[0] https://aws.amazon.com/lambda/pricing/
[1] https://www.cnbc.com/2017/09/18/aws-starts-charging-for-ec2-...
Not trying to nitpick anything; just curious what was meant by "underpowered". Seems like there's still a breadth of compute-intensive use cases that are more appropriate for lambda--e.g., cost is more sensitive than latency and I have too low a volume of requests for a dedicated EC2 instance to make economic sense. This has been where I've spent most of my career, but no doubt there are many use cases where this doesn't hold.
(ie, if people now use 1.5x as many Lambdas, they can lower costs by 1/3, and everyone wins).
People think about pricing as a zero sum game. In reality, there are very few things in the world that are zero sum games.