3 ms·
This is a deal breaker IMO. Pushing responsibility onto the application isn't going to work. What was needed from S3 was something more like filesystem snapsho
by vdm 17y ago
This is a deal breaker IMO. Pushing responsibility onto the application isn't going to work.
What was needed from S3 was something more like filesystem snapshots, where the cost is proportional to the amount of changed data. Or deduplication.
I was hoping S3 would get this right so I could just fling database backups at it and my bill would increase, but only a little. Maybe JungleDisk will work out a way so this can still happen.
- jnoller 17y agoI agree - while this new feature from S3 makes sense for a segment of users, just like in normal S3 usage, the complexity is left for the client application to deal with. This is a non starter for most companies. Full Disclosure - I am an employee of Nasuni. We just (today!) launched a versioned, encrypted filesystem sitting on top of cloud storage (including S3) (http://www.nasuni.com http://www.nasuni.com). You are right to point out that this implementation put the burden on the application developers. The fact that each version is a complete copy of the object means that your storage growth could be massive depending on your write pattern. For example, take MS Word - the number of changes generated when editing a file means that if you were to use this feature directly you could end up with hundreds of versions of that single object. This is a good feature that will apply to certain types of S3 users, but those S3 users will not likely fall in the class of generic file/file system application users. Amazon is the only cloud vendor that supports this right now - if you plan on using multiple cloud storage vendors you'd need to consider a design a cloud-neutral application yourself to handle this.