The signal of the transition between ASM (Azure Service Management) to ARM (Azure Resource Management) APIs have been given not long ago with the recent deprecation of the Switch-AzureMode cmdlet in v0.9.2 of the Azure PowerShell cmdlets.

Switch-AzureMode is now deprecated in release v.0.9.2

This is for the best

The differences between ASM (v1) and ARM (v2) resources are important and you need to prepare in advance to ensure the transition is as smooth as possible. Let's see some of the improvements in the Compute, Network & Storage APIs under Azure Resource Manager:

  • Enabling massive and parallel deployment of Virtual Machines
  • Support for 3 Fault Domains in Availability Sets
  • Improved Custom Script extension that allows specification of scripts from any publicly accessible custom URL
  • Integration of Virtual Machines with the Azure Key Vault for highly secure storage and private deployment of secrets from FIPS-validated Hardware Security Modules
  • Provides the basic building blocks of networking through APIs to enable customers to construct complicated applications that include Network Interfaces, Load Balancers, and Virtual Networks
  • Network Interfaces as a new object allows complicated network configuration to be sustained and reused for Virtual Machines
  • Load Balancers as a first-class resource enables IP Address assignments
  • Granular Virtual Network APIs allow you to simplify the management of individual Virtual Networks

Some of the conceptual differences with the introduction of new APIs

  • In ARM, Cloud Service is no longer an object required for creating a Virtual Machine using the new model. In ASM, Cloud Service was a container for holding the virtual machines that required Availability from the platform and Load Balancing.

  • In ARM, Network Interface is a resource exposed by Microsoft.Network Provider. The lifecycle of the Network Interface is not tied to a Virtual Machine. In ASM, Primary and Secondary Network Interface and its properties were defined as network configuration of a Virtual machine.

  • In ARM, DNS Names are optional parameters that can be specified on a Public IP Address resource. The FQDN will be in the following format - ..cloudapp.azure.com. In ASM, A cloud service would get an implicit globally unique DNS Name. For example: mycoffeeshop.cloudapp.net.

You can get the full detail of these changes in the Conceptual differences with the introduction of new APIs of the Azure Compute, Network & Storage Providers under the Azure Resource Manager documentation on the Azure web site (link in the Reference section)

Proposed changes to come for the PowerShell cmdlets

The proposed changes on GitHub are the following:

  • The Azure module will be renamed to "ASM".
  • All ASM cmdlets will be prefixed with "ASM", so Azure/New-AzureVM will become ASM/New-AsmVM or simply New-AsmVM.
  • AzureResourceManager cmdlets will keep their existing names, so New-AzureVM will be the ARM version.
  • A new convenience script will be added to provide backward compatibility to existing scripts, which only use the Azure module. The script will alias the ASM cmdlets back to their original names and remove the AzureResourceManager module from the session.
  • AzureResourceManager module will be broken into many modules by service and behavior. Examples of the module names would be the following: AzureCompute, AzureNetwork, AzureStorage, …
  • Azure PowerShell and all of its modules will be distributed via MSI and PowerShellGet. MSI cadence will decrease because the MSI will be a wrapper for a PowerShellGet script.

There are some significant performance advancements in the new APIs but no direct migration between v1 (ASM) to v2 (ARM) resources. The vast majority of the cmdlets that share the same names in both APIs have different parameters, the obvious one being the -ResourceGroupName parameter that is found everywhere in v2 cmdlets.

To resume the PowerShell cmdlets transition, it is planned to look like this (subject to change):
ARM module decomposition should start in July. Still in July and through August, the distribution of smaller Azure PowerShell modules will start. The actual removal of the Switch-AzureMode cmdlet should take place somewhere in September, at the same time that ASM cmdlet rename is performed. Azure automation updates is also planned for September.

David Justice (Program Manager - ADX SDK) said the following about the upcoming transition

These changes will affect a large number of users and have the potential to break many scripts. In fact, with out the use of the backward compatibility script, this change will break everyone except the users who are only using ARM cmdlets in their scripts.

What about Azure automation?

  • Azure Automation will continue to ship the Azure module out of the box as a global module, but the proposed ASM module will also become a global module. The “split-out” ARM modules (AzureCompute, AzureStorage, etc) will also ship as global modules.
  • Only the ASM and split-out ARM modules will have their global modules updated to the latest versions going forward.
  • So as not to break existing Azure Automation users, existing runbooks will continue to be served the Azure module, and will not be served the ASM or ARM modules. Jobs of these runbooks will note that they are using the Azure module, that this module is now deprecated in Azure Automation, and that these runbooks should be recreated to target the ASM module instead.
  • New runbooks will not be served the Azure module, and instead will be served the ASM and split-out ARM modules.

These are proposed steps, if you have any suggestions or concerns, I strongly suggest you to voice them in issue#428 on GitHub (see the Reference section for the link).

How can you prepare?

First, you need to understand the differences (conceptual and functional) in the ARM Resource Providers. Second, stop the bleeding by using Azure Resource Manager APIs as soon as possible. Easier said than done you'll tell me but at least your new resources will be future proof and it will reduce the number of resources you need to migrate later. Third but not least, migrate your ASM resources to ARM resources as well as your PowerShell scripts and Azure Automation workflows.

Last advice, start planning this today don't wait to start working on this ;)

References