How I fell in love with Cloudflare

I didn't fall in love with Cloudflare because of Cloudflare.

That's probably the first thing I should explain.

I didn't wake up one morning, look at a pricing page, and think, Finally. A platform that understands me.

That's not how these things work.

I fell in love with Cloudflare slowly.

It happened after years of building websites the old-fashioned way.

• Servers.
• Databases.
• Control panels.
• Plugins.
• Backups.
• CDNs.
• DNS providers.
• Hosting accounts.
• Little monthly charges that somehow multiplied when you weren't looking.

And, of course, the inevitable email from a hosting company telling me that something had become "resource intensive."

Apparently my website had the audacity to have visitors.

For most of my career, infrastructure was something I tolerated.

It was the plumbing underneath the business.

You didn't think about it when it worked, and when it didn't work, you lost an afternoon.

Then Cloudflare started changing my mental model.

Not all at once.

But enough that I eventually realized something had happened.

I had stopped thinking about servers.

And that was when I knew I was in trouble.

Because once a technology makes an entire category of problems disappear from your brain, going back is difficult.

I have spent too much of my life managing servers

I've been building websites for a long time.

Long enough to remember when putting a website online felt like an accomplishment in itself.

You bought hosting. You pointed DNS somewhere. You uploaded files. You created a database. You installed WordPress.

Then you waited. And waited. And eventually the thing appeared.

There was something satisfying about it. You could almost hear the machinery running.

• Apache was running.
• MySQL was running.
• PHP was running.
• Cron was running.

Your server was sitting somewhere, probably in Virginia, quietly waiting for somebody to visit your website.

And then people did. Which was where the fun began.

Because websites aren't really websites. They're little distributed systems pretending to be documents.

Traffic spikes. Bots crawl. Plugins break. Databases grow. Someone uploads a 14MB image. Someone else installs a plugin that executes seventeen queries every time someone loads the homepage. Googlebot decides today is the day it wants to crawl everything you've ever published.

And suddenly your $20/month server is sweating.

So you upgrade. Then you upgrade again. Eventually you're paying hundreds of dollars for infrastructure that exists primarily to make sure the infrastructure doesn't fall over.

I've done this for years. I've managed servers. I've configured DNS. I've moved websites. I've debugged caching. I've dealt with SSL certificates. I've configured CDNs. I've stared at logs at unreasonable hours.

And I've learned a very important lesson: I don't actually want to own infrastructure. I want infrastructure to disappear.

The first thing Cloudflare changed was DNS

Cloudflare initially seemed almost boring.

DNS isn't sexy. Nobody tells their friends about an exciting DNS provider.

“Hey, what are you doing tonight? Probably configuring my authoritative nameservers.

No.

But Cloudflare's DNS experience was different. It was fast. It was simple. It was everywhere.

And gradually, Cloudflare became the thing sitting in front of everything. DNS. SSL. Caching. Security. CDN.

Suddenly the internet looked a little different from my side of the desk.

Instead of browser, then server, it became browser, then Cloudflare, then whatever the hell I was running behind it.

Browser
   ↓
Cloudflare
   ↓
Whatever I was running behind it

That distinction turned out to be enormous.

Because once Cloudflare was in front of the application, the server stopped being the center of the universe.

That was the beginning.

Then I started thinking about Workers

Workers were where things got weird.

The idea was simple enough. Write some JavaScript. Deploy it. Run it at the edge.

• No server.
• No operating system.
• No SSH.
• No Docker container you have to babysit.
• No machine sitting there waiting for something to happen.

You write code. Cloudflare runs it.

That sounds trivial. It's not. Because removing the server changes what you build.

If you've spent twenty years thinking, Where should I host this? you eventually start asking, Why does this need hosting at all?

That's a much more interesting question.

A surprising number of applications don't need a traditional server. They need a little piece of logic. Authentication. A redirect. An API endpoint. A webhook. A form submission. A proxy. A small database operation. A request that needs to be transformed. A little bit of computation. A response.

That's it.

And Workers are very good at little bits of computation.

The architecture started getting smaller

This is probably my favorite part.

My applications started getting smaller. Not necessarily in terms of lines of code. In terms of things I had to care about.

That's a different kind of simplicity.

There's a difference between "this application has 37 files" and "this application requires 11 services to operate."

The second number is the one that matters.

A traditional web application might look something like this.

Browser
   ↓
CDN
   ↓
Load balancer
   ↓
Web server
   ↓
Application server
   ↓
Database
   ↓
Redis
   ↓
Background worker
   ↓
Object storage

None of these things are individually unreasonable. That's the problem. They're all reasonable. And suddenly you've built a small government.

Every service has credentials. Every service has configuration. Every service has a bill. Every service has documentation. Every service has an outage page. And every service becomes something you need to understand.

Cloudflare made me wonder whether the architecture could instead be this.

