The death of cloud centralization: Last decade’s internet had a gravity problem

Why workloads are fragmenting, edge is rising, and centralized cloud is quietly unraveling

I used to think cloud centralization was the cheat code.

Just deploy everything to us-east-1, toss it behind an API Gateway, slap a global CDN on top, and call it scalable. That’s what all the blog posts said, right?

“Don’t worry about infra. Just use the cloud.”

But somewhere between the $400 surprise bill, the cold starts, the 500ms latency to users in Singapore, and my fifth “is this region down?” panic spiral… I started to wonder:

Is this what modern infrastructure is supposed to feel like?

Turns out, the cloud didn’t break.
It just stopped fitting.

Apps got faster.
Users got global.
Data got sensitive.
And latency? Well, latency became the new error budget.

So now, everyone from indie devs to Big Tech is quietly rethinking the default. Not ditching the cloud entirely. But splintering it. Reshaping it.
Making it local again.

This isn’t another “serverless is dead” rant.
It’s about why the centralized cloud is unraveling and what we’re building instead.

What You’ll Learn in This Article

This post is for devs who’ve ever deployed to a distant region and regretted it.

• Why cloud centralization made sense in the 2010s and why it’s falling apart now
• Real-world examples of teams shifting away from giants like Shopify, Netflix, and Tesla to developer-loved tools like Raycast, Fathom Analytics, and Tailscale that are scaling without going all-in on centralized cloud
• The rise of edge, hybrid, and “closer-to-the-user” infrastructure
• The cost, latency, and legal traps of centralized regions
• What a modern stack looks like when cloud isn’t the only answer
• What this means for indie devs, SaaS teams, and you

Let’s get into it.

1: Why we centralized everything (and why it worked… for a while)

Let’s not rewrite history; the centralized cloud was a game-changer.

I’m talking about the golden era when you could:

• Set up an entire backend with 3 clicks and a .env file
• Forget what a firewall even is
• Say “scalable” in your pitch deck without actually knowing what autoscaling meant

Back then, cloud centralization made everything easier:

• One region. One provider. One mental model.
• No hardware. No racks. No 2 a.m. pager calls because some cooling unit failed in Frankfurt.

You didn’t think about “data locality” or “regulatory zones.”
You just picked us-east-1 because that’s where everyone else was and moved on.

Even now, there’s something comforting about having all your stuff in one place.
Your lambdas, your RDS, your S3 bucket of shame, all humming together in the cloud.

“It’s like a monolith, but distributed… and somehow still monolithic.”

1.1. So why did we love it?

Because it worked for what we needed then:

• MVPs that didn’t care about latency
• User bases mostly in North America
• Flat apps without complex data compliance
• Teams with one backend dev and three Post-it notes for infra docs

Centralized cloud lets us move fast and break prod with dignity.

1.2. And then… things grew up

Here’s what changed:

• Your users went global
• Your product needed sub-100ms responses
• Your database ballooned to “oh no” territory
• Your legal team sent you a “where’s our Canadian data?” email

Suddenly, that single cloud region started to feel like a bottleneck.

And not just a technical bottleneck but a cost bottleneck, a legal bottleneck, and a UX bottleneck.

“We scaled. And the cloud didn’t feel like magic anymore. It felt like a trap with a billing dashboard.”

TL;DR

Cloud centralization worked when the internet was smaller, simpler, and less regulated. But 2025 dev reality? That model is showing its age.

Press enter or click to view image in full size

Next: let’s look at who’s breaking away and why.

2. Real teams breaking up with centralization (but for real).

This isn’t hypothetical dev-talk; teams are genuinely shifting away from centralized cloud or avoiding it outright.

Not just the GPU-rich giants, but also indie tools and open-source favorites that developers actually use day-to-day.

2.1. Basecamp: “We can save millions off AWS.”

Basecamp (the remote-work project management app) made a high-profile move in the early 2020s:

Basecamp exited AWS and GCP, pulling most workloads into its own collocation facility.
They cited predictable budgets, simpler setup, and cost savings millions of dollars over time. (source)

