4 ms·
> They eat serverless/lambda as in AWS/GCP lunch Aren't Cloudflare Workers a very specialized kind of lambda that's severely resource constrained and whose run
by rewma 5y ago
> They eat serverless/lambda as in AWS/GCP lunch
Aren't Cloudflare Workers a very specialized kind of lambda that's severely resource constrained and whose runtime is capped at 15ms?
If anything Cloudflare Workers compete with Lambda@edge, but it's very disingenuous to compare them with AWS Lambdas and it's completely absurd to claim they eat anyone's lunch.
Cloudflare Workers's usecase is extremely limited and specialized: run a script comprised of a couple lines of code that do not do much at all right at the edge. We're talking about things like adding a response header. Even then they are immediately killed if pretty much they don't exit immediately.
- dragonwriter 5y agoAren't Cloudflare Workers more comparable to AWS Lambda@Edge than regular Lambda?
- rewma 5y ago> Aren't Cloudflare Workers more comparable to AWS Lambda@Edge than regular Lambda? Yes that's my point. Unlike AWS Lambda, the usefulness of Cloudflare Workers is very specialized and narrow, like adding response headers or update a response document. AWS Lambdas on the other hand can run freely for over 15min, have virtually no limit in how much RAM they can use, and can be pushed as a Docker image with a max size of 10GB. If that is not enough, AWS Lambdas can be tied together into workflows with AWS step function. Therefore, for anyone to claim that Cloudflare Workers win over AWS Lambdas, either they have no idea what AWS Lambdas are or have no idea what Cloudflare Workers are.
- kureikain 5y agoHere is my use case: I have a static site to process form and referral. It used to run on AWS Lambda. I migrated them to Cloudflare workers. Deployment, code editing etc is much easier. And no, it's fully act as a standalone app. I define the route to to route a part of traffic to the worker, other parts to our pages app. For me, it works great and replace my aws lambda usage.
- ElFitz 5y agoI have used them as reverse proxies to have re-direct slack messages to the Firebase project (we use one Firebase project per environment). Also used them to return images from different providers, and resize them, on a single endpoint. Plus, if you decide to pay a premium (but still often cheaper than lambda), they can run for just as much time. All that’s actually missing here, for me, is the triggering mechanisms and integrations with services like S3, SNS, DynamoDB, etc.
- latchkey 5y agoSo very limited, but really solve some huge problems. I run datacenter(s) with thousands of autonomous machines. These machines run a small binary daemon. That daemon needs to check for a new version of itself, which is built/released as a CI push job on github (after all the tests pass). A super simple CF worker serves as a reverse proxy to the GH API + the download of the binary. For $5/month, I've worked around the GH API limitations, in a massively scalable way.
- nly 5y agoYou should write this up, it sounds cool
- manquer 5y agoInteresting use case and solution. Why not use package publishing tool like packagecloud.io (or setting your own private reprepro, dak variation) with unattended-upgrades configured for the repos and frequency you need ? Was the tooling at OS layer not adequate for this kind of setup ?
- latchkey 5y agoYou have a good point. At the end of the day, this is an implementation detail and something that can be easily changed. =)
- latchkey 5y agoLooking into packagecloud.io pricing, I'd be in the $700/month plan based on transfer alone. $5 -> $700.
- manquer 5y agoYou are running a DC with thousands of machines, while $700 is not insignificant, it shouldn't be a decision making factor at that size. You could run package manager locally and save on that managed cost if you really wanted to. As developers we constantly discount the value of our time. Your time in developing/maintaining these scripts is not free. From an org perspective, to maintain a home grown solution is not free either, inevitably someone would take over this part of your role, they would need skills they otherwise probably won't need to have (making hiring harder/costlier) and they will need more training and also will have to spend time maintaining it. This is true even if you are the founder of the organization. I thought being a founder where I am going to go so early on built solutions like yours. It turns out that doesn't make any difference The role always changes . As an employee we become older acquire more skills/knowledge/experience and role changes or simply leave the org. As a founder we grow the company and have to hire more people to do what once we did.
- kondro 5y agoNo. The all-inclusive Lambda workers are limited to 50ms of actual CPU runtime and can execute forever (i.e. hours) for IO bound workloads, as long as you stay below the 50 network requests per execution. And for that they cost $0.50/million, have unlimited in/egress bandwidth and free in-DC caching. But they also have a more AWS-like pricing option that’s about 20% cheaper and charges per request, per GB-hour (for runtime, not actual CPU usage) and for bandwidth with a maximum runtime of 15 minutes. They also have Durable Workers which provide you global singleton persistent functions for stateful architecture. If you haven’t had a look at CF’s serverless stuff for a while, it’s worth a look again.
- ryan29 5y ago> If you haven’t had a look at CF’s serverless stuff for a while, it’s worth a look again. That's especially true if your workload makes sense for the all-inclusive Workers. I evaluated only the pricing a while back and Cloudflare Workers are far more attractive than anything else in the market IMO. With AWS and Azure, it's really hard to calculate just how expensive things are going to be. I'd say it borders on impossible without just running your workload for a bit and waiting for the bill. With Cloudflare Workers, it's dead simple. As long as your Worker runs in <50ms, it costs $0.0000005 per run. I can tie that directly to (page) hit counts and calculate costs with very little effort. For my own reference point, I ignored the fixed cost per run, which is actually more expensive for Lambda@Edge, ignored the variable cost per run, which actually has minimums for Azure Functions, and calculated the egress cost per byte. Assuming they use GB and not GiB for egress, it's $.09 / 1,000,000,000 = $0.00000000009 per byte. Now take your Worker cost and divide it by the per-byte egress cost and that's 0.0000005 / 0.00000000009 = 5,555. That's <6KB of egress for the same price as a Worker run on Cloudflare. Even if AWS and Azure started offering free Lambdas / Functions, it would still be a bad deal if Cloudflare Workers meet your technical needs.
- kondro 5y agoDon't forget AWS CloudWatch for logs. Cost for log processing is $0.50 per GB and the minimum size of logs (just for the START/END/REPORT lines output by Lambda itself, before you start logging any of your data) is about 260 characters (or 260MB/million == $0.13/million). Honestly, unless you have gone out of your way to implement something that isn't CloudWatch for logs (and there's almost no documentation on how to do that), its not hard to get an extra 5-10KB ($2.50-$5.00/million to process by CloudWatch) of logs per request. Like AWS egress charging, CloudWatch Logs can quickly dwarf the cost of using the services themselves.
- Thaxll 5y agoEspecially since lambdas are tide to the entire AWS ecosystem. It's plugged to cdn / load balancers, s3 ect ... Cloudflare has none of that.