peshkova - Fotolia


Untangling the confusion in the Microsoft Azure portal

Administrators must grapple with Azure management portal changes as Resource Manager displaces the classic Service Management portal.

For newcomers to Microsoft Azure, there can be confusion when they discover there are two ways of working with the Azure public cloud. Specifically, I'm talking about the Azure Service Management and Azure Resource Manager application programming interfaces.

With this tip, I'll explain why Microsoft has two deployment methods in the Microsoft Azure portal and help you determine which one is the best candidate for your organization.

Understanding Azure Service Manager

The Azure development team at Microsoft probably didn't envision how many different cloud services they'd be asked to bolt onto the Azure public cloud architecture. Take the Azure Service Management (ASM) management portal, for instance.

Figure 1 shows all the disparate Azure services -- web apps, virtual machines (VMs), virtual networks, SQL databases, HDInsight, machine learning and so on -- lined up, one above the other, with no apparent connection.

Azure Service Management portal
Figure 1. Shown is the Azure Service Management or the classic management portal.

What many Windows administrators learn before too long is that it's far too easy to botch a deployment in Azure if they are not familiar with its inner workings. For example, when deploying an Azure VM, most admins would first go to the virtual machines node in the portal, then click New. While this is partially true, if the necessary surrounding infrastructure isn't in place -- elements such as cloud service and virtual network -- then the deployment will not work as desired.

Likewise, using ASM to decommission Azure services can be difficult for new users because all the connecting pieces may not appear to be logically connected. Administrators may get a bill for services they thought they had removed.

Finally, ASM is not very good at large-scale deployments because there is no parallel processing. Recently, I needed to spin up 25 Azure VMs for a conference session. Somewhat naively, I assumed Azure would provision the VMs in parallel. But Azure processes them one at a time, which can take a while to complete.

Azure Resource Manager to the rescue

With Azure Resource Manager (ARM), the Azure development team was able to correct the architectural missteps made in ASM. First, the ARM portal was redesigned as you can see in Figure 2.

Azure Resource Manager portal
Figure 2. The portal of services was redesigned in the Azure Resource Manager.

The ARM portal experience offers the following benefits to the Azure administrator. Follow along with the annotations I made in Figure 2:

  • A: Quick access to the most frequently accessed resources. A service that is not being used does not get shown on the navigation bar.
  • B: Journey user interface (UI) paradigm. When clicking through a management task, so-called blades appear that allow navigation back and forth through the task sequence.
  • C: Global search helps to find resources quickly.
  • D: Dashboards allow favorite resources and performance metrics to be pinned. Dashboards can also be shared with colleagues.

The new UI is just the surface of what ARM offers. Consider the resource group, for example. In Figure 3, the resource group is an organizational container that keeps related resources together. This allows administrators to manage related resources -- associated with a particular customer, line of business application and so forth -- as a single unit, including deletion.

Azure Resource Manager resource groups
Figure 3: The Azure Resource Manager resource groups help bundle resources to make deployment and management easier.

ARM also allows administrators to define taxonomic tags and attach them to resources. You can then search through your Azure subscription for all resources tagged with a particular keyword.

Getting deep into the ARM plumbing is beyond the scope of this article, but there are several ARM features that stand out:

  • Role-based access control. In ASM, you're either a global administrator or a co-administrator. In ARM, roles can be defined that grant sub-administrative features to colleagues.
  • Template-based deployments. ARM uses  JSON-based templates to define service deployments. You learn the reasonably straightforward syntax then you can automate Azure deployments -- at scale and in parallel.
  • REST API. Technically, both ASM and ARM have Representational State Transfer (REST) endpoints that allow you to interact with Azure services. REST is a way to share data between web services by using HTTP or HTTPS and stateless, easy-to-read URLs.

Integrating ASM and ARM

What is the compatibility between ASM and ARM resources? The short answer is: minimal.

The four main layers of incompatibility concern: VMs, virtual networks, cloud services and storage.

You can't use an ASM VM, virtual network, cloud service or storage account in ARM, and vice versa. For instance, the deployment unit for Azure Infrastructure as a Service VMs is the cloud service, while in ARM, the resource group is the deployment unit. While these units are not compatible, you can view and manage some ASM resources from the ARM portal, as shown in Figure 4.

Azure Service Manager resources
Figure 4: Azure Service Manager resources are called classic resources in the Azure Resource Manager portal.

A reference to a classic resource in ARM means ASM resources. The Azure team strongly suggests using ARM exclusively for new deployments to use ASM only to support legacy/existing infrastructures.

Currently, there isn't a clear-cut migration path from ASM to ARM. It's a glaring pain point of Azure. What makes the ASM vs. ARM situation even more frustrating is how often you hit a dead end in ARM when trying to get something done. For instance, let's say the local administrator password on an ARM VM needs to be reset. You will likely see something similar to Figure 5 when trying to do so in the portal.

Azure Resource Manager portal password reset
Figure 5. Some Azure Service Manager functions aren't yet available in the Azure Resource Manager portal.

Because the ARM architecture is a work in progress, be prepared to see the following behaviors:

  • ARM actions that take you to the ASM portal to complete the task; Azure Active Directory is a good example here.
  • ARM actions that can be undertaken only through Windows PowerShell, the Azure Command-Line Interface, or the Azure software development kit.

Final thoughts

I agree with the Azure team that organizations should focus on using ARM for future Azure service deployments. That said, you'll only be able to do so if you are comfortable with PowerShell scripting with the Azure ARM cmdlets and JSON templates.

While the ASM portal is familiar to longtime users, but the Azure team is gradually stripping features from ASM, having the net effect of corralling customers into ARM. If you have existing ARM deployments, ask your Microsoft sales/support representative for their advice on how best to approach service migration to ARM. Welcome to the fast-moving world of the public cloud.

Next Steps

Build and manage Windows Server containers in Azure

Operations Management Suite helps manage cloud resources

Azure resources for Windows administrators

Compare ARM templates vs. Terraform for infrastructure as code

Dig Deeper on Microsoft Azure cloud services