4 ms·
You're not wrong, but if you look at the problem that Glacier is trying to solve then it doesn't look so bad: 1. Glacier is competing with tape. So for potenti
by discodave 11y ago
You're not wrong, but if you look at the problem that Glacier is trying to solve then it doesn't look so bad:
1. Glacier is competing with tape. So for potential customers, if it's easier to acquire and maintain than your own tape library then that's a win.
2. In the words of James Hamilton the use case for Glacier is referred "jokingly to as Write Only Storage". If you're using Glacier for disaster recovery then paying a one time cost to retrieve a bunch of data pales in in comparison to the potential costs of not being able to recover your data.
3. Is nearline actually superior for the case of "oh shit I need to retrieve everything right now"?
4. AWS already has this cloud storage thingy called S3 and it has reduced redundancy storage if you're looking for something slightly cheaper.
http://perspectives.mvdirona.com/2012/08/glacier-engineering-for-cold-data-storage-in-the-cloud/ http://perspectives.mvdirona.com/2012/08/glacier-engineering...
- teraflop 11y agoI guess you've got a good point as far as #3 goes; the analysis is actually more interesting than I thought it was. Both Google's nearline storage and Glacier scale your retrieval capabilities proportionally to how much data you have stored with them. You can express it as a tradeoff between cost/GB and the time taken to retrieve your entire dataset Google throttles your downloads to a fixed rate, so they're effectively forcing you to one point in that space: (3 days, $0.01/GB). With Glacier, you get a curve depending on how fast you want it. It's much more expensive at the same speed (3 days, $0.10/GB) but you can go to one extreme of getting all your data for free over the course of 20 months, or getting it all within 4 hours for about $1.80/GB. So I guess it's fair to say that Glacier gives you more flexibility, but Google's offering is a much better value at the particular point that it optimizes for.
- Dylan16807 11y agoHonestly it's hard for me to imagine a total emergency restore-EVERYTHING situation that needs the data in under a day. If it's not that much data you should have a local copy anyway. If it's massive amounts of data is your connection even that fast? And how did you wipe 50 servers at once?
- vidarh 11y ago> And how did you wipe 50 servers at once? Fire does that quite easily...
- Dylan16807 11y agoThat's destruction, not wiping. If you are buying new servers as part of rebuilding you don't exactly need all the data downloaded in a 10 hour window.
- vidarh 11y agoThat's an absolutely irrelevant distinction: The data is gone. And why, in this day of rapid provisioning via cloud providers, do you expect a company to suffer the extended loss of waiting for new servers to want to bring the data back?
- Dylan16807 11y agoSo you're talking about a company using entirely physical servers and switching to an entirely virtual infrastructure, while also dealing with the other effects of the disaster that hit them. They're doing this in less than half a week, or assuming not all the backups are live data they're doing this in less than a day. I submit that this is an extremely atypical company, and that in practice a company that just had a devastating fire is not going to be impacted more than marginally by the download speed limit. There are a good few scenarios where there's total data loss. There are much fewer where you need to restore all the data in under a working day.