Basecamp: After using clouds from both Amazon and Google extensively over the past 15 years, we finally had enough of the outrageous bills and the ever-increasing complexity. So in 2023, we pulled Basecamp, HEY, and five other heritage apps out of AWS and onto our own hardware — without adding any new staff.

The bottomline:

Leaving the cloud will save us
~$10 million over five years.

They literally built their own infrastructure stack to avoid cloud surprise bills, latency, and lock-in. For them, centralization became unnecessary baggage.

Here, you can read the FAQ coverage by 37signals’ DHH (David Heinemeier Hansson), which explains the operations related to their cloud exit, including hardware, team, and savings.

Their savings:

Press enter or click to view image in full size

2.2. Dropbox: From cloud-native to homegrown infrastructure.

Dropbox initially ran on AWS but not anymore.

They moved about 90% of their data off the cloud, back onto self-managed data centers, and reduced their annual costs by roughly $75 million.
It wasn’t nostalgia; it was numbers. (source)

For Dropbox, internet-scale file storage made on-prem efficiency competitive again.

2.3. Indie devs you actually know and love.

These indie tools didn’t just stay small they scaled smart by avoiding cloud centralization from the start:

• Fathom Analytics: Privacy-first GA alternative using Fly.io for edge-aware infrastructure and consistent global latency.
• Raycast: A dev tool that’s local-first, with optional cloud syncing built for trust and speed.
• Plausible: Lightweight analytics choice; easy self-hosting or simple, region-agnostic cloud from day one.
• Cal.com: Open-source booking tool using an edge/hybrid architecture to keep latency low and vendor lock-in minimal.

No massive teams. No $100M migrations. Just engineering-minded product builders who cared more about control and speed than centralized cloud status.

2.4. Pattern: Hybrid, local-first, fragmented.

There’s a clear theme:

• Cloud centralization isn’t a death sentence. it’s just not always the optimal default. Teams are asking critical questions:
• Which endpoints must be fast?
• What must comply with regional data laws
• Which workloads cost too much in egress & compute?

They’re composing infrastructure based on locality, cost, and compliance, not convenience.

TL;DR

Basecamp and Dropbox cut the cloud to save money and simplify operations.
Indie apps like Fathom, Raycast, Plausible, and Cal.com thrived by building distributed, edge-aware backends.
The trend? Not ditching the cloud it’s deciding what you actually need it for.

3: The hidden costs of centralization

On paper, centralized cloud looks clean:

• One region = easier setup
• One provider = fewer moving parts
• One bill = wait, why is it $847.32 this month?

You don’t notice the cost of centralization when you start.
You notice it when your app launches in Europe, your users are in Asia, and your cloud provider is still emotionally attached to us-east-1.

3.1. Latency: The invisible tax

Your app feels fast in dev.
Then a user in São Paulo clicks “checkout” and your /api/confirm call takes 450ms plus a retry.

Why?

Because your entire backend lives in Virginia.
And your user… doesn’t.

“You’re shipping modern UI with medieval routing.”

Every round-trip adds milliseconds. Milliseconds kill conversions.
And once you care about sub-100ms UX, centralization becomes your enemy.

Press enter or click to view image in full size

3.2. Surprise billing (a.k.a. “How I learned to fear egress”)

You didn’t think downloading a few profile images could break the budget.
But then egress charges showed up like:

“Oh hey, you moved 90GB from your bucket to the edge. That’ll be $61.23. Plus tax. Plus emotional damage.”

And that one ML job you ran for a weekend?
Double digits. Not in inference speed. In dollars-per-hour.

3.3. Cold starts + region lock-in

Lambda was fun until you realized it comes with cold starts, execution time caps, and API Gateway weirdness that only shows up in prod.

Centralized regions often can’t spin your functions close to the user.
And when they do? You’re juggling 12 regions manually, with IAM policies that feel like a Final Fantasy questline.

3.4. Data gravity: Once you’re in, you stay in

The more data you store in a centralized cloud, the harder it becomes to leave.

