Will also check on NS delegation. Again, my hunch is that we only charge for it because it's something that less sophisticated users we worry would get themselves in trouble messing with.
It does. IIRC GitLab Pages used to have docs saying to set a CNAME for your domain without warning about doing it on the apex domain. I'm not sure if GitHub Pages was any better either.
It's only confusing the first time you mask your MX records. LMAO.
To me, my biggest pain points is I cannot set NS record for a sub domain.
My use case is this: I had a certain subdomains where I want to use LetsEncrypt DNS with DNS validation. I don't want to give the whole domain to the auto renewal script. With another DNS provider, AWS Route53 for example, I can easily create another zone for that subdomain say blog.domain.com and set NS record on blog to that zone. Then create an API key with only privileges to manage that sub zone. I cannot do that with CloudFlare though.
Agree on Cname flattening. It cause some issue for my email forward service in the past.
So we have customer use githb page and set CNAME on apex domain. Then they add a MX record for apex domain. CloudFlare UI allow them to do that. But upon resolving won't return MX records for the apex. So my customer aren't able to finish setup. Eventually we have to set the A Record on Apex to an IP.
Are you sure? I have a free site where `in.example.com` is delegated to Namecheap's FreeDNS so I can use it for DynDNS on some devices that don't support Cloudflare's newer (fine grained) API tokens.
(I know there's an import but it erases some of the other settings)
$0.99 domain providers mostly get this right
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.
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.
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.
I'm not sure you're looking at the problem right.
I mean, if you write your AWS Lambda code to do the same thing Cloudflare does to their workers in their Bundled Requests pricing model and automatically kill them if they reach 50ms, you also get a dead simple way to know what you pay per request.
However, Cloudflare also charges per request and per execution time their Unbound requests pricing model, which leads us pretty much to AWS Lambda's pricing model.
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.
The really are. By Cloudflare's ow docs, Cloudflare workers are just scripts that are designed to be executed before a request hits the cache.
Quite the far cry from what AWS Lambda offers, which is a generic compute platform that handles both long-running batch jobs and handles events, and can be invoked any way that suits your fancy (HTTP request, events from other AWS services, AWS SDK).
At most, Cloudflare workers are comparable with Lambda@edge.
> 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.
You are right. According to Cloudflare's docs, Cloudflare Workers are capped at 10ms CPU time on their free tier, but their Bundled Usage Model plan bumps the CPU time limit to 50ms. There's also Cloudflare's Unbound plan which not only charges per request but also adds charges for duration instead of CPU time (i.e., also charges for idling time when waiting for responses) and that's bumped up to 30s.
https://developers.cloudflare.com/workers/platform/limits
> 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.
No, not really. Cloudflare announced a private beta for their Cloudflare Workers Unbound Cron Triggers a couple of months ago, but that's about it.
https://blog.cloudflare.com/workers-unbound-ga/
https://www.cloudflare.com/workers-unbound-beta/
I'm not sure how familiar you are with AWS Lambdas, but if you check their docs you'll notice that, unlike Cloudflare Workers offering, they are general purpose and can be even invoked from all kinds of events, including directly from HTTP requests. So, neither they are available nor are they comparable to AWS Lambdas. Thus I'm not really sure why you brought up something only made available through a private beta and is very limited in it's capabilities to compare with AWS Lambda, which is production ready for years.
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.
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 ?
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.
FYI, running it locally would involve buying hardware and maintaining that hardware, at each datacenter (there are multiple). We don't have any server hardware at the data centers.
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.
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.
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.
Right now I have to use Amazon SES + SNS for this but seeing how cloudflare already has workers, this would be a killer feature for a lot of companies including mine.
Also… auth
> Never lost your emails.
Should be "Never lose your emails."
They almost compete with everyone now.
DNS: They eat simpledns lunch Pages: They eat Netlify lunch Worker: They eat serverless/lambda as in AWS/GCP lunch R2: They eat AWS Lunch
And finally
Email Forwarding: They eat ... my own lunch (I'm founder of hanami.run an email forwarding service)
That's being said, from a user perspective, if my domain is already on CloudFlare, I can just host everything on it.
Right now, cloudflare workers is pretty great to add some dynamic stuff. And pages is great for static site.