Could a network replace AWS?

The database idea died on the way home, but a second one came with it and would not leave. If storage can live on a network, and compute can live on a network, why does anything need AWS? Build a platform on decentralized infrastructure instead of rented servers. Nobody can turn it off. Nobody can raise the price. And when the traffic gets absurd, the network absorbs it, because there are thousands of nodes and none of them is the bottleneck.

That is the pitch. I believed it for about twenty minutes on the ride, which is longer than I believed the database idea. Then I spent a few weeks reading about whether anyone had actually done it, and the answer turned out to be more interesting than yes or no.

The part that is real

I expected the whole thing to be vapor and it is not. There is a category for it now, decentralized physical infrastructure, and the name is honest about what it is: real hardware, owned by real people, connected into a network and paid in tokens for the work it does. Not a metaphor. Machines.

The economics are the interesting part. A cloud provider buys hardware, builds a data center, hires a team, and charges you enough to cover all three plus a margin. A decentralized network rents hardware that already exists, mostly sitting idle, from people who want something for it. The overhead that a cloud carries is not there, so the price is lower. Not a little lower. Compute markets have been quoting numbers far below the big clouds for the same kind of job, because a GPU that would otherwise sit unused has one honest price and it is close to zero.

And the resilience argument holds up. One company's data center going down takes everyone on it down. That has happened, at scale, more than once, and every company that depended on it felt the same sick feeling. A network with thousands of independent nodes does not have that failure mode. A node disappearing is an event, not an outage. That part of the pitch is not marketing. It is a genuine structural difference and it is real.

The part that is not

Here is where the twenty minutes of belief ran out.

The decentralized networks that work are almost all doing batch work. A render job that takes an hour. A training run that takes a day. A backup that gets written once and read rarely. Look at what the successful projects actually sell and you see the same shape over and over: the work does not care when it finishes, only that it finishes. If a node drops mid-job, another picks it up. If a job waits two minutes in a queue, nobody notices, because nobody is watching.

That is not most of the traffic on the internet. Most of the traffic is a person waiting. A page they clicked. A query they ran. A button they pressed. The defining feature of that traffic is that a human is staring at a spinner, and the spinner has an opinion about how long it should spin. Decentralized infrastructure is very good at eventually and very bad at right now, and the traffic that matters most to a platform is mostly right now.

The research says this plainly, which was refreshing. Papers in the space admit that the current protocols cannot serve demanding read-heavy work, and that the problem is not only technical. Bandwidth is expensive and hard to bill for across a network of strangers. Nobody has found a clean way to charge for a read that happens in fifty milliseconds on a node on the other side of the world, so the networks drift toward storing data instead of serving it. Serving is the part that needs a company, and the company is the part everyone wanted to delete.

The load test that made me change my mind

This is the part I got most wrong, and it took reading a paper to see it.

My scenario was the big-traffic one. Imagine the request volume is enormous, the kind that would make a data center sweat, the kind where a company buys hundreds of machines and hires people to watch them at night. I thought the decentralized network wins here by default. Thousands of nodes, no single bottleneck, the load spreads out, and the thing that kills centralized platforms simply does not happen.

Half of that is right, and the half that is wrong is the half I cared about.

Resilience and throughput are different problems and I had been treating them as one. Resilience is about what happens when something breaks. Throughput is about how much gets served while nothing is broken. A thousand nodes are more resilient than one. They are not faster than one at answering any single request. And for the requests that matter, the ones a person is waiting on, you are now asking the network to route a specific request to a specific node holding a specific piece of data and bring the answer back. The centralized version never paid that cost, because the centralized version knew exactly where everything was. You traded a routing problem for a resilience advantage on a load that was not going to break you anyway.

So the honest conclusion is the reverse of my motorbike thought. Enormous, spiky, tolerant load, the kind that can wait and retry: the network can genuinely be better, and it is better today. Enormous, steady, latency-bound load, the kind a person is watching: the data center is better, and the network spends its one advantage on a problem you did not have.

What I think will happen instead

My guess is that neither side wins, and the workloads sort themselves out.

The batchy things move first. Training, rendering, archiving, the long jobs nobody is watching. Those go to networks of rented hardware and stay there, because the networks are cheaper and more resilient and the workloads never needed to be fast. The latency-bound things stay. Queries, pages, user sessions, anything a human waits on, because those need an answer now from a machine that is up now, and no amount of cleverness about networks changes that.

So what I had imagined as a replacement is probably a partition. You do not swap the data center for a network. You look at what you run, find the pieces that can tolerate waiting, and hand those to a network. The boring fast parts stay where they are, on a machine you own and pay for, because they have to be fast and that is the one thing a network cannot give you.

That is a smaller idea than the one I had on the motorbike. It is also the version that holds up when I try to break it, and it is why I am writing this down instead of the exciting one.

A few things have settled after chewing on this for a few evenings.

Every example I could find of a real workload on decentralized infrastructure was a batch job. I could not find one that moved a database, a page render, or anything with a user on the other end waiting. I might be looking in the wrong places, but the pattern is consistent enough that I am writing it down as a pattern.

What I cannot answer yet is whether the split is permanent or just where the technology is right now. The papers are working on the read problem. Some scheme for metering fast reads across a network of strangers might show up in a few years. Or it might turn out that fast reads need a company the same way a bank needs a building, and the dream of deleting the data center was always a dream about the wrong layer. I do not know, and I have stopped assuming the answer is yes.

What I do know is that my first instinct, that a network of thousands of nodes beats a data center at everything, was a thought about structure that ignored a fact about physics. Distance costs time. Routing costs time. A node you did not choose costs time. Those costs do not go away because the network is bigger, and for a person staring at a spinner, they are the only costs that matter. I had a clean idea about how systems should be organized and forgot that someone, at the end of it, is waiting.

The motorbike served me one true thing and one false thing in the same twenty minutes, and I could not tell them apart until I did the reading. I still think that was a good trade for a ride home.