[tahoe-dev] Alternative deployment model - thoughts?

[Ravi Pinjala]

I've been thinking a bit lately about alternate ways to deploy Tahoe
(partly since the model used by Allmydata seems not to have worked
out). I was wondering what everybody else here thought about this.

* Let's say I'm a cloud storage provider deploying Tahoe. Instead of
deploying a large swarm of servers, and giving users access to all of
them individually, I could cluster them into a single storage server,
and give users a single point of access to it. Clusters could be
broken down in various ways - one cluster per rack might make sense,
or perhaps one per datacenter for a large service provider. Users
would see one reliable, high-capacity storage server, instead of many
small unreliable ones. The biggest advantage here is performance,
since the user uploads data to a given cluster once, and any further
replication happens inside the cluster. (Obviously, the user should
use multiple clusters the same way multiple servers are used now; but
they can upload fewer shares and get the same effective data
redundancy.) For extra coolness, if the clusters are broken down
geographically, then clients have the option of only choosing storage
that's near them, further improving performance.

* Every user should have their own introducer. Storage services could
offer to run one (possibly for a cost, though introducer traffic
should be light enough that they could be run for free), but the user
would retain the option of running their own, naturally. When the user
signs up for storage at a storage provider, they'd be responsible for
providing their introducer's address, and the storage service would
join the specified storage clusters to that introducer. Then, when the
user connects to their introducer, they'll see only servers which
they've authorized as part of their storage grid, and they can use
multiple services (and switch between them) seamlessly.

* An enterprising storage provider could expand by allowing other
people to offer storage through them, and run their own storage
clusters. If the storage provider keeps track of reliability
information from the third-party clusters that it mediates for, and
exposes that to clients in a good way, we could even bootstrap a
reputation-based storage ecosystem from there. :D

Deploying Tahoe this way would shift it from a p2p-style protocol to a
more centralized one, but I don't think that's necessarily bad. People
would still be able to use the p2p model, they'd just have some very
large and reliable peers as an option. I'm really interested to hear
what people think of this - good idea? terrible idea? old idea that
I'm accidentally rehashing?

All of this could be built and rolled out pretty easily, since it's
fully compatible with existing clients. The biggest issue (and the
reason I'm just talking about this instead of prototyping it) is
Tahoe's network protocols, since they're both undocumented and
impossible to implement in anything other than Python+Twisted (unless
there are impementations of Foolscap for other languages that I'm not
aware of). That's unlikely to change in the short term, but it's
something to think about, at least.

--Ravi