I use Azure Storage extensively, especially for dirt-cheap, highly reliable serving of static Web content.
And I use Azure Storage extensively as part of the robot that produces movie listings on MaineToday.com: Basically, all the showtimes you see there are HTML snippets retrieved via HTTP from Azure Storage.
The best thing about using Azure Storage for directly serving static content is price.
As of this writing I can host 1 GB of media (US East, locally redundant, 3 million transactions) and serve it out of multiple CDN zones (standard plan) for about $2 per month.
Consider that against even the cheapest of shared hosting, and it’s a significant savings. Especially when you consider that, with the right CORS and caching rules, Azure Storage will perform far better than some heavily-strained shared server in Silicon Valley.
There are bits and pieces floating around out on the Internet about how to serve content directly from Azure Storage, but no comprehensive look at using Storage as a means of directly serving static content.
Some Notes Before We Start
Before we begin, let’s define terms.
I am specifically talking about serving block blobs via HTTP. There are lots of other kinds of content you can store in Azure Storage and lots of other ways to get at it, but I am talking about retrieving a file via a URL, circa 1991.
I will control access to these files via CORS. That is, these files are going to be generally accessible over the web, but I will apply CORS rules to sensitive material, such as JSON and images I don’t want certain websites to leech. Recognizing, of course, that if it’s on the Web, it can probably be stolen.
I am only GETting files, not applying other HTTP verbs. PUT, POST, DELETE, HEAD, OPTIONS, TRACE, CONNECT — keep your fancy-schmancy HTTP verbs, I’m only serving up predefined, immutable content that doesn’t give a hoot about query string variables.
I am going to control caching via cache-control headers and the Azure CDN. I could go third-party as well, or develop my own middleware / proxy to manage caching and expiration, but as long as I expect people to use Web browsers made in the last 10 years, these caching methods should more than suffice.
— Doug Vanderweide (@dougvdotcom) April 20, 2016
Get A GUI
I’m a programmer and this blog is aimed at developers, so much of what we’re going to discuss in this series will use .NET code to accomplish a task.
The best one I’ve found, by far, is CloudBerry Explorer.
The free version is perfectly adequate for sending a file to a Storage account, editing its name or metadata, etc. But the ability to search a container for specific files makes the Pro version well worth the $40 CloudBerry charges for it. Not to mention the super-handy compare functionality, which makes finding duplicate versions a breeze.
Prior to discovering CloudBerry Explorer Pro, I used Azure Storage Explorer 6, available via CodePlex.
Although it’s not in active development, Azure Storage Explorer 6 still works just fine with blobs, including the most important tools: rudimentary search, file uploading / downloading, renaming, editing of metadata and rudimentary viewing of the file.
Microsoft also offers an official Storage client, also under the name Storage Explorer.
It doesn’t have as robust a metadata editor as either CloudBerry or Azure Storage Explorer 6. You can, however, use Storage Explorer to upload and download blobs.
So, if you’re going to be serious about serving static content from Azure Storage, make that $40 investment in CloudBerry Explorer Pro. You won’t regret it.
That’s it for now. Next up: Setting blob metadata to allow direct serving from Azure Storage.