Over the past year, Microsoft has been introducing Azure Resource Manager (ARM) as the preferred way to provision and manage resources in its Azure cloud. ARM is the successor to the original Service Management model, also known as "Classic."[1] While Classic will continue to be supported for the foreseeable future, ARM is the preferred deployment model and all new Azure features are being released on ARM only. Here is an overview ARM and the new features it provides.

ARM introduces the concept of "Resource Groups" and "Templates." Resource Groups are a simple way to manage and group related resources. In addition to simplifying the management of related resources, they also simplify accounting, security and auditing of your Azure deployment. Resource Manager Templates give Azure administrators a very powerful tool that they can leverage to rapidly deploy complex environments consisting of interrelated resources rapidly and consistently. Although there is a learning curve to effectively leverage Resource Manager Templates, once mastered this will be the most effective means of deploying resources in Azure.

Resource Manager Templates
While Resource Manager Templates are very powerful, administrators can still provision new resources in Azure using tools that they are familiar with. In addition to the Azure Portal GUI, Microsoft has released Azure PowerShell 1.0.[2] PowerShell has been the most efficient tool for managing Azure Classic and will continue to work just as well in ARM. For those administrators managing Azure from Mac OS or Linux there is also Azure Command Line which allows Azure management from a set of open-source shell-based commands.[3]

While the new Azure Portal has a variety of improvements over the previous portal and PowerShell continues to be a powerful tool for provisioning and managing resources, the real power of ARM comes from Resource Manager Templates, a declarative way to define your deployments.[4]

Resource Manager Templates
Resource Manager Templates are written in JavaScript Object Notation (JSON) and are used to define your resources as well as to create dependencies between resources. Microsoft has published a number of Azure Quickstart Templates which can be used "as is" or as examples as you build your own templates.[5] Templates generally allow users to pass parameters so each deployment can be customized, to an extent, at deployment time.

Templates can also be linked together so that a single main template can call multiple linked templates. These linked templates can pass parameters back and forth from the master template to the linked templates. This allows you to write templates that perform specific functions and reuse them in other deployments, much as a programmer would define functions within an application for reuse.

While this new paradigm is powerful, it poses a challenge for some Windows administrators who are concerned about programming languages. Many administrators are just now becoming comfortable with PowerShell; others prefer to use the Windows GUI whenever possible. While JSON is a relatively simple language to read and write, many Windows administrators will avoid using Templates because of their lack of experience with JSON and with programming languages in general.

Windows administrators who find themselves suddenly charged with managing Windows Azure deployments can still use a combination of the Azure Portal and Azure PowerShell commands. However, you cannot just use the Azure Portal UI because some ARM features are currently only available via Azure PowerShell. Azure Administrators should buy Visual Studio and learn how to write Resource Manager Templates in JSON.

Visual Studio has added several Azure-specific SDKs to expand Visual Studio. There are tools within Visual Studio that help developers build new programs and mobile applications that are cloud integrated. Windows administrators can also leverage Visual Studio to define and launch VMs and supporting resources right from within Visual Studio.[6]

Resource Groups
Azure Classic had a concept of a "Cloud Service", which was their attempt to group related resources. The limited functionality of Cloud Service has been replaced in ARM by Resource Groups which are used to manage the entire lifecycle of an application, from creation to deletion.

Resource Groups
Resource Groups are a container for all related Azure resources, from VMs, networks, IP addresses, load balancers, databases, web apps and more.  When creating new resources, you can choose to add a resource to an existing Resource Group or to create a new Resource Group. There are no explicit rules governing what should be placed in the same Resource Group, but there are a few things to keep in mind when making that decision.

Resource Groups are a security boundary. You can grant permissions at the Resource Group layer to different users or groups. Keep in mind, they are not NTFS security within your Windows Domain, rather, they provide security in terms of who has access to manage and/or monitor your Azure resources. At last count there were 32 different pre-defined security roles ranging from basic roles like Owner, Contributor and Reader all the way down to specific roles like DNS Zone Contributor and Security Manager.

When defining Resource Groups consider grouping resources that have similar security needs in the same Resource Group. Although permissions can be granted at the Resource Group layer, if there are sensitive VMs within a Resource Group that need additional security these VMs can have explicit security which overrides the security of the Resource Group, so you don't have to worry if your security needs are a little "complicated".

In addition to security, resource utilization, alerting, monitoring and billing can be done at the Resource  Group level as shown in Figure 1.

Figure 1: Example of a Resource Group panel in the Azure Portal

The Resource Group panel displays a simple overview of all the resources in a Resource Group and allows you directly click on each resource to drill down to get a more detailed view of resource as well as allow you to make changes to those resources. This panel is customizable, allowing you to display additional detail such as estimated spend, disk, CPU and memory utilization as well.

If you have ever managed an Azure Classic deployment, or even fooled around with Azure Classic in your home lab you will appreciate this next feature. When it comes time to decommission your application, the old method was to delete you your resources, one resource at a time. And don't forget; before you delete that Storage Account be sure to delete all the VHD files, all the containers and all the blobs first!  It wasn't pretty.

Cleaning up a failed deployment or simply trying to reset your lab to a clean slate in Azure Classic could sometimes be a tedious process. Forgetting to delete just one Premium Storage Disk after a POC will come as quite a surprise at the end of the month when your receive your credit card statement full of unexpected Azure charges; don't ask me how I know.

ARM simplifies this whole process. When you are done with an application and want to decommission it completely, just click "Delete" and all the resources within the Resource Group will be deleted, no fuss no muss (See Figure 2). Now as you can imagine, this is a pretty destructive command, so they do ask you to confirm what you are about to do and ask you to type the name of the Resource Group once again before the job will run to ensure you really are deleting the Resource Group you intended.

Figure 2: Deleting Resource Groups

Summary
In addition to Resource Groups and Template deployments there are other new features of ARM, such as the ability to perform tasks in parallel rather than series. For example, in Classic to stop four VMs via the portal, you would have to stop the first VM, wait for a while, and then try to stop the second VM. If the first VM was not far enough along in the stopping process my attempt to stop the second VM would fail. Needless to say you only had to do this a few times before you decided to write a PowerShell script to stop all your VMs.

With ARM you can now perform this same task in parallel, you no longer have to wait for the first VM to stop before you can stop the second, third and fourth VM. The same holds true for other operations that were previously serialized, such as creating new VMs.

While ARM is the future of Azure some features took a long time to be added and some are not as well documented as they are in Azure Classic. However, the benefits described here should help you overcome any hesitation you may have about making ARM your preferred Azure deployment method.

Learn more about ARM in this recorded webinar.

References

1. https://azure.microsoft.com/en-us/documentation/articles/resource-manager-deployment-model/
2. https://azure.microsoft.com/en-us/blog/azps-1-0/
3. https://azure.microsoft.com/en-us/documentation/articles/xplat-cli-install/
4. https://azure.microsoft.com/en-us/documentation/articles/resource-group-authoring-templates/
5. https://azure.microsoft.com/en-us/documentation/templates/
6. https://www.visualstudio.com/en-us/features/azure-tools-vs.aspx