Use Azure Resource Groups: A Simple Explanation
Resource groups (RG) in Azure is a new approach to group a collection of assets in logical groups for easy or even automatic provisioning, monitoring, and access control, and for more effective management of their costs. One benefit of using RGs in Azure is grouping related resources that belong to an application together, as they share a unified lifecycle from creation to usage and finally, de-provisioning.
The underlying technology that powers resource groups is the Azure Resource Manager (ARM). ARM was built by Microsoft in response to the shortcomings of the old Azure Service Manager (ASM) technology that powered the old Azure management portal. With ASM, users could create resources in an unstructured manner, leading to many challenges in tracking such resources or understanding their dependencies. This led to huge difficulties that discouraged people from using Azure, as they would have a big mess once they had to deal with multiple applications that spanned more than one region.
To better understand this challenge, imagine you wanted to create an application in the old Azure management portal. To do so, you would create the virtual networks, the storage account(s), the cloud services, virtual machines, and potentially many other components of that application—without the ability to group them. If you were to build or deploy more than one application, it would become a difficult to find which resources depended on which, what order to create them by, or even which application they belonged to.
How Do Azure Resource Groups Help?
Azure Resource Manager, which was announced in 2014 and became generally available in 2017, addresses this challenge and others by providing a new set of application programming interfaces (APIs) that are used to provision resources in Azure. ARM requires that resources be placed in resource groups, which allows for logical grouping of related resources.
In the figure below, two resource groups are used for grouping: First, those that are related to a line-of-business (LOB) application, and second, to an infrastructure as a service (IaaS) workload.
Although creating a resource group requires specifying a region for it to be stored in, the resources in that resource group could span multiple regions. The requirement to have a region for a resource group comes from the need to store the deployment metadata (definitions) associated with it in a specific location and does not dictate that resources belonging to it need to be in the same region.
Benefits of Azure Resource Manager (ARM)
Before ARM, you had to provision resources independently and you had to have a good understanding of their dependencies and accommodate for them in deployment scripts. As an example, to create a virtual machine, you needed to create a storage account, a virtual network, a subnet, etc. first.
On the other hand, ARM can figure out the dependencies of resources that need to be provisioned before creating the virtual machine and what order they need to be provisioned in, saving the user from having to repeat their work to fix unnecessary errors during deployment. In the example above, ARM will automatically create the virtual network and storage account simultaneously with the virtual machine. The portal blades walk the user through defining the related resources as part of provisioning the virtual network. As an example, in the screenshot below, you can see that creating a virtual machine requires specifying the other dependencies in the settings blade, including the virtual network, the subnet, the public IP address, and storage account, among other things.
In the ARM architecture, resource groups not only become units of deployment, but also units of management of related resources. This allows users to determine the cost associated with the whole resource group, making accounting and chargebacks more manageable. It also allows role-based access control (RBAC) at the resource group level, making it much easier to manage user access to the resources in the group. When users log into the Azure Portal, they will only see resource groups they have access to and not others within the subscription. Administrators will still be able to assign access control for users to individual resources within the resource group based on their roles.
Management of Azure Resource Group
Aside from scripting (e.g. using PowerShell or the Azure CLI 2.0,) resource groups can only be managed in the new Azure portal that became generally available last year. If using the new Azure Portal, a resource group item is available in the navigation menu by default and can be used to open the RG management “blade,” as you can see in the screenshot below.
The RG management blade provides a straightforward way to create and manage resource groups. It also provides a flexible customizable, high-level view of available resource groups in a specific Azure subscription. The user can select what columns to see in this view based on their role and interests and may use filters to zoom in on resource groups specific to a subscription or a location.
The new portal was designed to work well with the ARM concepts and architecture providing great flexibility and user experience in how resources are displayed and managed. The portal displays blades to the user as additional resources are created. A blade is a self-contained page (or set of pages) that allows the user to view and manage all aspects of the resource they have created using a step-by-step wizard-like approach for building the resource.
Keys to a Successful Azure Resource Groups
Despite the advantages resource groups and ARM bring to Azure users, it is important to use them with care and good insight. The key to having a successful design of resource groups is understanding the lifecycle of the resources that are included in them. For instance, if an application requires different resources that need to be updated together, such as having a SQL database, a web app, a mobile app, etc., then it makes sense to group these resource in the same resource group. It is important, however, to use different resource groups for dev/test, staging, or production, as the resources in these groups have different lifecycles.