Using experimental Azure PowerShell modules
With the emphasis on developer tools (especially CLIs) in Azure, the Azure PowerShell team is experimenting with many improvements to the Azure PowerShell experience.
To facilitate experimentation, we are creating new Azure PowerShell modules that implement existing Azure SDK functionality in new, easier to use ways. In most cases, the cmdlets exactly mirror existing cmdlets. However, the experimental cmdlets provide a shorthand notation and smarter default values that make it easier to create and manage Azure resources.
These modules can be installed side-by-side with existing Azure PowerShell modules. The cmdlet names have been shortened to provide shorter names and avoid name conflicts with existing, non-experimental cmdlets.
The experimental modules use the following naming convention:
AzureRM.*.Experiments. This naming
convention is similar to the naming of Preview modules:
AzureRM.*.Preview. Preview modules differ
from experimental modules. Preview modules implement new functionality of Azure services that is
only available as a Preview offering. Preview modules replace existing Azure PowerShell modules and
use the same cmdlet and parameter names.
How to install an experimental module
Experimental modules are published to the PowerShell Gallery just like the existing Azure PowerShell modules. To see a list of experimental modules, run the following command:
Version Name Repository Description ------- ---- ---------- ----------- 1.0.25 AzureRM.Compute.Experiments PSGallery Azure Compute experiments for VM creation 1.0.0 AzureRM.Websites.Experiments PSGallery Create and deploy web applications using Azure App Services.
To install the experimental module, use the following commands from an elevated PowerShell session:
Install-Module AzureRM.Compute.Experiments Install-Module AzureRM.Websites.Experiments
Documentation and support
Documentation is included in the install package and is accessed using the
Get-Help cmdlet. No
official documentation is published for experimental modules.
We encourage you to test these modules. Your feedback allows us to improve usability and respond to your needs. However, being experimental, support for these modules is limited. Questions or problem reports can be submitted by creating an issue in the GitHub repository.
Experiments and areas of improvement
These improvements were selected based on key differentiators in competing products. For example, Azure CLI 2.0 has made a point of basing commands on scenarios rather than API surface area. Azure CLI 2.0 use a number of smart defaults that make "getting started" scenarios easier for end users.
The core improvements are regarded as "common sense", and little experimentation is needed to move forward in implementing these updates.
Scenario-based Cmdlets - *All- cmdlets should be designed around scenarios, not the Azure REST service.
Shorter Names - Includes the names of cmdlets (for example,
New-AzVm) and the names of parameters (for example,
-Rg). Use aliases for compatibility with "old" cmdlets. Provide backwards compatible parameter sets.
Smart Defaults - Create smart defaults to fill in "required" information. For example:
- Resource Group
- Dependent resources
The experimental improvements present a significant change that the team wants to validate via experimentation.
Simple types - Create scenarios should move away from complex types and config objects. Simplify the configuration down to one or two parameters.
"Smart Create" - All create scenarios implementing "Smart Create" would have no required parameters: all necessary information would be chosen by Azure PowerShell in an opinionated fashion.
Gray Parameters - In many cases, some parameters could be "gray" or semi-optional. If the parameter is not specified, the user is asked if they want the parameter generated for them. It also makes sense for gray parameters to infer a value based on context with the user's consent. For example, it may make sense to have the gray parameter suggest the most recently used value.
-AutoSwitch - The
-Autoswitch would provide an "opt-in" way for users to default all the things while maintaining the integrity of required parameters in the mainline path.
For example, the "Create web app" scenario might have a
-AddRemote switch that would
automatically add an "azure" remote to an existing git repository.
Settable Defaults - Users should have the ability to default certain ubiquitous parameters like
Size Defaults - Resource "sizes" can be confusing to users since many Resource Providers use different names (for example, "Standard_DS1_v2" or "S1"). However, most users care more about cost. Therefore, it makes sense to define "universal" sizes based on a pricing schedule. Users can choose a specific size or let Azure PowerShell choose the best option based on the resource the budget.
Output Format - Azure PowerShell currently returns
PSObjects and there is little console output. Azure PowerShell may need to display some information to the user regarding the "smart defaults" used.