As many readers of this blog know, I am a fan of the Azure module – it makes it simple and relatively straightforward to automate just about all operations in Azure. I've written scripts to do all sorts of things, including creating LInux and Windows VMs, created web sites, worked with networking, etc. I have a lot of scripts out there – and soon, I am going to have to look at each and every one, and probably change most if not all of them. The Azure module is about to change in a very big way – and this could become work for some!
To understand the renaming that is about to happen, we must start at the beginning. In developing Azure, Microsoft created a REST API, the Azure Service Management (ASP) API. A set of cmdlets were created that interfaced with the API to enable automation via PowerShell of the Azure components like VMs. I use these cmdlets most days and they rock. There is room for improvement, but they work and work well.
But the Azure team created a second API, the Azure Resourced Manager (ARM) API. And the Azure module was changed to allow Azure ARM based cmdlets. The ARM API has a much different look and feel – and provides some features not available in the ASM version, particularly templates and resource groups. As an aside, I can only surmise that if thee Azure team were to go back in time, knowing what they know now, they may never have built the ASM API, going straight to ARM. But they didn't.
The impact to the user of the Azure module is how you call cmdlets targeting ARM vs. ASM. For a start, the two cmdlet sets were never meant to be loaded or used together. When you load the Azure module, you get a module of cmdlets, etc, that are targeted at the ASM API. To get to view the ARM based cmdlets, you use the Switch-AzureMode cmdlet, and using the –Name parameter, you specify whether to use the expose AzureResourceManager or AzureServiceManagement API based cmdlets. Both cmdlet sets feature cmdlets with the same name that do more or less the same thing, but are in compatible. You can't really mix and match between the cmdlet sets. With the latest Azure module, it looks like this:
As you can see, there a different number of cmdlets in each set, and when you use Switch-AzureMode, it removes one set of cmdlets and load a totally different module (where did that come from – we never loaded or installed an AzureResourceManager module! The magic of the Azure module makes this all work – and since scripts tend to only use one or other API set, no real harm done.
But it is confusing and from a pure PowerShell point of view, the basic design was flawed – it does need cleaning up. And, going forward, that is what Microsoft is going to do. In a post entitled Deprecation of Switch-AzureMode in Azure PowerShell, Joe Levy spells out the need for the change and how it will happen.
The key changes are broadly as follows:
- The Azure module will be renamed to “ASM”. And all ASM cmdlets will be prefixed with “ASM”, so Azure/New-AzureVM will become ASM/New-AsmVM or simply New-AsmVM.
- The existing AzureResourceManager cmdlets will keep their existing names, so New-AzureVM will map to the ARM version.
- The existing AzureResourceManager module will be broken into many modules by service and behaviour. 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.
So if you have written any scripts using ASM cmdlets, these will need to be updated to use the new cmdlet names. If you have written scripts using the ARM modules, these should not need to change much, but some change is inevitable (erg removing any Switch-AzureMode statements you have!).
If you have done ANY scripting with Azure and PowerShell, you should read the article carefully and start to work out your strategy for the updates that will be coming. The plan, at the moment at least, is that this will all happen over the next couple of months. The ARM decomposition should be done in August, and the Azure module rename will happen in September.
