Comparison of S3 and Rackspace/Mosso Cloud Files(blog.mosso.com)
blog.mosso.com
Comparison of S3 and Rackspace/Mosso Cloud Files
http://blog.mosso.com/2009/02/a-quantitative-comparison-of-rackspace-and-amazon-cloud-storage-solutions/
5 comments
"Mosso is offering free incoming bandwidth until the end of the month. Seems a little unfair to be creating a comparison on a situation that will exist for another 19 days."
Wow that's kind of silly, thanks for pointing this out.
Just wanted to mention: if someone is higher on incoming than outgoing like that, GoGrid has free incoming as a permanent policy. (I can't speak to whether they are any good or not, I evaluated their options and it wasn't right for my stuff).
Wow that's kind of silly, thanks for pointing this out.
Just wanted to mention: if someone is higher on incoming than outgoing like that, GoGrid has free incoming as a permanent policy. (I can't speak to whether they are any good or not, I evaluated their options and it wasn't right for my stuff).
Hey mdasen -
Thanks for digging into the details. Please allow me to clarify a couple of things...
1. Average File Size - You have nailed the difference in request fee pricing but failed to point out that 2 of the 5 scenarios show an avg file size of 75KB. In fact, scenarios 1 and 2 are exactly the same with the exception of file size and were included to specifically highlight the difference in pricing both above and below the 100KB threshold. Also, in some instances, a smaller avg file size results in Amazon costs being even MORE expensive. For example, take a look at scenario #5 and set the average file size to 50KB. The savings with Rack INCREASE from $3,116.97 to $3,525.70. That's because Amazon charges CDN and origin fetch request fees, neither of which Rack/Mosso does. The point of the calculator was to make something that is difficult to compare more quantitative. Your assumption that file sizes over 100KB would always benefit Rackspace is a good example of why the calc was created. As scenario 5 shows, that's not always the case. We tried not to pull any punches and make the scenarios reasonable and fair (I'm an architect and don't particularly care for hyped up marketing). We believe in complete transparency which is also why we make the calculator available. We encourage anyone and everyone to run their own scenarios. If there are errors in the calc, that is another story and we welcome feedback so we can fix any that exist. We recognize we won't be cheaper in EVERY case, but at least people will have the data they need to make an informed decision.
2. Incoming Bandwidth Charges - You are correct that incoming BW is temporarily free. I can't speak in great detail here but we won't simply be introducing an incoming BW charge. Instead, we'll be making some broader cloud pricing changes that will also impact Files BW pricing. That's still a bit of a moving target but I have a newer version of the calc that includes these changes and it doesn't change the fundamental result. When the new pricing is released, we will be releasing a new version of the calculator. Again, full transparency. We thought about waiting until the pricing changes go into affect before releasing this analysis, but since there isn't a fundamental difference, we wanted to get the analysis out now. That said, even with the EXISTING pricing, adding in an incoming BW charge doesn't really change the result. For example, on the "Pricing" tab of the workbook, change the 0 to .10 for "BW in" under Cloud Files. We're still less expensive on all scenarios (with support) and less expensive (or roughly the same) on 4 of the 5 scenarios without support.
3. Gigabytes vs. Gibibytes - We measure in increments of 1024, not 1000 and the pricing breakpoints (see the Pricing tab) are the same. The amount of storage and bandwidth used is an input to the calculator so any number can be entered. We probably should have used 5120 instead of 5000, etc, etc. so your point is well taken. I'll update that for the next version.
Again, thanks for digging in. In general, we expect some degree of skepticism (as there SHOULD be when any company produces their own comparative analysis) but we felt there was a very quantifiable message that wasn't being told. We have tried to be as fair and transparent as we could be in the analysis and we don't necessarily want you to take our word for it. We encourage any and all to look at the cost and performance for yourself. If we've made a mistake, let us know so we can fix it.
If it would be of use, don't hesitate to e-mail me directly at erik[dot]carlin[at]rackspace.com.
Regards, Erik Carlin
Thanks for digging into the details. Please allow me to clarify a couple of things...
1. Average File Size - You have nailed the difference in request fee pricing but failed to point out that 2 of the 5 scenarios show an avg file size of 75KB. In fact, scenarios 1 and 2 are exactly the same with the exception of file size and were included to specifically highlight the difference in pricing both above and below the 100KB threshold. Also, in some instances, a smaller avg file size results in Amazon costs being even MORE expensive. For example, take a look at scenario #5 and set the average file size to 50KB. The savings with Rack INCREASE from $3,116.97 to $3,525.70. That's because Amazon charges CDN and origin fetch request fees, neither of which Rack/Mosso does. The point of the calculator was to make something that is difficult to compare more quantitative. Your assumption that file sizes over 100KB would always benefit Rackspace is a good example of why the calc was created. As scenario 5 shows, that's not always the case. We tried not to pull any punches and make the scenarios reasonable and fair (I'm an architect and don't particularly care for hyped up marketing). We believe in complete transparency which is also why we make the calculator available. We encourage anyone and everyone to run their own scenarios. If there are errors in the calc, that is another story and we welcome feedback so we can fix any that exist. We recognize we won't be cheaper in EVERY case, but at least people will have the data they need to make an informed decision.
2. Incoming Bandwidth Charges - You are correct that incoming BW is temporarily free. I can't speak in great detail here but we won't simply be introducing an incoming BW charge. Instead, we'll be making some broader cloud pricing changes that will also impact Files BW pricing. That's still a bit of a moving target but I have a newer version of the calc that includes these changes and it doesn't change the fundamental result. When the new pricing is released, we will be releasing a new version of the calculator. Again, full transparency. We thought about waiting until the pricing changes go into affect before releasing this analysis, but since there isn't a fundamental difference, we wanted to get the analysis out now. That said, even with the EXISTING pricing, adding in an incoming BW charge doesn't really change the result. For example, on the "Pricing" tab of the workbook, change the 0 to .10 for "BW in" under Cloud Files. We're still less expensive on all scenarios (with support) and less expensive (or roughly the same) on 4 of the 5 scenarios without support.
3. Gigabytes vs. Gibibytes - We measure in increments of 1024, not 1000 and the pricing breakpoints (see the Pricing tab) are the same. The amount of storage and bandwidth used is an input to the calculator so any number can be entered. We probably should have used 5120 instead of 5000, etc, etc. so your point is well taken. I'll update that for the next version.
Again, thanks for digging in. In general, we expect some degree of skepticism (as there SHOULD be when any company produces their own comparative analysis) but we felt there was a very quantifiable message that wasn't being told. We have tried to be as fair and transparent as we could be in the analysis and we don't necessarily want you to take our word for it. We encourage any and all to look at the cost and performance for yourself. If we've made a mistake, let us know so we can fix it.
If it would be of use, don't hesitate to e-mail me directly at erik[dot]carlin[at]rackspace.com.
Regards, Erik Carlin
It's unfortunate that HN has gotten so busy lately that your reply won't be seen by more people. Thankyou for taking the time here to clarify the argument.
Mosso thinks that Mosso is better than the competition? I'm shocked.
The data itself seems pretty objective...
that may be, but the wording suggests serious bias: "cloud files saves you" is not the kind of language you'd expect in an objective review.
Is there a more objective comparison of these services somewhere ?
Well, at least they didn't do the usual, pay someone else to come up with an 'impartial review'.
Well, at least they didn't do the usual, pay someone else to come up with an 'impartial review'.
They both have nice pricing calculators:
http://calculator.s3.amazonaws.com/calc5.html
http://www.mosso.com/pricingfiles.jsp
Just tack in your values and see for yourself.
http://calculator.s3.amazonaws.com/calc5.html
http://www.mosso.com/pricingfiles.jsp
Just tack in your values and see for yourself.
Impressive latency results for static files.
Too bad that's not what I do. Post another ad when the on-demand instances are available and priced hourly.
Too bad that's not what I do. Post another ad when the on-demand instances are available and priced hourly.
The CDN latency test may be flawed. They accessed an 8K file once every 5 minutes, but CDNs are designed for large files that are frequently accessed. Amazon's high latency may be due to cache misses that would not occur if the traffic was heavier.
Likewise, the test is 1TB of incoming bandwidth and 100GB of outgoing bandwidth. Now, Amazon easily trumps Mosso on outgoing bandwidth charges - BUT Mosso is offering free incoming bandwidth until the end of the month. Seems a little unfair to be creating a comparison on a situation that will exist for another 19 days.
I should also note that Mosso seems to measure in Gigabytes instead of Gibibytes. Why? Well, they're storing 5TB which would be 5120GB, but they've calculated their pricing based on 5000GB as being 5TB (5000 * 0.15 + 100 * 0.22 = 722). So, you're actually getting less storage. It's not that important in the small range, but when you're talking about terrabytes of storage it sure as hell becomes important. It means that each terrabyte used on their system is over 90GB short. Now, Amazon might be using the same logic there so I should pull back.
Really, it's cheap to do a comparison using pricing that's going to go up in under a month from when you wrote the comparison.