The Internet Isn't Really Distributed, We're Just Pretending It Is.

The internet looks decentralized from the outside.

There are billions of devices.

Millions of websites.

Countless apps.

Thousands of companies.

Servers scattered across the planet.

It feels almost impossible for one company to break a meaningful part of it.

And yet, sometimes one company has a bad morning and half the internet starts acting weird.

That contradiction is becoming harder to ignore.

We spent decades building the internet around decentralization, redundancy and distributed systems. Then we spent the last decade putting enormous chunks of the actual infrastructure underneath it into the hands of a surprisingly small number of companies.

AWS.

Microsoft Azure.

Google Cloud.

Cloudflare.

A handful of major telecom operators.

A handful of DNS providers.

A handful of content delivery networks.

A relatively small number of undersea cable systems.

The websites may be different.

The infrastructure underneath them often isn't.

THE CLOUD DIDN'T DESTROY THE INTERNET

The cloud was supposed to make infrastructure easier.

And, to be fair, it did.

You no longer need to buy a server, find somewhere to put it, configure networking, maintain disks, replace failed hardware and spend your weekend praying that the power doesn't go out.

You click a few buttons.

You get a server.

Need another one?

Click again.

Need a database?

There it is.

Need storage?

Take your pick.

Need a global network?

Somebody already built it.

This is one of the greatest productivity improvements in modern computing.

But there was a trade.

We exchanged the complexity of owning infrastructure for the complexity of depending on infrastructure.

And dependence is easy to ignore when everything works.

Until it doesn't.

THE NUMBERS ARE GETTING HARD TO IGNORE

The global cloud infrastructure market is now measured in enormous quarterly revenues, with the major providers continuing to dominate the market. Recent market data shows AWS, Microsoft Azure and Google Cloud maintaining a commanding lead over their competitors.

That concentration isn't automatically bad.

Large infrastructure companies can invest billions in data centers, networking, security, power systems and engineering teams that smaller providers simply cannot afford.

They can build in places most companies couldn't.

They can maintain redundant systems across continents.

They can hire people whose entire job is making sure your database doesn't disappear at 3:17 a.m.

There are very good reasons to use them.

The uncomfortable question is what happens when everyone uses them.

Because redundancy only works if your redundant systems aren't secretly the same system.

THE MULTI-CLOUD LIE

Every enterprise presentation eventually reaches the same slide.

“Multi-cloud strategy.”

It sounds responsible.

AWS for some workloads.

Azure for others.

Google Cloud somewhere else.

Maybe Oracle Cloud for that one weird enterprise system nobody understands anymore.

The architecture diagram looks beautiful.

Three clouds.

Lots of arrows.

Everyone nods.

Then you look at the actual infrastructure.

The database is in one provider.

The identity system is somewhere else.

The DNS is somewhere else.

The CDN sits in front.

The observability platform depends on another provider.

The payment system depends on a third party.

Your authentication provider has an outage.

Your application is technically running perfectly.

Nobody can log in.

Congratulations.

You built multi-cloud.

You just forgot to make the dependencies multi-cloud too.

THE INTERNET'S BIGGEST PROBLEM MAY BE WHAT YOU CAN'T SEE

This is what makes modern infrastructure so strange.

A user visits a website.

They see a website.

That's it.

They don't see the DNS provider.

They don't see the CDN.

They don't see the cloud region.

They don't see the identity provider.

They don't see the load balancer.

They don't see the certificate authority.

They don't see the database.

They don't see the undersea cable carrying their traffic halfway around the world.

They certainly don't see the thousands of decisions made by infrastructure engineers to make the whole thing look like one simple page.

The modern internet is an enormous stack of dependencies hiding behind a browser window.

And every dependency is another opportunity for something to go wrong.

THE OUTAGE DOESN'T HAVE TO HAPPEN TO YOU

Here's the part people underestimate.

You don't have to use a company's product directly for its failure to affect you.

Suppose your favorite application runs on Cloud Provider A.

