DEV Community: Rengaswamy Marimuthu

The Great Centralisation: History of the internet is a tragedy in Four acts

Rengaswamy Marimuthu — Sat, 06 Dec 2025 22:30:23 +0000

The Great Centralization: History of the internet is a tragedy in Four acts.

The internet was born not by chance, nor as a startup venture seeking funding, but as an essential mechanism for survival.

During the nuclear tensions of the 1960s and 70s, brilliant minds like Paul Baran, Vint Cerf, and Bob Kahn faced a critical challenge: How could a communication network be engineered to remain operational even if half its infrastructure were obliterated?

Their groundbreaking solution was the "mesh" network with no central point, no single master switch, and no head. Data was rerouted seamlessly; It was built for resilience.

Yet, five decades on, this miracle of decentralization is largely managed by a few powerful corporations in Seattle and Silicon Valley, often protected by a single proxy service. These are the three major incidents of this year that took down half of the internet.

December 5, 2025: Cloudflare pushed a routine update to their Web Application Firewall (WAF) to patch a minor React vulnerability.

The Mistake: A single logic error in the update code (a "killswitch" for a testing tool) triggered a bug that caused their servers to reject valid traffic.
The Blast Radius: Instantly, 28% of the world's HTTP traffic hit a wall. Zoom calls dropped mid-sentence. LinkedIn vanished. Coinbase users couldn't trade. Even Zerodha (India's largest broker) went dark.
The Lesson: It wasn't a nuclear bomb that took down the world's communication; it was a bad config file from one company in San Francisco.

November 18, 2025: The Cloudflare "Bad File" Blackout

What happened: A routine change to a database permission caused a configuration file for Cloudflare's Bot Management system to bloat in size. This "bad file" was pushed globally, instantly crashing the proxy software on every server in their network simultaneously.
The Impact: X (Twitter), ChatGPT, Spotify, Canva, and Discord all went dark at the exact same second.
The Lesson: We built a "decentralized" edge network, but we manage it with a centralized switch. One bad config file can brick the world's most popular apps.

October 20, 2025: The AWS "US-EAST-1" Collapse

What happened: A malfunction in a subsystem monitoring network load balancers in Northern Virginia (us-east-1) triggered cascading DNS failures.
The Impact: It took down 113 separate AWS services. The "blast radius" wiped out Snapchat, Roblox, Ring smart home devices, and banking apps globally.
The Lesson: We realized that us-east-1 isn't just a data center; it’s a single point of failure for 30% of the internet.

Furthermore, the very "revolution" intended as a safeguard—Web3—is now being acquired en masse by the same financial institutions it was designed to disrupt.

I. The Architects of the Unbreakable (1969–1995)

We often forget the sheer difficulty of the early internet. The engineers who built ARPANET (the precursor to the Internet) were working with hardware less powerful than a modern digital watch.

They weren't just writing code; they were inventing the laws of digital physics. They created TCP/IP (Transmission Control Protocol/Internet Protocol), a language that allowed any computer, of any make, to talk to any other computer without a middleman.

The ethos was "dumb network, smart edges." The network didn't care what you were saying or who you were; it just moved packets. Power resided at the edges—with the users.

The Dream: A global library where no book could be burned.
The Reality: To be online, you had to be a technician. You ran your own mail server. You hosted your own website on a box in your closet. You were free, but you were also responsible for everything.

II. The Convenience (The Web 2.0 Takeover)

As the internet grew, a friction point emerged: Freedom is exhausting.Managing your own server is hard. Security patches are annoying. If your hard drive fails, your data is gone forever.

Enter the giants. In the mid-2000s, Amazon (AWS), Google, and later Cloudflare offered the world a deal.

"Stop worrying about the hardware. Give us your data. We will host it, secure it, back it up, and serve it to the world faster than you ever could. All for pennies."

We took the deal and changed the topology of the internet.

The Hub-and-Spoke Disaster

We moved from a mesh network to a feudal system.

The Cloud: Today, AWS, Microsoft Azure, and Google Cloud control the vast majority of the world's backend infrastructure. If us-east-1 (an AWS region) has a hiccup, half the internet—from Netflix to your smart doorbell—stops working.
The Gatekeeper: Then there is Cloudflare. In our quest to stop DDoS attacks, we routed the world's traffic through one company's reverse proxies. Cloudflare sees, scrubs, and approves a massive percentage of global web traffic.

The engineers of the 70s worked to ensure no single nuclear bomb could kill the network. Today, a single bad configuration update at a data center in Virginia can take it offline. We traded resilience for convenience.

III. The Broken Promise of Web3 (The Infrastructure Lie)

Then came the rebellion. Bitcoin (2009) and Ethereum (2015) arrived with a promise to undo the centralization of Web 2.0.

"Web3 is permissionless. It runs on thousands of nodes. No one can shut it down. It is the return of the open internet."

But look under the hood of your favorite Decentralized App (dApp).

Where is the frontend hosted? Usually on AWS or Vercel. If Amazon shuts off the hosting, the "uncensorable" dApp vanishes from the browser.
How does the wallet talk to the blockchain? Your MetaMask wallet doesn't run a full Bitcoin or Ethereum node. It connects to the blockchain via RPC (Remote Procedure Call) providers like Infura (owned by Consensys) or Alchemy.
The Result: Most of Web3 relies on centralized APIs to function. If Infura decides to block IP addresses from a sanctioned country (which they have done), those users are cut off from the "decentralized" blockchain.

We built a decentralized ledger, but we access it through the same centralized doors we built in the Web 2.0 era.

IV. The Banker's Takeover

If the infrastructure centralization is disappointing, the financial capture is heartbreaking.

The genesis block of Bitcoin contains a hidden message: "The Times 03/Jan/2009 Chancellor on brink of second bailout for banks." Satoshi Nakamoto built Bitcoin specifically as a protest against the reckless gambling of institutional banks.

Fifteen years later, the "Cypherpunk" dream is dead. The "Institutional Grade" reality is here.

The ETF Trojan Horse

We cheered when the Bitcoin and Ethereum ETFs (Exchange Traded Funds) were approved. "Number Go Up," we said. "Mass Adoption," we said.

But look at who is buying:

BlackRock, Fidelity, and VanEck: These asset managers now hold billions of dollars worth of Bitcoin.
The Supply Crunch: As these giants vacuum up the supply, Bitcoin shifts from being a peer-to-peer currency to a pristine collateral asset for Wall Street. You aren't supposed to spend it; you're supposed to leverage it.

What about Proof-of-stake?

It is even worse on Proof-of-Stake networks like Ethereum.

To secure the network, you need to stake 32 ETH. Most people can't afford that, and the technical overhead is high (echoing the early internet server problem). So, users hand their ETH to Lido or Coinbase to stake it for them. The result is a massive percentage of all staked Ethereum is controlled by a handful of entities. If regulators pressure these entities to censor transactions, they have the market power to threaten the network's neutrality.

Conclusion: The Cycle Completes

The history of the internet is a tragedy in three acts.

Act I: Engineers work hard to build a free, survival-focused mesh network.
Act II: We handed the keys to Big Tech because we wanted faster video streaming and easier emails.
Act III: Greed took over our attempt to decentralize.
Act IV: We built a "decentralized" financial system to escape the banks, only to sell the coins to BlackRock because we wanted our portfolios to turn green.

We have arrived at a strange destination. We have "decentralized" protocols running on Amazon servers, funded by Venture Capitalists, and bought by Investment Banks.

Connect with me on Linkedin

Go: Stick to the Standard Library, Fill the Gaps with Chi, Zap, and Migrate

Rengaswamy Marimuthu — Fri, 05 Dec 2025 22:55:29 +0000

As a Go developer with significant experience in web development, I have seen the cycle repeat itself. New developers often jump straight into heavy frameworks like Gin or Beego, or reach for complex ORMs like GORM, thinking they need them to be productive.

I used to do the same. But over time, I realised that Go is different. The standard library is incredibly powerful, and adding "magic" usually just adds technical debt.

My philosophy for 2025 is simple: Stick to the Standard Library for the core, and use specialised libraries only to fill the gaps.

Here is the "Standard+Gap" stack I use to build production-ready services, and why I chose these specific tools over the alternatives.

1. The Core: Why I Reject Web Frameworks and ORMs

Before talking about the libraries I do use, let's talk about what I don't use.

HTTP Server: `net/http` vs. Frameworks

I don't use heavy HTTP frameworks to start the server.

The Reality: Go’s standard net/http is production-grade. It handles HTTP/2, timeouts, and cancellation contexts natively.
The Problem with Frameworks: Frameworks often wrap the http.ResponseWriter and http.Request in their own context objects. This breaks compatibility with the rest of the Go ecosystem and hides what is actually happening over the wire.

Database: `database/sql` vs. ORMs (GORM, Ent)

I stick to the standard database/sql (occasionally with sqlx for struct mapping).

The Cons of ORMs: ORMs promise speed but often deliver inflexibility. They rely on reflection (slow) and introduce "magic" behavior. Simple queries are easy, but complex joins or performance tuning become a nightmare of fighting the ORM's syntax.
The Pros of Standard Lib: SQL is the universal language of data. Using the standard library forces you to write efficient queries and gives you full control over database interactions.

2. Filling the Routing Gap: Chi

While net/http is great, its default request multiplexer (router) can be a bit basic for complex REST APIs. This is where I fill the gap.

My Choice: Chi

Why:
Chi is barely a framework; it's a router that is 100% compatible with net/http.

Pros: It uses standard http.Handler. It has zero external dependencies. Middleware integration is intuitive.
Cons: You have to handle your own JSON encoding/decoding (which I prefer, as it gives me control).

Comparison:

Gin/Echo: These are full web frameworks. They are faster in micro-benchmarks, but they lock you into their vendor-specific context. If you use Chi, your code is just "Go code."

3. Filling the Logging Gap: Zap

The standard log package is insufficient for modern observability. You need structured (JSON) logging for tools like Datadog or ELK.

My Choice: Zap

Why:
Zap is Uber's structured logger. It is obsessively optimized for performance.

Pros: Zero-allocation in hot paths. Extremely fast. Strongly typed fields prevent runtime errors in logs.
Cons: The syntax is verbose (logger.Info("msg", zap.String("key", "value"))).

Comparison:

Logrus: The old standard. It’s easy to read but slow and uses a lot of memory.
Slog: The new standard library addition. It is excellent and likely the future, but Zap currently has a larger ecosystem and battle-tested edge cases in high-load systems.

4. Filling the Migration Gap: Go-Migrate

Database schemas evolve. You need a way to version control your database.

My Choice: golang-migrate

Why:
It treats migrations as what they are: SQL files.

Pros: It supports almost every database driver. It keeps up and down migrations in plain SQL files, separating your DB logic from your Go code.
Cons: Error handling can be tricky; if a migration fails halfway, you often have to manually fix the "dirty" state in the schema table.

Comparison:

Goose: Goose allows migrations written in Go code. This is powerful for data backfilling, but for schema changes, I prefer the strict isolation of SQL files that go-migrate enforces.

This stack represents the "sweet spot" of Go development:

Server: Standard net/http (Reliable, Standard).
Database: Standard database/sql (Explicit, High Control).
Router: Chi (Fills the routing gap without locking you in).
Logs: Zap (Fills the observability gap with high performance).
Migrations: Go-migrate (Fills the versioning gap).

By avoiding bloated frameworks and inflexibility ORMs, you keep your Go applications readable, maintainable, and close to the metal.

What is your "Gap-Filling" stack? Tell me in the comments!

Connect with me on Linkedin

DEV Community: Rengaswamy Marimuthu

The Great Centralisation: History of the internet is a tragedy in Four acts

The Great Centralization: History of the internet is a tragedy in Four acts.

I. The Architects of the Unbreakable (1969–1995)

II. The Convenience (The Web 2.0 Takeover)

The Hub-and-Spoke Disaster

III. The Broken Promise of Web3 (The Infrastructure Lie)

IV. The Banker's Takeover

If the infrastructure centralization is disappointing, the financial capture is heartbreaking.

The ETF Trojan Horse

What about Proof-of-stake?

Conclusion: The Cycle Completes

Go: Stick to the Standard Library, Fill the Gaps with Chi, Zap, and Migrate

1. The Core: Why I Reject Web Frameworks and ORMs

HTTP Server: net/http vs. Frameworks

Database: database/sql vs. ORMs (GORM, Ent)

2. Filling the Routing Gap: Chi

3. Filling the Logging Gap: Zap

4. Filling the Migration Gap: Go-Migrate

HTTP Server: `net/http` vs. Frameworks

Database: `database/sql` vs. ORMs (GORM, Ent)