Is the Internet Really Decentralized? | 🎙️#69

Orange background with "DevOps Accents Episode 69" and "Is the Internet Really Decentralized?" text. Illustration shows a vintage microphone with an orange cloth and a laptop displaying "<3" on screen.
Last updated: | Published:

The internet is “decentralized”… until one cloud provider has a bad day. This time on DevOps Accents, Leo, Pablo, and Kirill break down where decentralization actually exists, where we’ve centralized by convenience, and why outages feel inevitable in today’s cloud-driven world. In this episode:

  • What “decentralized internet” really means — protocols vs. reality
  • Why major outages (Cloudflare, AWS, DNS) expose hidden centralization
  • Single points of failure: clouds, CDNs, certificate authorities, and power grids
  • From infrastructure to geopolitics: how political borders affect the internet
  • Disaster recovery trade-offs: cost, downtime, and realistic expectations for teams
  • Practical advice: how much resilience is enough — and what not to blindly trust

You can listen to episode 69 of DevOps Accents on Spotify, or right now:


The internet is often described as decentralized, resilient, and almost impossible to shut down. In theory, that idea still holds. In practice, though, everyday experience tells a different story: a single outage at a major cloud provider or platform can knock out huge parts of what people think of as “the internet.”

This tension between theory and reality was unpacked from several angles, with Kirill, Pablo, and Leo each highlighting different layers of the problem—from foundational protocols to human behavior and business trade-offs.

What emerges is a clearer picture: the internet is decentralized at its core, but heavily centralized at the layers we rely on most.


Protocols Are Decentralized, Convenience Is Not

Kirill made an important distinction early on: the foundational technologies of the internet were designed to be decentralized. DNS, routing, and networking don’t rely on a single server or a single country. Root DNS servers are geographically distributed, aggressively cached, and intentionally difficult to take down all at once. Even if one fails, the system keeps working for a long time.

From a technical standpoint, this is still a beautifully engineered system.

The problem starts higher up the stack. Modern applications don’t interact directly with raw internet protocols. Instead, they sit on layers of cloud platforms, CDNs, certificate authorities, authentication systems, and managed services. These layers exist for good reasons: they’re fast, global, and convenient. But they are also operated by a small number of private companies.

As Kirill pointed out, when a bug or misconfiguration happens at that level, it can instantly affect a significant percentage of the internet—not because the internet itself failed, but because so many services pass through the same chokepoints.


Outages Feel Bigger Than They Are (But the Damage Is Real)

Pablo added a human perspective that explains why these outages feel so dramatic. When platforms like social networks or messaging apps go down, people notice immediately—not because civilization has stopped, but because their daily digital habits are interrupted. No feed, no scroll, no dopamine.

That visibility creates a distorted perception: it feels like “the internet is down,” even though many lower-level systems are still functioning. At the same time, Pablo emphasized that there are far more serious consequences hiding beneath the surface. When infrastructure fails, it’s not just entertainment that disappears—payments stop working, hospital systems struggle, public services go offline, and businesses lose money by the hour.

The issue isn’t just that everything is interconnected. It’s that these interconnections often aren’t obvious until something breaks.


Centralization by Design, Not by Accident

Leo framed the problem with a simple but powerful analogy: instead of many small roads, we’ve built a few massive highways. They’re incredibly efficient—until one of them closes.

Kirill expanded on this by explaining how modern platforms like global CDNs and edge computing systems work. These systems are massively distributed physically, with servers close to users all over the world. On the surface, that looks like decentralization. But behind the scenes, they are still controlled by a single software platform and a single operational authority. A failure in that control plane can bring every location down at once.

This isn’t because engineers made a mistake. It’s because centralization is the price we pay for speed, simplicity, and scale. The better these platforms get, the more attractive they become—and the more dependent everyone becomes on them.


Resilience Is a Business Decision, Not a Technical One

When the discussion turned to what teams can realistically do, Kirill was blunt: perfect resilience doesn’t exist, and chasing it blindly is pointless. Disaster recovery is always about trade-offs.

You can design systems that recover in hours, minutes, or seconds—but each step costs more money and more operational complexity. For most products, being down for a while is acceptable. For hospitals, banks, or payment systems, it isn’t. The difference isn’t technology; it’s how much downtime the business can afford.

Pablo reinforced this with a practical lens: resilience is ultimately tied to budget. Spending enough can get you closer to “five nines” of availability, but nothing ever reaches 100%. At some point, you’re not engineering reliability—you’re paying for peace of mind.


The Real Risk: Blind Trust in Single Providers

The strongest takeaway came near the end. Kirill warned against betting everything—personal or professional—on a single provider. Not because any one company is bad, but because their importance makes them dangerous to trust blindly.

On a personal level, that means backing up data across multiple platforms. On a company level, it means understanding where true single points of failure exist—not just technically, but politically and legally as well. Cloud centralization isn’t only an engineering risk; it’s also tied to jurisdiction, regulation, and geopolitics.

Leo summed it up simply: the internet didn’t lose its decentralization. We outsourced it.


A More Realistic Way to Think About the Internet

The internet is still decentralized where it matters most: its foundations. But the world built on top of it is optimized for convenience, speed, and scale—and those optimizations naturally pull things toward centralization.

The challenge isn’t to undo that reality. It’s to recognize it, plan around it, and avoid pretending that resilience comes for free.

Outages will happen. Dependencies will fail. The real question is whether you understand which ones matter most—and whether you’ve decided, consciously, how much risk you’re willing to accept.



Show Notes


Podcast editing: Mila Jones, milajonesproduction@gmail.com