Bugs happen all the time. They roughly increase with scale, not decrease. There’s an argument to be made about better testing, but this specific bug seems like a perfect one to slip through: multiple services, hard to spot at code review, involves JS/frontend, invisible at low traffic (test/UT envs).

So IMO it’s not completely insane. Is the implication that Cloudflare should have no bugs whatsoever?

We're already past the point of getting our hackles raised when we suspect something is AI written. Everything is or soon will be AI written.

So I don't think it's that useful to blame bad product design on AI.

Bad product design is just bad product design. Bad writing is just bad writing. Bad graphic design is just bad graphic design.

The industry needs to get over this hump of pretending we're not all going to adopt AI for every imaginable thing. The cat's out of the bag, for better or for worse.

> a little more cringey and clique

Why on earth do I care if someone thinks Cloudflare is cringe? What is interesting about that? They are following the market like everyone else.

> Too many ways to do the same thing, none of them great…They got D1 (SQLite serverless), Durable Objects with their own SQLite, KV, R2, Queues, and Hyperdrive to speed up external Postgres or MySQL.

What does this have to do with AI psychosis? I thought that was the thesis of this article? As I said, it’s just directionless complaining.

There wasn't. Cloudflare is a cancer grown too big. And it was always positioned to become one, the middleman between users and the Internet.

It is already painful to browse web sometimes using the non-"standard" tools (that is, not a Chrome with Google account signed in, not an EU/US residential IP). What if tomorrow Cloudflare checks will require attested and signed browser binaries?

They own a huge chunk of the internet now - with many, many companies having deeply integrated CF into their own stuff.

Switching costs are so high, from a business standpoint, investing in technical excellence would be wasted money. They're just a corp like everyone else. Gravity also applies to them.

__

Don't take this as "they're right to do so". Take this as "You should never have started integrating their products this deeply. This was inevitable and obvious."

Using CF always was trading short-term wins for long-term losses. We're now entering said long-term.

And AWS/GCP/etc are “Cloud 1.0”.

They believe that AI Agent will fundamentally change the internet, and it’s hard to fault them for seeing it that way when their own stats shows that bot/agents account for the majority of Internet traffic.

As such, going all in on AI fits into their thesis of being “Cloud 2.0”.

it gets a bit more complex for customers to figure out what the good nuggets are and what to ignore for now

same @ google, aws and so on

(I usually rely on opinions of people i trust to find the 'javascript — the good parts' version of large offerings)

the other extreme would be not to try and ship new stuff which is also risky

difficult to find a balance and probably a good idea to over-index on momentum and new stuff

while investing enough in hardening and improving the stuff that sticks

I've been at companies with lots of staffing and velocity (pre-AI), and it is a huge foot-gun to think pumping out features is automatically a good thing. Most paying customers do not want this from SaaS type companies.

Smaller companies especially should calm down and do one thing well, and unfortunately AI dev does not encourage that.

Maybe 2 years ago it would’ve been acceptable to release the product internally, slowly add features, dogfood it, then open to public a year later. But now someone else will release the same product within a month, get sticky customers, and most likely won’t switch.

It’s much easier and faster to release features, so once anyone sees a competition gaining some attention, they just copy the same feature. Which, i think, is fair.

It’s easy to blame the org, but the market is extremely competitive right now. Kind of race to the bottom, except the hardware parts, which have different constraints right now.

Powerful, but the densest collection of UI anti-patterns known to man.

Their "designers" obviously walked up hill both ways in the snow to school every day while being eaten by a walrus and feel anyone who doesn't enjoy a suitably opaque navigation scheme isn't worth acknowledging.

But also: What they've doing with Workers et al. has made them a platform for fully-fledged apps and deployments. I personally love the ecosystem and use it for all of my projects now. It's like the perfect blend of ease-of-use and DX of Heroku, and breadth of services of AWS / GCP. Well, maybe not quite AWS or GCP, but that's kind of the point -- they've created an opinionated system of "objects" that are all highly extensible to the point where in my opinion you can pretty much deploy anything you want on it.

