The next chapter for Cloudflare Workers: open-source
blog.cloudflare.com
blog.cloudflare.com
Deno follows the same philosophy as Cloudflare Workers - it’s a web compatible, secure-by-default V8 runtime for server code. But instead of only running on Cloudflare’s service, Deno can run anywhere and has a growing ecosystem of modules ready to use, including a NodeJS compatibility shim. You can even emit NPM modules from Deno code using a build step. Because Deno is open, companies like Slack have adopted it as part of their first-party APIs (https://slack.com/blog/developers/faster-simpler-way-build-a...).
I think open sourcing the runtime is a good move from Cloudflare, but even as open source, will they be able to build an ecosystem to rival Deno over the long run? Their big moat/lock-in is still the rest of Cloudflare’s APIs - but with an open local dev environment perhaps it’s easier to convince someone like me to use https://denoflare.dev/ and have the best of both worlds.
(Edit: not to imply Cloudflare is a devil! Just a term of phrase - I’m a happy Cloudflare customer)
R2 was announced in September 2021 and still isn't available (not even in open beta). And lets not mention that it was announced with the concept of zero-cost for single-digit per second access and now, when I look at the pricing page[1], I don't see request pricing that's significantly different to AWS.
Sure, egress is free, but $4.50/million write (AWS is $5) and $0.36/million reads (AWS is $0.40) is pretty expensive.
S3 is 20,000 GET requests; R2 is 10,000,000
S3 is 2,000 PUT requests; R2 is 1,000,000
S3 is 100GB egress; R2 is unlimited.
So, with R2 you get unlimited egress, 500x the free limit on requests and flat global pricing. Oh, and the actual storage is cheaper.
Except I can't get unlimited egress, because the product isn't available yet.
Egress isn't our price pain point anyway, as you may have guessed, it's request pricing. $4.50/million seems cheap, but when you're dealing with objects of 4-20KB that only exit our platform approximately once it doesn't end up being where the significant expense lies.
The blog posts in September all seemed intentionally vague on request pricing (which I and many others commented on in September) and no one from Cloudflare seemed willing to weigh in then.
I could also mention my disappointment with Durable Objects, especially as our primary use case for them was to be websockets (which also seems to be one of the biggest pitches the documentation makes for Durable Objects). But in no world does $12.50/million GB-s make sense per open connection (that's $1.56/month for a single continuous websocket connection by the way).
I even remember reading in a blog at some point (that seems to be missing now or so long ago that I can't find it anymore) that Cloudflare recognised that fact and planned to implement something that makes sense by the time Durable Objects came out of beta. But the product seems to be no longer in beta and the pricing page seems to be very specific, even having the gall to actually list a websocket example[1] on the pricing page. $409.72/month for 100 connections doing 1 message per month is not a figure I'd be shouting from the rooftops. This is literal orders of magnitude (over 100x) more expensive than alternate solutions. Heck, it's over 4x more expensive than the AWS Lambda + API Gateway equivalent if you want to compare serverless with serverless.
And as I'm sure you're aware, whilst Cloudflare have great deals for free & pro plans, as soon as you want to deliver anything that isn't really text-base at scale you need to move to the enterprise plans. The Cloudflare T&Cs basically prohibit anything that isn't HTML or from an API (see section 2.8)[2] And whilst I'll acknowledge these are less expensive than AWS, I'd hardly call these cheap. The last pricing I saw was $0.045/GB, but obviously, given it's not listed anywhere publicly on the Cloudflare website it's in the category of "if you need to ask…"
Ultimately my pain and frustration comes from loving so much of what Cloudflare is and some of the truly wonderful ways in which you and your team John, solve the technical challenges of being one of the largest CDNs on the net. But I'm disappointed that I don't get to use any of them. We're either priced out or we get excited that a new Cloudflare product is going to solve a pain point, but after waiting months for an announced product to become available, we're forced to move on or the released version doesn't deliver on the original promises.
Which brings to me to my primary point. I wish Cloudflare didn't announce products until they're actually (or very close to) available, and definitely with complete pricing with notes on quotas & limits.
Ignore my comments if you like, I had high hopes that R2 & Durable Objects would solve some of our issues. Unfortunately the small variance in price for R2 isn't going to justify re-engineering and moving our data not only to a different platform but to an entirely different organisation.
[1] https://developers.cloudflare.com/workers/platform/pricing/#...
"The Cloudflare Developer Platform consists of the following Services: (i) Cloudflare Workers, a Service that permits developers to deploy and run encapsulated versions of their proprietary software source code (each a “Workers Script”) on Cloudflare’s edge servers; (ii) Cloudflare Pages, a JAMstack platform for frontend developers to collaborate and deploy websites; and (iii) Workers KV, Durable Objects, and R2, storage offerings used to serve HTML and non-HTML content."
You can use non-HTML content on R2, DO and KV.Thats was updated, if i'm not mistaken few months ago.
We still have some work to do to get the runtime ready to open source and make it broadly available, but happy to answer any questions we can.
Specifically, the Workers Runtime was built as an integrated component of the overall Cloudflare stack. We'll need to detangle it a bit into something that can run stand-alone. It's important to us that what we release is actually usable.
The two specific things we aim to enable with this are:
1. Testing Workers locally (with more accuracy than our existing simulator).
2. Running your production app on your own servers (with no dependency on Cloudflare).
(I'm the tech lead for Workers.)
Hopefully open sourcing will stimulate the community, and maybe Cloudflare, to address the incompatibility issue. For example, to develop a shim emulating some filesystem APIs with underlying storage being as scalable as people expect from a filesystem and backed by either KV or upcoming R2.
Hopefully it comes packaged in a somewhat user friendly box. If step 1 is have a global CDN the less useful