146
votes

Please correct my wrongs. From my reading on the topic so far, it appears to me that both, Azure Blob Storage and File Service offer the ability to store file(s) and folder(s) (I understand that blobs can store any binary object, but any serialized binary stream is just a file at the end of the day) in a hierarchical structure that mimics a file system.

Only the API to access them are slightly different in that the File Service allows you to query the source using Win32 File I/O like functions as well in addition to using the REST API.

Why would you choose one over another if you wanted your application to store some files owned by your application's users?

3
Have you read this blog post from Azure Storage Team: blogs.msdn.com/b/windowsazurestorage/archive/2014/05/12/…? Please scroll down to the section where it explains when to use which service.Gaurav Mantri
Yes, I read that article before posting. I am in very early stages of thinking things through and my understanding is not yet well-formed. I still am confused. I understand all that's written in all the articles I've read but I am trying to figure out what best to use if I want to store user owned files for an application I am designing.Water Cooler v2
I guess it boils down to what you want to do with these user files? Will they be somehow streamed back (through a web browser etc.) or will they be processed further? If it is former, then blob storage makes sense. If it is latter, then file service makes sense.Gaurav Mantri
Thing is: I want to let the user upload and download his own files and also share some of them with others in his group of contacts (for them to only download/read). I could use Shared Access Signatures (SAS) with Blob storage to do that, but that'd not take care of my "sharing" requirement. I was leaning towards a solution where my app/service did all the authentication and did not expose the actual storage resource to the user. In that context, for me, both File Service and Blob storage do the same thing. No one offers me any more comfort than the other.Water Cooler v2

3 Answers

118
votes

A few items for your question:

  1. You can't mount Azure Blob Storage as a native share on a virtual machine.
  2. Azure Blob Storage isn't hierarchical beyond containers. You can add files that have / or \ characters in them that are interpreted as folders by many apps that read blob storage.
  3. Azure File Service provides a SMB protocol interface to Azure Blob Storage which solves the problem with (1).

If you are developing a new application then leverage the native Azure API directly into Blob Storage.

If you are porting an existing application that needs to share files then use Azure File Service.

Note that there are a few SMB protocol features that Azure File Service doesn't support.

42
votes

A few other things to consider:

  • Pricing: Blob storage is much cheaper than file storage.
  • Portability: With blob storage if you decide to migrate to a diff platform in future you may have to change your app code but with File storage you can migrate your app to any other platform that supports SMB (assuming you are using native file system APIs in your app)
13
votes

Azure File Service is targeted more to internal file handling. With internal I mean mounting a directory to a VM in the cloud or on-premises so it can be loaded in you back-end (SMB based protocol).

For sharing files with end-users (web or apps) it probably makes more sense to use blob storage as this simplifies downloading through a URL and securing download through Shared Access Signatures.

This post shares more details on the comparison (at the bottom): https://blogs.msdn.microsoft.com/windowsazurestorage/2014/05/12/introducing-microsoft-azure-file-service/