Getting started with Azure
When you first start on your journey to Azure, usually the first steps will be to sign up, log in and start deploying some resources to get a feel for how it works, and how it can help your business.
After this initial foray into Azure, it’s easy to just continue, steadily building out your infrastructure from day one. While this can be beneficial in developing your experience and comfort with Azure, its equally important at this time to take a deep breath and step back.
What do we mean by this? Well, there are a few key points you must attempt answer in the best way possible for your businesses use of Azure. We’ll cover some of the more important points below and provide links to Microsoft reference documentation that will let you deep dive into these further.
Naming convention
It’s important to come up with a standard naming convention for your Azure resources. When doing so, it’s important to be aware that certain resource types may have restrictions imposed on the name you may use. Some notable examples are:
- Storage Accounts: Names must be a minimum of 3 and a maximum of 24 characters in length, must be lower case, and importantly the name must be globally unique
- Virtual Machines: Windows VM names must be a minimum of 1 and a maximum of 15 characters in length, whereas Linux VM names must be a minimum of 1 and a maximum of 64 characters in length
As you can see above, it could become problematic if you decide a naming convention without at least considering the most widely used resources and the restrictions they place on names. You could come up with a great 22 character naming convention for Linux VM’s, but as soon as you try to apply it to a Windows VM you’re out of luck.
So where do you start? Some key identifiers that can be considered for use in an Azure resource name are listed below:
- Abbreviation for the application
- Abbreviation for the region where the resource is deployed
- Abbreviation for the environment where the resource is deployed
- Abbreviation for the type of Azure resource that’s deployed
- A numbered suffix
We’ll put the above points into practice with a simple example. You’re deploying resources for an app called Finance, in the West Europe region, for our Development environment, the resource you’re deploying is an App Service Plan, and it’s the first App Service Plan you’ve deployed – the resulting name could be: FIN-WEU-DEV-ASP-001
It’s important when abbreviating to keep the names as relevant and recognisable as possible. Now if you were deploying the Finance Web Application to this App Service Plan you could name the Web App: FIN-WEU-DEV-WEBAPP-001
The name used for the Web App will also be used for its URL, which will result in fin-weu-dev-webapp-001.azurewebsites.net. Although the name of the resource itself is capitalised, Azure will automatically format this as lowercase for use as the sites URL property. Note that the resource name within Azure will not change to lowercase.
Another important consideration when naming resources is the use of a region abbreviation – e.g. WEU for West Europe. Although this can be useful with most resources, consideration must be taken as to what may happen to the resource in the future.
As an example, if you have a VM named FINWEUVM001 running in West Europe [WEU], if you were to use Azure Site Recovery to fail over the VM to the North Europe [NEU] region in the event of a disaster, a question to ask is, is it acceptable to be running my VM with WEU as part of the name when the VM is running in the NEU region?
This is particularly important if there is the potential that the VM may never be failed back to the WEU region as this could result in confusion.
Example of an Azure naming convention
Resource Groups
One of the first ‘resources’ you will most likely deploy to Azure is a Resource Group – a simple way to think of these is in the context of a folder into which you will deploy your Azure resources. A key first step is to decide how you will structure your resource groups, will you have a resource group per application? And will you have a resource group per environment?
Returning to the context of a folder, if you were saving files on your machine you likely wouldn’t want to save every single file into one folder, you’d want to organise them in some way to make them easy to find and manage – perhaps a folder for Accounts, one for Marketing or even Photo’s.
Its important to have this view when working with resource groups – you should aim to make their organisation logical and manageable, being able to look at resource groups at a glance and know their purpose will make your time with Azure that much more efficient.
You can use the above mentioned Naming Convention guidance to come up with a suitable naming convention for your resource groups.
Looking again at the Finance app as an example, we could the following resource group:
FIN-WEU-DEV-RSG-001
Within this resource group you’d deploy the App Service Plan FIN-WEU-DEV-ASP-001 and the Web App FIN-WEU-DEV-WEBAPP-001.
Tag resources
Resource tagging is a simple concept that is often overlooked, but can provide many benefits, especially to larger organisations where cross charging for consumption is important. With tags you can apply any text information to your resource in the form of Name:Value pairs, for example you could create the tags ProjectName:Finance and Owner:Joe Bloggs.
As mentioned previously, a key use for tags is presenting consumption and billing information. Using tags can allow you to easily identify which resources are used for which project, allowing you to charge appropriately.
Tags can also be used for other purposes, such as when employing automation. A tag you might want to apply to a resource is Expiry: 2019-09-30. Automation could then be used to periodically interrogate resource tags and delete any where the expiry date has lapsed.
Example of tags applied to an Azure resource
Subscriptions
Subscriptions reside within your Azure Tenant and allow for segregation, which can be particularly useful when working with different environments. For example you may wish to utilise one subscription per environment, one each for Proof of Concept, Development, User Acceptance Testing and Production. This makes it simpler to manage costs, as at a glance you would be able to see the total cost of running your production systems.
Role Based Access Control can also be used at the subscription level to ensure only the personnel who require access to the resources are able to – in most cases you wouldn’t want a developer having Global Admin rights on a production subscription.
Another use of subscription is to use one per application. This is particularly useful when you are dealing with large applications composing of many resources and to provide access to only the personnel who require access to this applications deployed resources.
Useful Links
Azure Naming Conventions:
https://docs.microsoft.com/en-us/azure/architecture/best-practices/naming-conventions
Resource Tagging:
https://docs.microsoft.com/en-us/azure/azure-resource-manager/resource-group-using-tags