It took me a bit of time to learn the "Cloudflare way" of doing things, but once I started making on it I saw just how flexible (and low cost!) everything is.

If what you want is a VM to run postgres then there are other offerings that would be much better.

Not saying they aren't evil though, they probably are, but the infra stuff is cool.

In the DRM problem you want to sell someone a Blu-Ray with a movie they can play, but also not allow them to copy the movie. So they get the data but can't have the data.

In the IaaS problem you want to sell someone a piece of server(s) in a datacenter they can play with, but also not allow them to just directly use the hardware (because then they could have open standards and portability). So the product teams are required to work backwards from the necessity of wrapping compute in a thing you can sell as a product.

This also explains nonsense like "durable objects", which may have some purpose but become the weekly podcast fad after getting hyped by cloud providers trying to find new ways to sell compute without selling compute.

I can really only remember one catastrophic outage. It involved some part of CF that had no redundancy, and the incident was followed by a pretty whiny blog about a data center.

That's pretty much it. There were other minor outages but I'm not aware that it affected business.

Despite the disclaimer I think the author should explain precisely how "AI product mindset" or whatever is actually translating to bad outcomes.

Cloudflare build from the bottom up. First the SDN ( Software Defined Network), then the products on top. The first one was logical: CDN + DDOS.

All the rest continued to build on top of the SDN - Workers, D1, ... But once they have the full stack ( which happened arround D1), it was time to let others build on top of Cloudflare.

That's the current stage ( Cloud 2.0), that was always the goal. It's even in their ticker ( NET ).

In practise, AI could be a godsend. A total new foundation for software where the Cloudflare stack is a perfect product fit( disposable compute, where others will protect their compute with long running compute contracts). I can't blame them to try to seize the opportunity.

Tbh. I feels like the author hasn't actually adjusted to how Cloudflare is building it's cloud ( eg. how powerfull Durable Objects is).

PS. A big outage is a long time ago... ( we use them, I remember the issues those days and the post mortem, a lot became more stable as far as I noticed).

When it came time to launch (2023?), the initial setup was using DNS/Cache, Workers, Workers KV, R2, D1, Durable Objects, Access, and Queues.

My first hint was that the Typescript library to access their API was simply just wrong. API requests through the library would fail, complaining about missing fields or invalid types, even though the types said my construction was correct, and I received dismissive replies when raising it in their Discord.

Then there were the D1 issues with random requests failing.

Then there were the Durable Objects issues with syncing clients in our collaborative editor.

Then there were the KV and (by extension) Access outages.

Eventually it made sense to switch it all over to AWS. Today, I trust Cloudflare for DNS, Cache, DDoS protection, and not much else.

The "AI psychosis" that may or may not have infected Cloudflare and caused this reminds me of Github's, except Cloudflare has a much much bigger moat.

This is the kind of naive thinking that enabled what's going on today. Sadly, the decentralized Internet is now destroyed and will never exist again.

They want to eat at the AI table, given that they are not producing models or GPUs and not building datacentres, they try with the product. But we are still in the early stage so it's not clear what will work and what not, so they have to try as much as possible.

> They got D1 (SQLite serverless), Durable Objects with their own SQLite, KV, R2, Queues, and Hyperdrive to speed up external Postgres or MySQL.

Maybe it's just me, but I don't see this as confusing:

- D1 is SQLite on cloud, their go-to relational database

- Durable object is the cousin of durable execution (via actor model instead of saga)

- KV is for caching like Redis (sub-ms read latency)

- R2 is S3, R2 SQL is Iceberg + Athena (for OLAP queries)

- Queue is SQS

- Hyperdrive is bridge to allow CF worker to use native Postgres/MySQL driver (since v8 isolate cannot maintain persistent connection)

I've built some stuff on top of CF, and the data ecosystem is actually useful.