Going to hone my previous storage suggestion a bit, based on others' ideas and more thinking...
Using Amazon Web Services as a reference point, I think something between S3 and EBS would be ideal.
S3's problem is that it lacks the filesystem semantics we all know and love, making things like s3fs a kludge of the first order. On the other hand, concurrent access is trivial: each operation stands alone, so it doesn't matter if you have a hundred instances reading/writing to the same bucket.
EBS's problem is that it lacks concurrent access. By emulating a block device, this means you can't use "normal" Linux filesystems if you want multiple servers mounting it read/write simultaneously. Also, despite "elastic" being in the name, resizing is not possible without snapshot/restore. Both of these problems can be worked around using LVM and fancy filesystems, but that's not
easy, and that's not the Linode Way. I'm off of IRC for a bit (
I'll be back on as soon as I'm caught up with coursework ha ha hahaha why am I in the forums oh god I'm going to fail) but I break out in a cold sweat just thinking of someone --forcing a read-write mount of an ext4 filesystem from two Linodes.....
So, something in the middle. Perhaps NFS to a massive NAS, or something involving
GlusterFS, or both. Or maybe the
rsync.net (Not Affiliated With
rsync Industries) model would work.
It would necessarily be slower than local storage, but that's OK, just as long as it's cheaper and won't impact core service reliability.
Anonymous HTTP access (e.g. S3-style static hosting, perhaps integrated with NodeBalancer?) would still be nice, for those folks still using Apache+mod_php, but... eh, screw 'em.
_________________
Code:
/* TODO: need to add signature to posts */