Azure Files service, First Take: SMB file sharing for cloud VMs
When you have a local network, you can have network storage — an SMB share on a file server, or a Network Attached Storage (NAS) box that everything on the network can access. Inside a cloud service, ironically, you don't have that same concept of local network storage.
Data in Microsoft's Azure can be inside a specific virtual machine that you can share with other virtual machines by doing some rather tedious setup — sharing and mounting the drive and writing scripts to find it and manage high availability. Alternatively, it's in a platform service like a blob or table that doesn't handle those everyday files you still need — for scripts, utilities, logos, log files, content that goes in your CMS and dozens of other things that would be just as handy to have when you're working on Azure as when you're remoting into your on-premise server.
Network cloud storage from inside a cloud service
The idea behind the new Azure Files storage service is to give you network-connected cloud storage that you can use seamlessly from inside a cloud service, blending the platform and infrastructure cloud concepts in a way that's making Azure stand out. (The agent in every VM that lets you manage them via Puppet, Chef or PowerShell, without ever remoting into the individual machines to set that up, crosses the PaaS and IaaS streams in a similar way, giving you a platform service for managing and monitoring infrastructure VMs.)
Azure Files is actually a feature requested by the team building the Azure Web Sites service, to stop them having to make their own file shares from which to copy files all the time, and it's one of those ideas that seems blindingly obvious once someone has suggested it.
If you have an app that works with your on-premise file server, moving it to Azure means rewriting it, or setting up a file server in the cloud. Azure Files is perfect for that. You can also use it as a central location for settings you want to apply to distributed applications or multiple VMs, or as a place to store utilities and logs and other developer and test tools.
SMB 2.1: pros and cons
Azure Files doesn't just sound like SMB — it's using the SMB 2.1 protocol for compatibility, so you'll be able to access it from Linux systems as well as Windows, in VMs on Azure or running in your own business (although you'll have to make a VPN connection to Azure first). You get standard file commands like moving and renaming files, writing content to a file or setting it to read only, or getting notifications when files are modified — all the things you're used to when working with files.
Picking SMB 2.1 means it will be compatible with far more systems and applications, because operating systems and tools and libraries understand files already. However, it also means it doesn't have built-in encryption.
That's why you can only access Azure Files storage from VMs and Azure roles in the same Azure region, not from another Azure data centre. Unless Microsoft comes up with a way to wrap encryption around a cross-data-centre connection, the transfer wouldn't be secure. But file storage can be geo-replicated within a region (in the same way as Azure blobs, tables and queues), so you do get redundancy.
You can also access your storage through a REST API, which lets you access individual files or the entire share, and from anywhere without needing a VPN. That means you can build a connection into an Azure Files storage account into a web application, giving you a lightweight way to build a website that lets you upload files like images from a smartphone.
While the service is in preview, you'll have to wait for access after signing up for the trial. Even when that's approved you can't use Azure Files with an existing storage account — you have to create a new one to get it enabled. It's not clear whether that's a limitation of the preview, or if you'll be able to enable it for existing storage accounts once the service is fully available.
There isn't a graphical tool for creating the file share in the Azure portal yet either. You can do it with the REST API or the .NET Storage Client Library v4, if you're building or converting an application to use Azure files, or with PowerShell if you want to do it via the command line.
PowerShell complications
Using PowerShell to create an Azure Files file share is a little more complex than usual, because the current Azure PowerShell module uses an earlier version of the Storage Client Library. When you install the Azure Files PowerShell module, you have to use the new PowerShell commands in a different PowerShell session because they use a new version of the library.
There are commands to create a file share, make directories in the file share, upload and download files, delete files and list files and folders. Or you can connect to a VM in the same region and mount the file share with the NET USE command (NET USE Z: \\[STORAGE_ACCOUNT_NAME].file.core.windows.net\[SHARE _NAME] /u:[STORAGE_ACCOUNT_NAME] [STORAGE_ACCOUNT_KEY] ) — the Explorer tool for mapping network drives won't work — and then work with the file share like any other drive.
There are a few other limitations. You can't copy data across from blobs on Azure, although Microsoft said it might consider this in the future. Similarly you can't get data into your Azure Files storage by shipping a disk to Azure using the import service that Microsoft offers. Unless you want to do it all in PowerShell, you need to connect to the file share via Remote Desktop and copy your files in that way or use the AzCopy utility. Currently, authentication is based on the (lengthy and complex) Azure storage key, but Microsoft plans to add access based on ACLs and Active Directory authentication in future.
Billing for Azure Files will be based on the size of files you store there — a share can be up to 5TB and the maximum file size is 1TB. You do have to pay for storage during the preview, but it's only half the final price, which will be 2.6p or 3.2p per gigabyte depending on whether you want a second copy of your files stored in another region for redundancy. Storage doesn't time out, so if you're collecting logs you'll want to set up something to delete them when you no longer need them.
Don't expect a consumer-style cloud storage interface in Azure Files. When the service launches it will have the same friendly Azure portal tools as other Azure services, but it's always going to be cloud storage inside a cloud service for developers and testers, and system administrators who are comfortable with PowerShell remoting. It's an inspired bridging of two worlds, but that will also mean you're dealing with the complexity of both worlds.