Having a virtual machine created via the Azure portal without any preparation, and looking at the resources found after creation, I had the impression that some kind of preparation is required before creating a virtual machine in Azure.
These three things I consider to be very helpful to be completed upfront before using Azure for production purposes:
- Define Naming Conventions
- Define how to structure resource groups
- Plan network requirements
Note: This post is part of a series of postings describing several aspects I found noticeable or good to know when I recently created a virtual machine in Microsoft Azure. “Notes and Observations when setting up a Virtual Machine in Microsoft Azure” gives an overview of all parts of the series.
Naming Conventions
Being a fan of naming conventions, I was looking for the definitions / best practices for Azure.
No surprise, there are some. You can find them here.
Unfortunately, when the Azure portal creates new resources, e.g. as part of the creation of a new virtual machine, it does not follow these conventions. For some resources, like virtual networks, it adds a suffix, for others, it does not suggest a name at all.
Before I continue to use Azure, I will define my own conventions, based the Azure Naming Conventions. Once established, whenever I am asked for a new resource while creating another in the portal, I will click on the “Create new” below the combo box and set a name by myrself, following my conventions, instead of letting the portal set the name.
I think it is worth to note that because of some naming restrictions, it is not possible to define consistent naming conventions. E.g. the name of a storage account can only contain lowercase letters and numbers. While using a hyphen separator for other resources, this is not possible here 🙁
Structure Resource Groups
Searching the Internet for best practices, two approaches are named:
- Application centric
- Workload centric
I share this view. One only have to decide which way to go (based on what is expected to suite best the needs).
I am wondering if it makes sence to have additionally (a) specific resource group(s) for resources that might be shared across application / workload boundaries, e.g. network resources. As a general rule of thumb, anything that might be a shared resource could be member of a resource group which is more task/service/type oriented.
Why this? Well, imagine the application centric approach is used, and you do have some network resources that need to be shared across applications. Now one of the applications has reached the end of its lifecycle. Being happy to have the application centric setup, you just have to delete the application-related resources groups, and all application-related resources are history too. In consequence, another application that shared some network resources with the deleted application, will start reporting errors the moment the other application was deleted.
Once I am a little bit more experienced in Azure, I will see if this idea makes sense or not.
Plan Network Requirements Up-Front
When there is no need that my VM is communicating with any other virtual machine or Azure service, I will continue to let Azure create a new virtual network together with the new virtual machine (and watch out to follow my naming conventions 😉 ).
In case some inter-VM, Azure service, or external communication is required, planning and creating the network resources I consider to be helpful. As I am not a network specialist, I hope I will find some support when I need it, and will have a look at Microsoft’s guidance on “How to plan virtual Networks“.
If the only intention of the VM is to have a single, stand-alone box, I will not put time in thinking about this. Creating the network resources as part of the VM creation will be sufficient here from my point of view.
Links
Notes and Observations when setting up a Virtual Machine in Microsoft Azure
Resources found after Creation of a Virtual Machine in Microsoft Azure
Azure Naming Conventions
Microsoft’s Guidance “How to plan virtual Networks“