You don't know that.

You don't care.

The application works.

Then Cloud Provider A has a major outage.

Now the application doesn't work.

Maybe your bank uses a different provider.

But its identity service depends on another company that depends on the same infrastructure.

Maybe your food delivery app is fine.

But its mapping provider isn't.

Maybe your messaging service is fine.

But its notification provider isn't.

Suddenly a failure that began inside one data center becomes something normal people experience as:

“Why is everything broken today?”

That's the strange thing about infrastructure.

The deeper it gets, the less visible it becomes.

And the less visible something is, the easier it is to build dependency on it.

THE CLOUD IS ALSO A BUSINESS DECISION

This isn't just an engineering story.

It's a money story.

Cloud infrastructure has become a massive recurring expense for companies of every size.

And once a company builds enough of its business around one provider, leaving becomes difficult.

Not impossible.

Difficult.

You have databases.

Storage.

Networking.

IAM policies.

Monitoring.

Deployment pipelines.

Internal tooling.

Developer knowledge.

Vendor-specific APIs.

Compliance controls.

Years of operational history.

The cloud provider isn't just hosting your application anymore.

It has become part of your company's architecture.

That is incredibly convenient.

It is also a form of lock-in.

And lock-in doesn't feel like lock-in when you're saving time.

It feels like productivity.

Until the day finance asks:

“Why would it cost us millions to move?”

THE EXIT DOOR IS OFTEN SMALLER THAN THE ENTRANCE

This is one of the most interesting problems with cloud computing.

Getting in is easy.

Getting out is another story.

You can provision infrastructure in minutes.

Moving petabytes of data can take considerably longer.

Rebuilding a production system somewhere else is not just a technical migration.

It is a business migration.

You have to test it.

Train people.

Rewrite infrastructure.

Rebuild observability.

Validate compliance.

Move data.

Change contracts.

Change processes.

And somehow keep the company running while doing it.

That's why “just move to another provider” is usually not serious advice.

The cloud made infrastructure disposable.

It didn't necessarily make businesses portable.

THE INTERNET HAS OTHER BOTTLENECKS TOO

Cloud is only one layer.

Look underneath it.

DNS.

A surprisingly small group of companies handles a huge amount of the internet's domain resolution.

Then there are content delivery networks.

Then backbone networks.

Then submarine cables.

Then internet exchange points.

Then mobile operators.

Then the physical data centers.

Then the electricity feeding them.

Each layer has redundancy.

But redundancy doesn't mean infinite independence.

Sometimes several different systems depend on the same physical or commercial bottleneck.

That's the part diagrams tend to hide.

You can have five different applications running on five different servers and still have one shared dependency capable of taking all five offline.

Distributed architecture can create the illusion of independence without actually creating it.

THE MOST DANGEROUS DEPENDENCY IS THE ONE EVERYONE HAS

Imagine there is a tiny company providing a boring service.

Nobody talks about it.

No one puts it on a conference stage.

Nobody writes “the future of technology” articles about it.

But thousands of companies depend on it.

That company might be handling authentication.

Or DNS.

Or certificate issuance.

Or payments.

Or package distribution.

Or some obscure API.

Everything works.

Until it doesn't.

This is why infrastructure engineers worry about common-mode failures.

You can have redundancy everywhere and still fail if every redundant component shares the same underlying assumption.

Five applications can be hosted in five regions.

If all five rely on the same DNS provider, you don't have five independent systems.

You have one system with five customers.

That's a very different risk profile.

WE HAVE BEEN OPTIMIZING FOR EFFICIENCY

This is probably the bigger story.

Modern technology has become extremely good at efficiency.

Don't own hardware if you can rent it.

Don't maintain infrastructure if someone else can.

Don't duplicate systems unnecessarily.

Don't keep spare capacity sitting idle.

Don't build a service when an API exists.

Don't run your own data center if a cloud region can do it.

All of these ideas make sense.

They save money.

They reduce engineering work.