Not legally. Physically. Financially. Mentally.

• Exporting TBs? Get ready for transfer fees.
• Hosting backups in multiple regions? More fees.
• Moving to another provider? Hope your CEO likes PDFs of S3 billing dashboards.

“Centralized cloud isn’t a prison. It’s just a really expensive Airbnb you never check out of.”

3.5. Legal + compliance nightmares

Europe wants data in Europe.
Canada wants their own region.
India doesn’t want you to decide at all.

If your centralized region isn’t compliant by location, purpose, or policy, congratulations: you’re now a part-time data lawyer.

TL;DR:

Centralized cloud feels simple… until it’s not.

• Latency slows you down
• Bills start to spike
• Legal flags show up
• You’re too far from users
• And somehow you’ve created a distributed monolith anyway

Spoiler: Scaling across regions is harder when you start centralized.

4: What the modern internet stack actually looks like

Let’s be real, we’re not all running billion-dollar ML pipelines. But we are building apps that need to feel fast, stay global, and not bankrupt us by month three.

So what does the smart, post-centralization stack look like in 2025?

4.1. The new blueprint: composable and hybrid infrastructure

Forget “pick a cloud.”
The real strategy is compose per need:

Press enter or click to view image in full size

This isn’t fantasy. It’s what indie devs and agile teams are actually using right now.

4.2. From “Region-First” to “User-First”

Old Way (2016–2020)

Centralize on AWS us-east-1
Accept latency + surprise billing
Lock in with managed services

2025 Stack

• Static assets served via CDN in 300+ cities
• Functions run 5ms from the user.
• Auth + sessions at the edge
• Hybrid compute spans cloud, colo, and edge
• Data flows via smart syncs, not dumb mirrors

This isn’t about abandoning cloud.
It’s making cloud work per context.

4.3. Why hybrid isn’t just for enterprises anymore

“Hybrid cloud” used to mean running SAP in a private cloud and syncing it with AWS.

Now it means:

• Edge logic + cloud backend
• Data stored locally, but backed up to object storage
• Compute happening near users, not just near your billing department

Even smaller teams are pulling this off using:

• Cloudflare + Supabase
• Vercel + Fly.io + S3
• Azure Static Web Apps + PostgreSQL Flexible

Hybrid is what you do when you want scale, speed, and control — not just one of them.

4.4. When centralized cloud still wins

We’re not here to dunk on AWS. In fact, centralized cloud still makes sense for:

Training LLMs or hosting GPU-heavy workloads

Running compliance-sensitive apps with ISO/SOC2 guarantees

Using mature managed services (e.g., RDS, Cloud Run, S3 Glacier)

Massive regional deployments with predictable traffic

But what changed is that it’s no longer the only viable path.

TL;DR:

Cloud in 2025 isn’t dead, it’s decentralized.

• Use cloud where it shines: scale, ML, mature APIs
• Use edge where speed and proximity matter
• Use hybrid to get the best of both
• Use multi-cloud if you’re not allergic to YAML

Don’t pick a cloud. Compose a system.

5. What to ask before you deploy anything

Here’s your checklist:

• Where are my users? Not where I live. Where they do.
• What needs to be fast? APIs, auth, dashboards, checkouts? Make those edge-first.
• What can tolerate latency? Backups, logs, internal tools? Cloud it up.
• What will explode my bill? Egress? GPU inference? Cold starts? Check and mitigate.
• What are the legal traps? GDPR? India’s DPDP? Canada’s data residency? Plan for it now, not after the audit.
• What will be hard to move later? Design for escape hatches. Multi-cloud or vendor-agnostic infra pays off.

5.1. Final Thought:

The cloud didn’t fail.
It evolved.
And smart devs evolved with it.

Today, you don’t just deploy to a region.
You deploy to wherever your users actually are.

Not because it’s trendy.
But because it’s the only way the modern internet makes sense.

Built something cool with edge or hybrid infra?
Tag us. Share it.
Or send us your us-east-1 breakup story we’ll pour one out together.

Press enter or click to view image in full size