The older version of the API (now known as Azure Service Management) is still there, as is the original web portal (manage.windowsazure.com) and it is still necessary to use this portal to access and provision some of the services that are not currently available in ARM, but the majority of services are and ARM should be used to create these services. But why? What makes ARM better than its predecessor?
1. Resource Groups
The concept of a resource is not new, but Resource Groups are. Each Azure service – VM, SQL DB, Storage, vNet, App Service etc, can now be grouped within a Resource Group, a logical container for all resources that are linked. For example, think of an application that is composed of an App Service and a SQL DB. These can now be grouped together within a Resource Group which means it is easier to manage. If your application consists of a Virtual Machine then there will be several resources attached to it – Vnet, Network Cards, Storage, Public IP – and that is just for a single VM, if you have to load balance then you need to double that up and before you know it you have 10+ resources. Having these all grouped within a Resource Group makes managing the resources much easier.
In this example you can see all the resources related to a Virtual Network, Storage, SQL Server and a Virtual Machine in the same Resource Group.
But the advantages of Resource Groups go far beyond a logical grouping of resources:
Permissions can be granted to each Resource Group, so other users can be granted access to only those resources that they need access to, and this can be restricted further by resource if required (giving access to manage the SQL DB only for example).
Using Resource Groups, an Azure administrator can more easily get comprehensive billing information for all the resources within the group, and thus for any particular application or service.
One of the main things I like is that by using the ARM Template you have a fully repeatable configuration of a given deployment and this is extremely valuable for Production environments but especially so for Dev/Test deployments. By having a set template, we can ensure that anytime a new Dev or Test deployment is required (which happens all the time), it can be achieved in moments and safe in the knowledge that it will be identical to the previous environments.
This is also useful for Production environments, when you require the deployment of the exact same resource in different Azure regions- the same template can be run, just specifying the different Region at the time of deployment.
Whilst all of these features are very welcome, the main advantage that ARM gives the Azure Administrator though is how you are actually able to provision the resources in the first place.
2. ARM Templates in Detail
In their most basic form these templates are comprised of 2 JSON documents (one to deploy the resources and one to specify the parameters) and a PowerShell script that can be used to deploy the resources, although it is often easier to deploy directly from Visual Studio.
The Templates are declarative- that means the template describes exactly what resources you want and the properties that are associated with each of the resources, which makes them clearer and easier to understand. It is also easier to declare the parameters for the resources as well, such as VM size or deployment location within the template so that if permission is given to other users to deploy using this template they can only select from the parameters that you have previously determined.
Provisioning the Resources
As ARM templates contain the details of all the resources that are required for the deployment, the template and Azure handles the creation of all the resources. This may sound obvious, but this is completely different from the old API where you as the administrator had to handle everything yourself.
As an example let’s say that the deployment requires a Virtual Network, Storage and a Virtual Machine. In the old API the administrator had to deploy each of these in turn. Whilst this was possible to do via PowerShell, it required extra work to put in error handling etc to ensure the PowerShell script could be run successfully and repeatedly. This is not an issue when using ARM Templates as Azure handles all of this. It is also able to provision some resources simultaneously making deployment via ARM templates far quicker as well.
Creating an ARM Template
In Visual Studio you will need to download the Azure Tools (VS2015 version here) from there you can select the Azure Resource Group Template. You can create a blank template or from one of the preset options, and for the purposes of this example we selected a single Virtual Machine. Once the project is created you can see the relevant files in the solution explorer:
The WindowsVirtualMachine.json file contains our declarative template- that is all the elements required for this particular deployment, a small piece of which is seen below:
In this example you can see the Parameters, Variables and Resources for the deployment and the template details for the Storage Account, Public IP and Virtual Network. This can be modified as required to meet the requirements of the deployment. For example, you would probably not provision a Virtual Network every time you want a new server so that element would be removed and different code added to ensure that the VM gets deployed into an existing Virtual Network.
Hopefully that gives you a good overview of the basics of Azure Resource Manager and the many advantages it offers. It is something that we at BrightStarr have used extensively to build out our Azure platform for our digital workplace solution – Unily – which currently operates in 8 different Azure Data Centres around the world. Using the templates allows us to continually expand our deployments within Azure, knowing that there will be complete consistency across the entire platform.
Get in touch with us today to discuss our Azure Consulting Services.