They make startups possible.

They let small companies build things that once required entire IT departments.

But resilience and efficiency are not always friends.

Keeping a backup system that nobody uses is inefficient.

Until the primary system fails.

Maintaining your own infrastructure is expensive.

Until your provider has a prolonged outage.

Running two independent vendors is annoying.

Until one vendor becomes unavailable.

Keeping copies of data in different places costs money.

Until one location disappears.

Resilience is basically paying for things you hope you never need.

And companies hate paying for things they hope they never need.

THE INTERNET HAS ALWAYS BEEN A LITTLE FRAGILE

None of this means the internet is about to collapse.

Quite the opposite.

The internet is extraordinarily resilient.

It was designed to survive failures.

Packets can take different paths.

Networks can reroute.

Systems can replicate.

Data can be copied.

Traffic can move.

Engineers are very good at this stuff.

The problem is that the internet has evolved.

The original distributed-network philosophy is now sitting underneath a massive commercial infrastructure layer.

And commercial infrastructure naturally creates concentration.

Scale creates efficiency.

Efficiency creates adoption.

Adoption creates dependency.

Dependency creates lock-in.

Lock-in creates concentration.

And concentration creates a new kind of risk.

The irony is almost too neat.

We built distributed computing.

Then we centralized the boring parts.

WHY THIS MATTERS MORE THAN IT SOUNDS

This isn't just a concern for cloud architects.

It affects almost everybody.

If you're a startup, your infrastructure decisions can determine how expensive your company becomes to move.

If you're a developer, your architecture determines how badly an outage can hurt you.

If you're a founder, infrastructure concentration becomes a business continuity question.

If you're a government, it becomes a digital sovereignty question.

If you're a consumer, it determines whether the services you depend on work when somebody else's infrastructure doesn't.

And if you're running a critical service, it becomes a safety issue.

The more of society moves online, the more infrastructure stops being “tech infrastructure” and starts becoming infrastructure in the normal sense of the word.

Electricity infrastructure.

Transportation infrastructure.

Telecommunications infrastructure.

The boring stuff that nobody thinks about until it stops working.

THE NEXT INTERNET WON'T NECESSARILY BE MORE DISTRIBUTED

This is the part I find most interesting.

The obvious assumption is that technology eventually decentralizes again.

Maybe.

But there is another possibility.

The infrastructure becomes even more concentrated because the economics make it almost impossible for smaller providers to compete.

Cloud gets bigger.

Data centers get bigger.

Networks get bigger.

Companies buy more infrastructure.

The largest providers become more efficient.

Their prices become more competitive.

More customers move to them.

And the cycle continues.

At some point, the question stops being:

“Can I build my application on the cloud?”

Of course you can.

The better question becomes:

“How much of my business am I comfortable building on somebody else's infrastructure?”

That is a very different question.

And it is one more companies should probably ask before their first major outage.

THE BORING INFRASTRUCTURE IS THE IMPORTANT INFRASTRUCTURE

Technology culture has a funny habit.

We celebrate the visible layer.

The new phone.

The new app.

The new social network.

The beautiful interface.

The clever feature.

The viral product.

Meanwhile, underneath all of it are racks of computers, fiber cables, DNS servers, power systems, cooling systems, routers and databases quietly doing their jobs.

Nobody takes screenshots of them.

Nobody posts them on social media.

Nobody calls them revolutionary.

But when they stop working, everyone suddenly remembers they exist.

That is why the next phase of internet infrastructure should not be judged purely by how cheap or convenient it is.

It should also be judged by how much failure it can absorb.

Because the internet isn't actually one giant machine.

It is supposed to be millions of machines cooperating.

The danger is that we keep making those machines easier to manage until we forget how many of them depend on the same few foundations.

And if that happens, the internet can remain technically distributed while becoming economically centralized.

That distinction matters.

A lot.

Because the next big infrastructure failure probably won't teach us that the internet is fragile.

It will teach us how concentrated it had quietly become.