Azure Immutable Storage has been in the market for a while, and this was one of my more anticipated capabilities. In this blog post I want to give you some insight to it’s use as it’s been in place for a while now and we see a lot of ecosystem and independent software vendors building solutions leveraging Azure Immutable Storage. First off, give a read of what Azure Immutable Storage is: https://learn.microsoft.com/en-us/azure/storage/blobs/immutable-storage-overview
Let’s first go through the key Azure storage elements to make sure we understand what is what. My professional recommendation is to leverage multiple Azure storage accounts (and multiple Azure subscriptions) to provide good administrative boundaries for immutable resources. Immutability is a special use case and likely by its nature it would be a good idea to have as much logical separation as possible.
Azure storage accounts have to be uniquely named within all of Azure, and when one is created, immutability is enabled by the options that start during the account creation. Pay particular attention to the Data Protection tab. This is where Azure Blob Soft Delete is enabled (this is a default by the way) and other options. In order to have immutability, at a minimum, versioning needs to be enabled as shown below:
Now you may wonder why did I unselect the version-level immutability support? This is because this would apply to all resources inside of the storage account persistently. By default, the if version-level immutability support is selected, versioning will click on.
When we look at the other primary configuration element, we can set options to leverage the versioning to implement immutability. For example, here is a blob container being created with immutability turned on:
If the storage account did not have the versioning enabled, the individual option for a container would not be selectable as shown above.
Every implementation may be unique: Go in smart!
I will admit that I have messed this up on my early implementations when ISVs were ready for it. My advice before you implement Azure Immutable Storage is to have the following identified ahead of time:
- What are the Azure storage configuration requirements (container, storage account, etc).
- Give good thought to the duration of immutability as it applies to your Azure storage cost/consumption balanced with resiliency
- Ensure proper support for the application your are using (or developing with)
- Do a pilot ahead of time to ensure the cost model matches the implementation (otherwise its too late if you implement it and you get billshock)
Have you implemented Azure Immutable Storage? Share your experience below!