Browser
   ↓
Cloudflare
   ↓
Worker
   ↓
Storage

That's not always possible. But it's possible surprisingly often. And when it is, it's beautiful.

I started falling for the constraints

There's a strange thing that happens when you work with a platform like Cloudflare. You start appreciating constraints.

This is counterintuitive. Developers usually want fewer constraints. More RAM. More CPU. Bigger databases. Longer execution times. More disk. More everything.

But constraints can be useful. They force you to ask better questions.

• Does this really need to happen here?
• Does this really need to happen synchronously?
• Does this really need to be stored in a database?
• Does this really need to exist at all?

Those are good questions. Cloudflare encourages them.

Then came Analytics Engine

This is where my relationship with Cloudflare became more serious.

I started playing with Analytics Engine. And suddenly I could build analytics systems without immediately reaching for Postgres.

That sounds like a small thing. It isn't.

If you've built analytics before, you know what happens. Someone says, let's track pageviews. Easy. Then unique visitors. Fine. Then sessions. Okay. Then referrers. Sure. Then countries. Fine. Then browsers. Fine. Then devices. Fine. Then historical reports. Okay. Then: what happened on September 14th between 2:00 and 4:00 PM?

And suddenly you've built a data warehouse.

The beautiful thing about analytics is that the data is mostly append-only. A visitor happened. A pageview happened. A click happened. A conversion happened. You're not constantly editing rows. You're recording events.

That is a very different problem from running an ecommerce database. And Cloudflare's analytics infrastructure starts to make much more sense when you think about the problem that way.

I started asking a different question

Instead of asking, what database should I use? I started asking, what kind of data is this?

That's a much better question.

• If it's application state, maybe I want a database.
• If it's configuration, maybe I want KV.
• If it's files, maybe I want R2.
• If it's events, maybe I want Analytics Engine.
• If it's computation, maybe I want Workers.
• If it's authentication, maybe I want an external identity provider.
• And if it's something that needs to happen asynchronously? Queue it.

This is what I mean when I say Cloudflare made me fall in love with architecture again. It wasn't just giving me tools. It was making me think about what the tools were actually for.

I became increasingly suspicious of servers

There's a point where you start seeing servers everywhere. And then you start wondering why they're there.

Someone tells you, we're going to deploy this application on a VPS. And your first instinct becomes, why?

Not because VPSs are bad. They're fantastic. I've used them. I'll probably use them again. But because "we need a server" is often an assumption rather than a requirement.

A server is a wonderful solution when you actually need a server. But if your application consists primarily of receive a request, check something, do something, return a response, then perhaps you don't need a server.

receive request
check something
do something
return response

Perhaps you need a function. And perhaps that function should live close to the person making the request.

That's the edge.

The edge is more interesting than it sounds

"The edge" has become one of those technology words that can sound like marketing nonsense. But the underlying idea is simple.

The internet is global. Your users are global. Your application shouldn't necessarily live in one building on one continent.

Cloudflare has built a massive network around the world. So instead of sending every request back to one server somewhere, you can execute logic much closer to the user.

That matters. Not because milliseconds are sacred. But because architecture starts to change when geography stops being such a constraint.

A website in Manila doesn't need to think like a website hosted in Virginia. A customer in London doesn't need to wait for your application to take a scenic tour across the Atlantic. And a tiny API endpoint doesn't need a dedicated machine sitting in a datacenter waiting patiently for requests.

The network itself becomes part of the application. That's a profound shift.

The best part is that it gets boring

This might be the strangest compliment I can give Cloudflare.

It gets boring. And boring software is wonderful.

• I don't want to wake up and think, I wonder if my Redis cluster is healthy.
• I don't want to think, did the certificate renew?
• I don't want to think, why is nginx returning 502?
• I don't want to think, why did this server run out of disk space?
• I don't want to think, did the backup actually run?

I want to think about the product. I want to think about the customer. I want to think about the weird little problem we're solving.

Infrastructure should be boring. Cloudflare has helped me make it boring.

It also changed how I think about cost

There's another reason I like this architecture. The economics make sense for small businesses.

Traditional infrastructure tends to have a floor. You pay for the server whether anyone visits or not. You pay for database capacity whether you use it or not. You pay for infrastructure that might someday be necessary.

Cloud platforms increasingly let you pay for actual usage. That doesn't automatically mean cheaper. You can absolutely build an expensive Cloudflare application. Please don't interpret this article as a suggestion that cloud pricing is magical. It isn't.

But the economics can align beautifully with small software businesses. If you have 100 customers today and 100,000 customers someday, your infrastructure can grow with you.

That's a very different mental model from buying enough hardware for your imaginary future.

I'm particularly interested in this for tiny SaaS companies

I've become increasingly convinced that the best small software companies aren't necessarily the ones with the most sophisticated infrastructure. They're the ones with the least unnecessary infrastructure.

