ARM or Azure Resource Manager is a new way of building and grouping resources in Azure. A resource is single entity in the infrastructure like a virtual machine or storage account and so on. And now with ARM model you can group these in to a group called resource group.
So, is that it? What was the reason for wanting to do this in the first place? Let’s see.
Reason 1: Well if you look at the classic portal also known as the ASM (Azure Service Manager) portal when you create resources they just got created and one fine day you would see a list like this containing a mix of types of resources which were created by different people for different reasons all in one place.
Whereas if you look at ARM based model, when you create resources they get grouped under resource groups.
Resource groups in Azure
And when you expand on a resource group you could see the resources in that group.
Great, so one problem of grouping solved and a view which can drill down takes care of putting it cleanly for us. Is that it?
Reason 2: The real important problem that resource group solves is that in the earlier model Azure subscription was the real isolation boundary and that constrained lot of ways in which project teams could effectively use it. You could argue that you will give away a subscription for every team that needs it, but that used to bring up another issue of ease of resource sharing like DNS, AD, and Databases and so on across subscriptions. You had to go through site-to-site VPN to really start sharing resources between subscriptions. A bit too much overhead for simple requirement.
Resource group brings in one additional isolation boundary within a subscription.
As shown in the 2nd graphic above for every project you could provision a new resource group and create an owner for that, typically the project manager and let her run with it. The project manager can then add different users based on roles etc. That basically takes you into RBAC (Role Based Access Control) discussion.
Some important things worth noting in the new ARM world:
- Virtual machines deployed with the classic deployment model cannot be included in a virtual network deployed with Resource Manager.
- Virtual machines deployed with the Resource Manager Deployment model must be included in a virtual network.
- Virtual machines deployed with the classic deployment model don’t have to be included in a virtual network.
- Every virtual machine in classic deployment model must have a public IP. In the ARM model, you may choose not to have a public IP at all. See the graphic below.
- Only resources created through Resource Manager support tags.
- You cannot apply tags to classic resources.
- You can move resources from one resource group to another one.
Using PowerShell to move resources from one resource group to another.
PS C:\> $resource = Get-AzureRmResource -ResourceName ExampleApp -ResourceGroupName OldRG
PS C:\> Move-AzureRmResource -DestinationResourceGroupName NewRG -ResourceId $resource.ResourceId
Using REST to move resources from one resource group to another
- Any resources created using Azure Resource Manager will not be visible in the ASM or classic portal.
- Role Based Access Control is available only in the ARM model and not in the classis model.
- There is an entire different set of PowerShell cmdlets for dealing with resources in the ARM model and they are not compatible with classic set of cmdlets. The ARM PowerShell cmdlets have ‘Rm” in it. For example: Get-AzureRm
Summary of Azure Resource Manager
ARM is a great move forward in terms of the overall design for real world teams in organizations to work with. Every resource group can directly map to a project or even a region (development, test and production). If you are considering any net new development it’s needless to say that you should do it using ARM model in the new Azure portal which is now generally available.