I've written about "data hosting/data deposit box" as an alternative to "cloud computing." Cloud computing is timesharing -- we run our software and hold our data on remote computers, and connect to them from terminals. It's a swing back from personal computing, where you had your own computer, and it erases the 4th amendment by putting our data in the hands of others.

Lately, the more cloud computing applications I use, the more I realize one other benefit that data hosting could provide as an architecture. Sometimes the cloud apps I use are slow. It may be because of bandwidth to them, or it may simply be because they are overloaded. One of the advantages of cloud computing and timesharing is that it is indeed cheaper to buy a cluster mainframe and have many people share it than to have a computer for everybody, because those computers sit idle most of the time.

But when I want a desktop application to go faster, I can just buy a faster computer. And I often have. But I can't make Facebook faster that way. Right now there's no way I can do it. If it weren't free, I could complain, and perhaps pay for a larger share, though that's harder to solve with bandwidth.

In the data hosting approach, the user pays for the data host. That data host would usually be on their ISP's network, or perhaps (with suitable virtual machine sandboxing) it might be the computer on their desk that has all those spare cycles. You would always get good bandwidth to it for the high-bandwidth user interface stuff. And you could pay to get more CPU if you need more CPU. That can still be efficient, in that you could possibly be in a cloud of virtual machines on a big mainframe cluster at your ISP. The difference is, it's close to you, and under your control. You own it.

There's also no reason you couldn't allow applications that have some parallelism to them to try to use multiple hosts for high-CPU projects. Your own PC might well be enough for most requests, but perhaps some extra CPU would be called for from time to time, as long as there is bandwidth enough to send the temporary task (or sub-tasks that don't require sending a lot of data along with them.)

And, as noted before, since the users own the infrastructure, this allows new, innovative free applications to spring up because they don't have to buy their infrastructure. You can be the next youtube, eating that much bandwidth, with full scalability, without spending much on bandwidth at all.