Question

I have a web application which can receive files uploaded by users. These files are stored in a directory of a web server. Other users can download these files. I am customizing this application for migration on Windows Azure.
On Windows Azure these files are stored in sitesroot and approot.
Does Windows Azure synchronize these changes automatically or I should synchronize them manually? Maybe, to store files with such method is not appropriate ?

Answer 1

Great answer by @Igorek. Just wanted to add a bit. Each of your role instances operates completely independently. And, at its essence, a role instance is Windows 2008 Server. If you have 5 Web Role instances, you have 5 VMs running, each with their own local storage.

And, while you can use local storage, it’s separate storage for each VM instance, and it’s non-durable (meaning if the disk crashes, your data is gone).

Blob Storage, as @Igorek suggested, is independent of your Role instances. You can access it from anywhere (from any role instance, or even from an on-premises app). And blob storage is organized by container, and each blob can be up to 200GB. But most importantly: it’s durable: triple-replicated within the datacenter, and geo-replicated to a neighboring datacenter.

As long as your storage account is in the same datacenter as your application, access is extremely fast (approx. 60MB/sec per blob). Also, you get to set individual blobs (or containers) to public or private. Public blobs are great for CSS, images, or anything else that you might want to render on your webpage. They’re accessible via URI such as:

https://myapp.blob.core.windows.net/images/logo.png

With this type of URI, you can embed it in a web page, and the browser will now retrieve these images directly from storage, completely bypassing your IIS web server, which, in turn, takes load off your role instances. Take enough load off your servers, and you could end up being able to reduce your instance count.

Now, with private blobs, these cannot be seen by the outside world; you’ll need your storage account key to access these. For your web server, this is all transparent. And you can quickly load data into blobs, download blobs to local storage, serve content to your end users… just like you’d serve content from a local disk. If you need to perform operations on a file, where it has to be located on disk, you can first download it to local storage, then perform the operation from local storage.

One more thing on private blobs: You can grant temporary access to these, by encoding the url with a Shared Access Signature on the querystring. This is signed with your storage account key, and grants access for up to an hour. If, for example, your end users have account-specific pdf’s that nobody else should have access to, you have your choice for serving this content. Either:

• Download the private blob from blob storage to local storage, then send it back to the browser via IIS (or any alternate web server), or
• Return a link to the private blob, encoded with a Shared Access Signature (with some short-TTL expiration, maybe 5 minutes), and let the end user access the blob from their browser (via link-click, for example), which then downloads the blob directly from blob storage, bypassing your role instance.