For reference:
http://www.dincloud.com/netapp-cloud-storage

But, I really do think Azure needs to handle larger sustained I/O better. It smells like they rely on caching rather than providing big pipes (think of a sponge: it’s ok when you only get little bursts, but when you leave the water on the sponge can’t handle the load)

BACKUP (DISASTER RECOVERY)
How can they say Azure leads in Cloud storage, when Amazon Glacier provides backup of S3, and Azure doesn’t offer a D/R solution? With Amazon, I can recover all data in ~4hours, … no matter how much I have.
Replication, as we know, is not a backup because errors (like file deletion or overwrites) propagate to the backups.

CAPACITY
Azure storage is limited to a certain amount (currently 200TB) per storage account. Sure, you can hack an app to use multiple accounts (20 of them by default).
Even if you have one Azure account, good luck with the billing complexity. This post, http://www.nasuni.com/blog/177-azure_fair_and_balanced, by a Nasuni employee says even Azure billing isn’t reliable.

On the other hand Amazon capacity is not limited and can handle individual blobs of up to 5TB. This was also not mentioned. Interesting.

AZURE INTERNAL I/O IS SLOW
I know from my own tests, that I/O within Azure VM hosts flattens out at ~4MB/s after ~30 seconds of writing, and Amazon VM hosts stays steady at ~35MB/s without ever dropping off. Test it yourself, download your own tool (e.g. Iometer or Sqlio). So, that made me suspicious of the report’s numbers. Sure, those are VMs, but it’s the closest an outsider can get to testing Azure’s internal (shared) infrastructure. In any case, that performance is so bad that it made me suspicous enough to read the report details…

LET’S LOOK AT THE REPORT
http://ht.ly/hR301
Check out the time to write 10MB… Rackspace (of the disparaged OpenStack) had the best time to write 10MB. Azure was in 4th place, behind Google and Amazon

Also, Amazon and Azure both lag greatly in their “availability” metric. Why is that not a factor. Interesting.

So, I read the *actual numbers* in the report, and guess what, Azure’s bandwidth/performance drop off precipitously with larger blob/file sizes.
In fact, ***THEY OMIT THE PERFORMANCE NUMBERS FOR AZURE BLOBS GREATER THAN 10MB, BUT INCLUDE THEM FOR ALL OTHER CLOUDS ***
Why? I can only guess.

What I know is that:
Azure can handle blobs greater than 10MB, but metrics for bigger files were not included
Azure internal IO is horrible with sustained IO (see above) and that might mean the performance for files larger than 10MB are poor.
The report does show that performance numbers for Azure dropped off very quickly (faster than the other clouds) as the blob sizes got bigger.
If I wanted to make Azure look good, I’d focus on the small blobs (100KB) and do as they did and omit metrics on blobs larger than 10MB.
It’s possible that most of the files they care about are indeed smaller than 10MB.

Here’s a clue, Dropbox is running on Amazon S3′s backend ;)