New Azure BLOB Storage Provider for Kentico
Azure is the best way how you can host Kentico sites. It provides you with great tools, easy deployment options, high availability and many more features. BLOB storage is then the convenient place to store all binary files. The standard provider for BLOB storage available in Kentico CMS comes with strict limitations, but that has changed now.
Apart from already mentioned advantages of hosting Kentico sites in Azure, I would like to also note support for scaling-out and scaling-up and the fact that hosting in cloud is tied with pretty much no maintenance requirements from your side. These are some of the reasons why we at Kentico recommend Azure.
Azure BLOB storage
We know that websites can get huge in amount of files, especially when you instruct your editors to upload high quality images as Responsive image management can take care of the image resizing and optimizing. Think about large ecommerce platforms that need to store tens of thousands of product images which can easily go over few tens of gigabytes.
These websites are usually running in high availability setups and require strategy for regular backups. Azure provides all these options. However, to backup App Services, there is a size limit on data. In the scenario with large website, this means you would not be able to include all your files in the backup.
In another scenario, there is a medium-size website, which only enables editors to work on staging environment. Staging and Production are both configured as App Services, but as they share the same set of media files it would be unnecessary overhead to transfer all binary files between these two environments.
Another feature of Azure – BLOB storage, can solve all these blockers. BLOB storage is a container for your files – BLOBs. You can look at this storage like you would on a shared drive. Kentico does contain a provider that enables you to redirect some or all files to BLOB storage instead of local file system. That actually solves both previously mentioned issues. BLOB storage can host large amount of files (and you can back up only important data) and can be used by multiple instances of Kentico.
There is also one bonus – files in BLOB storage can be made available through CDNs so the binary files of your website can be loaded from the nearest server to your website visitors.
Default BLOB storage provider
As I mentioned above, Kentico does have support for BLOB storage and lets you use it either for all files of your website or only specific folders, like Media Libraries folder. However, as our documentation mentions, there are some limitations to it. This is because Kentico’s standard provider works with BLOB storage in an online fashion. It makes sure that every request is getting the latest data so that you are seeing up-to-date data sets.
The most problematic limitation is on number of items in Media Library. When you open library containing a lot of files or folders, Kentico’s standard provider tries to get you an up-to-date list of all items. That results in many requests being made to BLOB storage from your website. Processing of these requests takes some time, the higher number of items the longer. Therefore, the main goal of the new provider was to minimize this time and provide nice and fast user experience when working with Media Libraries.
Meet the new Azure Storage Provider
The new provider is designed and implemented to use server memory as much as possible. It works lazily and keeps track of all files and folders that were requested sometime in the past. Metadata of such files are stored in application memory and live there throughout the whole life cycle of an application pool. This means that the provider does not need to create new requests for files that were already requested before, it just provides the data from memory instead.
By default this works for metadata of files so you do not need to worry that the memory consumption will increase dramatically. When a binary file content is requested, it is still gathered from BLOB storage using a HTTP request. If you want to optimize this part as well, you can enable caching either in memory or in file system. In that case binary data will be cached for specified amount of time. After that it will be invalidated and removed, but metadata of such files will still be persisted.
Provider also supports web farms, which are essential for App Services in high availability setups.
Due to the nature of this provider’s implementation, it currently does not support direct changes on BLOB storage. In case of manual upload/update of files in BLOB storage, it may be necessary to restart the application to register all file changes by the provider.
This is the best part. AzureStorageProvider is now available as open-source on our Github. Feel free to take a look and if you like it, we would appreciate any feedback or even contribution to its codebase!
Get the code