Imagine a tiny analytics company. Two founders. No venture capital. A few thousand customers. They don't need Kubernetes. They don't need twelve microservices. They don't need a team of infrastructure engineers. They need a product that works.

Maybe the entire system is Cloudflare, Workers, Analytics Engine, R2, a small database, authentication, and a frontend.

Cloudflare
Workers
Analytics Engine
R2
A small database
Authentication
A frontend

That's enough to build something serious. And because the underlying network is already enormous, the company doesn't have to become an infrastructure company by accident.

That's incredibly empowering.

This is where Tarsier came from

At some point, all of these ideas collided for me.

I started thinking about building analytics software. Not enterprise analytics. Not another giant dashboard with 400 buttons. Something small. Fast. Private. Affordable. A little bit delightful.

And I wanted the architecture to reflect that.

That's when the Tarsier idea started to make sense. A tiny analytics product running almost entirely on Cloudflare. The tracker lives at the edge. Events go into an analytics system designed for events. Historical data can live cheaply in object storage. The dashboard can be cached. The application can run without maintaining a fleet of servers. And AI can sit on top of the data and actually explain what happened.

Suddenly the architecture wasn't just infrastructure. It became part of the product philosophy.

I don't want to build another Google Analytics

There are already plenty of analytics platforms. Some are enormous. Some are beautiful. Some are incredibly powerful. Some are privacy-focused. Some are cheap.

I don't need another dashboard that tells me your website received 1,284 visitors. That's not particularly interesting.

“Traffic was up 23% this week, mostly because three articles started getting shared on Reddit. Your pricing page received 41% more traffic, but conversions didn't increase.

That's useful. And if the system can answer why, without me opening seven reports, that's even better.

Cloudflare makes the underlying architecture for that kind of product surprisingly accessible.

The more I use it, the less I want

That's probably the real reason I fell in love with it.

I want less. Less infrastructure. Less configuration. Less code. Less administration. Less maintenance. Less stuff to break. Less money spent before the first customer arrives. Less cognitive overhead.

More product. More experimentation. More time. More room for weird ideas.

That's what good infrastructure should do. It should give you less to think about.

There's a lesson here about building businesses

I've spent a lot of time thinking about small businesses. And one idea has stayed with me more than any other.

“Bigger is not better. Better is better.

Growth is not a strategy. Growth is a tactic. Sometimes.

The business world loves to treat growth as the point of everything. More customers. More employees. More revenue. More offices. More everything.

But more of what? More complexity. More meetings. More payroll. More things that can break.

Growth has a cost. And the cost is usually paid in the thing that made the business worth building in the first place: your time, your focus, your sanity.

There's another way. You can build something useful. You can keep it small on purpose. You can ask, at every turn: do I actually need more?

Usually the answer is no.

What you need is enough. Enough customers to sustain the business. Enough revenue to pay yourself well. Enough product to solve the problem. Enough.

Then you can stop optimizing for more and start optimizing for better. Better product. Better customers. Better days.

Technology should give you leverage, not homework

That's probably the simplest way I can describe my relationship with Cloudflare now.

I don't want technology that gives me homework. I want technology that gives me leverage.

There's a difference.

A VPS gives you a server. Cloudflare can give you a network. A database gives you tables. Analytics Engine can give you an event stream. A CDN gives you caching. Workers give you execution. R2 gives you storage. Queues give you asynchronous work.

And all of these pieces can fit together without requiring you to build the underlying planet yourself.

That's powerful.

I still like servers

This isn't a manifesto against servers. Servers are great.

There are applications where a traditional server is exactly what you want. There are workloads where you want persistent processes. There are databases that belong on dedicated infrastructure. There are applications where having full control is worth every ounce of complexity.

I'm not religious about technology. That's another thing I've learned after doing this for a long time. Every abstraction is a tradeoff.

Cloudflare has simply given me a set of tradeoffs I increasingly like.

The funny thing about falling in love with infrastructure

You don't actually want to think about it. That's how you know it's working.

I used to spend a lot of time thinking about where my software lived. Now I mostly think about what my software does.

That's a much better use of my time.

And perhaps that's the real reason I fell in love with Cloudflare. It didn't make me excited about servers. It made me stop caring about them.

It let me take a messy collection of infrastructure problems and turn them into something much smaller.

Build the thing.
Deploy the thing.
Let people use the thing.

Then go back to building.

That's a pretty good deal.

And after twenty years of building things on the internet, I've become increasingly convinced that the best technology isn't necessarily the technology that lets you build the most complicated system.

It's the technology that lets you build something simple enough to understand, cheap enough to operate, fast enough to delight people, and boring enough that you can forget it exists.

That's what Cloudflare has become for me. Not a hosting company. Not a CDN. Not a collection of developer products. A way of thinking about software.

And once you start thinking that way, it's surprisingly hard to go back.