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 class 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. In fact you can browse by resource groups.
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. I had blogged about RBAC previously. You can check that out- Azure role based access control.
Some important things worth noting in the new ARM (Azure Resource Manager) 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.
- You can of course build a Site-to-Site VPN between classic network and network build using ARM model.
ARM or Azure Resource Manager is V2 of Azure release in itself. It gives you an excellent way to manage resources which have to be together, like resources that belong to a project. You can move resources between resource groups. That said, it’s of immense importance to do some upfront planning to define and decide various resource groups that you would build in an organization. You could define an project Azure on-boarding strategy based on resource group mapping. Needless to say, but it is highly recommended that for any net new work you do in Azure, you should do it the ARM way. More of less all the new features being released are work under ARM model and are not backward compatible (examples include tagging in Azure, role based access control etc).
Hope you learnt something new and something important and interesting. These views are purely my own. I don’t work for Microsoft. These views are based on my experience working in various projects and my experiments with Azure.