Deprecation of Switch AzureMode in Azure PowerShell
Beginning in version 0.8.0, the Azure PowerShell installation included both Azure Service Management (ASM) and Azure Resource Manager (ARM) modules. These modules were not designed to be used in the same session. So to allow use of the modules within the same session, one module would be loaded and the other module would be unloaded using Switch-AzureMode. ASM was the default module loaded into the Azure PowerShell session and required the use of Switch-AzureMode to transition to ARM mode.
For those who are unfamiliar with ASM and ARM, these modules represent collections of cmdlets, which target the Azure Service Management and Azure Resource Management REST APIs. These REST APIs provide an interface for managing Azure cloud resources such as virtual machines, networks, storage, etc. ARM and ASM can be used to create Azure resources, but the two APIs take drastically different approaches. ASM was a strictly imperative model for creating your Azure resources. ARM introduces an entirely new way of thinking about your Azure resources. Instead of creating and managing individual resources, you are able to manage entire topologies of resources together as logical units. ARM is the future of Azure management and thus the future of Azure PowerShell.
Initially, ARM didn’t have all of the functionality needed to perform all of the Azure management tasks required by most users, so it was decided to default to ASM. Now, ARM is ready to be the default Azure module.
The Switch-AzureMode cmdlet was created to cover up the fact that many of the cmdlets in ARM share the same name as cmdlets in ASM (ASM/New-AzureVM and ARM/New-AzureVM, for example). We really liked the names of the cmdlets in ASM and wanted to keep them for ARM, but we didn’t want to break existing Azure PowerShell scripts. So, rather than changing the names of the ASM cmdlets and breaking everyone’s scripts, we added Switch-AzureMode to transparently load one module and unload another module.
The Switch-AzureMode cmdlet introduces a pattern, which is antithetical to the way that PowerShell was designed to work with modules. Innately, PowerShell provides the functionality for the user to import modules and remove modules with a wide variety of options. The opinionated pattern of Swich-AzureMode has been confusing and frustrating to users and locks the user into using the specific way we set for loading modules. It also made use of the ASM and ARM modules together in Azure Automation difficult.
There has been significant user feedback regarding the design and we have decided to make a change for the better and deprecate Switch-AzureMode. Proposed Future Without Switch-AzureMode
With the deprecation of Switch-AzureMode the following changes are proposed.
- 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 map to the ARM version.
- A new convenience command 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 PS-Get. MSI cadence will decrease because the MSI will be a wrapper for a PS-Get script.
These changes will affect a large number of users and have the potential to break many scripts. In fact, without the use of the backward compatibility script, this change will break everyone except the users who are only using ARM cmdlets in their scripts.
As mentioned above, the Switch-AzureMode method of Azure and ARM module use did not work in Azure’s Automation service, leading to a lack of ARM adoption in the service. The above proposed changes to Azure PowerShell, along with proposed changes to Azure Automation, will make use of ASM and ARM cmdlets side by side in Azure Automation much simpler. The following changes to Azure Automation are proposed:
- 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.
With the wide-ranging impact of these changes in mind, we have decided to start talking about the transition many months before we intend on making this changes. We intend on making some of the underlying changes such as breaking up of the AzureResourceManager module into its component modules and moving to PSGet in preparation for the removal of Switch-AzureMode during July and August. The removal of Switch-AzureMode, and the updates to Azure Automation, will occur in early September, which should provide ample time to prepare for these changes.
Azure PowerShell is an open source project and as such, we would like to illicit feedback from the community regarding these upcoming changes. Please think of this as proposal, which is open to being shaped by feedback. This is our initial plan and is a living document. We are open to ideas from the community regarding its direction. If you feel strongly regarding this topic and would like to have your design ideas heard, please contribute to the discussion via GitHub issue #428 which we are using to track discussion for this change. The Azure Automation team will also be monitoring this GitHub issue.