

Comparison of S3 and Rackspace/Mosso Cloud Files - timf
http://blog.mosso.com/2009/02/a-quantitative-comparison-of-rackspace-and-amazon-cloud-storage-solutions/

======
mdasen
The comparisons they use are quite contrived. For example, Mosso charges $0.01
for every 500 PUT requests (vs. Amazon's $0.01 for every 1,000 PUTs). However,
Mosso gives you free PUTs if the file is over 100K so they made the tests to
have a 150K filesize meaning that they have no request charges. Whether that's
true of your application is another story.

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.

~~~
ecarlin
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

~~~
timf
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.

------
cperciva
Mosso thinks that Mosso is better than the competition? I'm shocked.

~~~
dabeeeenster
The data itself seems pretty objective...

~~~
jacquesm
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.

------
jacquesm
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'.

~~~
moe
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.

------
ggruschow
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.

~~~
wmf
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.

