Azure Blob Storage vs. File Service

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. Here are few points to differentiate between two:

  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).
  4. Pricing: Blob storage is much cheaper than file storage.
  5. 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)

When to use Azure Files vs Azure Blobs vs Azure Disks

We have three main ways to store data in the Azure cloud – Files, Blobs and Disks. All three abstractions take advantage of Azure Storage stack and the Azure platform. The following section compares the advantages of each abstraction.

Azure Files: Provides a SMB 2.1 interface in addition to the REST interface to provide access to files. The SMB interface enables applications running in the cloud to use native file system APIs to read and write from files. A file share is best for:

  • Lifting & shifting applications to the cloud which already use native file system APIs to share data between pieces of the applications
  • Storing development and debugging tools that need to be accessed from many cloud instances
  • Applications that want REST access to data from anywhere and SMB access to data from within the region the storage account is located in

Azure Blobs: Provides a REST interface for massively scale out object storage.

  • Applications can be written to use REST APIs to store unstructured data into Azure blobs at a massive scale (a single container can be 500TBs in size). .
  • Supports streaming scenarios and random access
  • Access to data from anywhere via REST

Azure Disks: Provides persistent disks to be attached to Azure virtual machine in which data is made durable by storing the disk as a fixed formatted VHD in a page blob in Azure storage. When used as a VHD, the disk can be attached to a single VM, but not shared across VM instances.

  • Lift & Shift applications that use native file system APIs to read and write data to persistent disks, but does not require this data to be available to other cloud VMs. Note that a single disk can be attached to only a single VM at any given time.
  • Individual data stored on the disk is not required to be accessed from outside the VM as the data is stored in a VHD formatted with NTFS. However, the VHD can be downloaded from anywhere via REST API and then loaded onto a local virtual machine.
  • Disks can be snapshotted to create point in time read-only backups. When recovery needs to take place, a snapshot can then be copied to a different blob and data can be recovered.

When accessing Azure Files via SMB 2.1, the share is available to VMswithin the same region as the storage account. The REST interface on other hand is available from everywhere. This new service enables customers to “lift and shift” legacy applications that rely on file system APIs to the cloud without code change.