One of the key governance when deploying resources to cloud is to have a good naming convention. A good naming convention should help people quickly identify what the resource is and any relevant information that could prove useful, for example, location(uks, ne) or environment(prod, preprod, etc). You might see a VM resource reporting unhealthy and just by the name you are able to identify the location it is running from and which environment without needing to query for more information. People can then make a quick judgement call if they need to priorities to fix this particular VM or it can be dealt with later.
So how do you start and any good framework to work against? In Azure world Microsoft has create tons of material called "Cloud Adoption Framework" CAF where you will find best practices, guidance and tools from Microsoft to get you going. https://docs.microsoft.com/en-us/azure/cloud-adoption-framework/
Below are a few articles that I have drawn out from CAF which I have use often to give me ideas for naming conventions.
A quick article to give you an idea of how you might want to define overall the naming convention for your resources in Azure with some examples.
The following article gives you some ideas on the recommended abbreviations for various Azure resource types if you can't think of any
This final article is important as it highlights the naming rule and restrictions for Azure resources. The important column to look out for is "Scope". There are three possible scope at present and they are;
- Global - This means this resource name has to be unique across the Azure platform as it is expose out as a possible public endpoint. An example would be Storage Account Name. You may never expose your storage account publicly but because you have an option to expose it, hence at creation time this has to be unique.
- Resource Group - This means the resource name within the resource group for a resource type has to be unique. For example you can not have two managed disk with the same name but you could have a network interface and a managed disk with the same name as they are two different resource type.
- Resource Attribute - This means this has to be unique to the parent resource. An example with file services shares within storage account has to be unique. You will not be able to have two file share name the same under the same storage account.
https://docs.microsoft.com/en-us/azure/azure-resource-manager/management/resource-name-rules
As always these documentation are just best practices and you should adapt it to suit your needs within your organisation. One key takeaway is to make sure the naming convention is documented and kept up to date where possible. As you start to automate processes or builds you will find that with a good naming convention you will be able to make your scripts more generic.
For example, you wanted to know how many disk are OS disks. If you had followed the recommended best practices then any disk that you have deployed and is an attached as an OS Disk for a VM would have the words "OS Disk". Of course you could still find out if a disk is an OS disk by querying each VM and getting the OS disk attribute but what if you just had a bunch of disk not attached to a VM or just did a restore of disks? it would be very hard to identify and your script would be time consuming to write and run.
