Azure services to support the Resource Manager modelThe interface to Azure has transitioned from the Azure Service Management (ASM) model to the Azure Resource Manager (ARM) model over the past year or so. You can view the predecessor ASM as the REST API that allowed you to programmatically (PowerShell or CLI) access the functionality of the Azure “Classic” Portal. Using X.509 certificates, ASM was the alternative and automated way to manage deployments, storage, hosted services, and almost anything you could manually do in the Classic portal.
In 2015, ARM gradually began replacing the ASM model in incremental service rollouts. ASM supports the current Azure “IBIZA” Portal. Using Azure Active Directory for authentication, ARM (is the recommended and supported way going forward to manage your Azure resources. ARM promotes the concept of Resource Groups (RG). An RG is a declarative way of specifying Azure resources (such as storage, VMs, Web Sites, etc.) in a logical grouping to that they are deployed, or released, as a unit.
RGs use a JSON-based template model to describe the relationship hierarchy of all the resources. During execution the template can be run in inline manual entry mode, or in a file named azuredeploy.parameters.json. This is typically obtained at runtime from the GitHub code repository.
I remember in grammar school having to learn the metric system since they told us that over time the US would no longer use the measurements we had grown up with (inches and pounds and ounces). The transition to the metric system would have been wrought with hair-pulling I’m sure for awhile as we cowered in our circa 1970 back yard “bomb shelters” (okay, dating myself here a bit!). The transition from ARM to ASM has not had as dramatic an influence on society as the shift to the metric system would have had on the US population. However, it has caused much consternation on the part of IT folks responsible for the deployment and management of Azure resources for their company. Here is some current guidance and information on where the process is as of today (Leap Day 2016).
Some services still don’t support ARM: We have re-tooled the majority of Azure services to support the Resource Manager model. For some of the remaining services that don’t yet support this model, we’re planning to complete the work within the next few months.
Connecting ASM and ARM environments: Connecting ASM and ARM environments is possible today by linking VNETs created under these models via the gateways. Both environments can also be connected to on-premises via VPN. If using ExpressRoute though, an ExpressRoute circuit created in the ASM model can only be used with a VNET in ASM model, and ExpressRoute circuit created in the Resource manager model can be used with VNET created in Resource Manager model. We are working to address this and by April 2016, just one ExpressRoute circuit will be sufficient to connect Virtual Networks from both environments. In addition, we are also working on a capability that would allow setting up a high bandwidth ASM VNET to ARM VNET Peering connection [in the same region] without a gateway in between them. The Peering should be available in the summer timeframe.
Migration from ASM to ARM: Today, there are scripts to help you migrate Virtual Machines from ASM to the ARM model. We are also working on a few more solutions that will help reduce the VM reboots and network downtime when migrating.
When to choose ASM vs. ARM: When building new applications in Azure or starting new projects, we strongly encourage considering using the ARM model. However if some of the services aren’t yet supported under ARM, or if you have existing deployments under ASM, please continue using ASM until you become comfortable with connecting and managing both environments simultaneously. In the long term, please consider migration of ASM to ARM deployments (using migrations solutions we have planned) but rest assured that that we will be supporting the ASM model for a long time to come.