Comment by BoorishBears
3 days ago
Why are you straining so hard and spending so many words to defend general scumminess.
Invisible limits are an anti-pattern, simple as that.
3 days ago
Why are you straining so hard and spending so many words to defend general scumminess.
Invisible limits are an anti-pattern, simple as that.
See my other comment[1]. I'm not sure why you're straining so hard and spending so many words to defend "general scumminess", like the the right of a gambling site hosting dozens of domains (to evade government bans) on shared cloudflare IPs, or people expecting to get 1.2PB of bandwidth served out of a $200 CDN plan.
[1] https://news.ycombinator.com/item?id=42717005
You want this to be complicated so badly, but it's not.
Hidden limits are an anti-pattern.
There is no counter-argument.
If they have a hard limit they can cut people off well ahead of 1.2PB of bandwidth with less ambiguity: it's a strictly better situation.
>You want this to be complicated so badly, but it's not.
>Hidden limits are an anti-pattern.
>There is no counter-argument.
Here's a counterargument: do you get similarly upset that restaurants advertising "free refills" cut you off after you've been at the place for 12 hours and you dispensed 8L of coke? Explicit limits is how you get "limit one refill per customer", leaving most customers worse off.
Do I think hidden limits are always better? No. It operates on a spectrum, and depends on how many "legitimate" customers are affected by the limit.
7 replies →
Cloudflare doesn't have hidden limits. Their limits are not written down, and they're somewhat moving targets (which is probably why they're not written down); but they're very obvious (in an economic sense), and their value (at any given point in time) is very easily measured.
Cloudflare's limits can be formalized by imagining one of their PMs saying the following: "You can do things on our general infrastructure for free, as long as we don't offer more-specific infrastructure that's intended specifically for the thing you're doing. And even then, we will let you use the general infrastructure as a "workaround" to needing to engage with the domain-specific infrastructure... up until the point where — if you had been using the purpose-built domain-specific infrastructure from the beginning — the cost model for that specific infrastructure would have had you spending enough money, that the 'uncaptured revenue' you would represent, would begin to affect one of our salespeople's KPIs. Once you hit that point, our salespeople will come to 'convert' you."
For examples:
• You can force regular old Cloudflare to cache large image assets through Page Rules, with long TTLs, for free. Or you can stuff your large image assets into Cloudflare R2, lose the ability to set long TTLs, and pay per (origin-pull) GET request above a certain daily free-tier limit. If you serve enough image assets through Page Rules that you represent non-trivial uncaptured R2 revenue, then Cloudflare will contact you.
• You can force a Cloudflare Pages site to do small amounts of CF Workers logic in the routing phase of serving the page, for free. Or you can put an actual Worker in front of a regular static site, and pay per GET request + per CPU-second after some free-tier thresholds. If you use enough CPU-seconds inside the "unbilled" stage of your Cloudflare Pages site, Cloudflare will contact you. (Note that they're very unlikely to come after you for this, since the limit on the amount of work you can do here is pretty trivial, so you'd have to be getting a ridiculous amount of requests for this overhead to add up to anything meaningful.)
• Previously, you could force Cloudflare to resize images "on the way through" for free, using a /cdn-cgi/ path. These days, you're forced to go through Cloudflare Images, which charges per request and (IIRC) per processed byte. This is because everyone was using the free approach and ignoring the Cloudflare Images infra, and Cloudflare saw hundreds to thousands of accounts with potential non-trivial un-captured revenue here. Rather than address them all individually, they "sunsetted" the support for free image resizing, to force these accounts to either start paying or get out.
---
Note how this is exactly the same as a restaurant saying: "you can have water for free, and we'll put a lemon slice in your water, but we're not going to give you enough lemon slices and table sugar packets to make lemonade with — because we charge for lemonade. Just buy the gosh-darn lemonade; stop exploiting our kindness to make it yourself; by doing so, you're using way more of our resources than if you'd just let us make it."
There's nothing hidden about the cost of lemons or sugar packets. The restaurant is going to give you lemons and sugar packets for free right up until your consumption could have paid for a lemonade. Then they're gonna force you to buy the lemonade.
1 reply →
If 1.2 PB is a problem, then why don't they just specify a bandwidth limit of say 1 PB? They specifically say "unlimited bandwidth", so yes, what they are doing _is_ scummy because there is a very obvious incongruity between what they claim and what they actually offer.
I imagine because people will immediately push up against the limit and no further. It’s much easier to detect these excessive users if their bandwidth naturally keeps growing.
This is just stratified pricing. If you're egressing 1.2PB ($50k+ worth of bw on AWS) there's a likelihood that you're earning a fair bit and an enterprise contract will be worth it to you when it comes to support. On the other hand if you're egressing 1.2PB to serve some open model weights that you don't charge for, CF would prefer to leave you to it and enable you to serve.