Which ways does the Azure Resource Manager model provide to deploy resources?

When you are working with Microsoft Azure cloud you must create Azure resources. For managing these resources, Microsoft introduced Azure resource manager, an advanced, cheaper, and faster way to deploy, configure, and manage resources on Azure. It combines all the resources which include Azure resources groups, resource providers, and resources to form a managed cloud platform. You can do this By Azure Portal, Azure CLI, Azure PowerShell, and by using SDKs.

But the question is, why did Microsoft Introduce Azure Resource Manager? The answer is, with the previous classic azure system management you can only manage one resource at one time. This explains the birth of the new Azure Resource manager because if you have a complex application as we are using nowadays, one application consists of multiple components like virtual networks, storage accounts, web app, database, database server, virtual machines and many more depends on applications. To manage these kinds of complex applications, Microsoft introduced Azure management portal 3.0, in which the resource group was introduced. You can manage your components as a single entity not separate entities, but as related and interdependent parts of a single entity. So you will be able to manage all the resources of your application simultaneously.

There are multiple ways you can access the Azure resource manager and its tools. These access options include the following:

• The common and traditional way via the Azure management portal (portal version 3.0 and newer).
• The script-based way via Azure PowerShell or you can access it through Azure CLI which is a cross-platform command-line interface.
• Developers can use the SDKs (.NET and some other programming languages) and, as with all Azure services, an extensive REST API.

The architecture diagram of the Azure Resource Manager (ARM) and its components are mentioned below. As we go through the following diagram, Azure Subscription contains multiple resource groups. Each resource group contains resource instances that are created from resource types available in the resource provider.

Classic deployment characteristics

Resources created in the classic deployment model share the following characteristics:

• Created through one of the following methods:

  • Classic portal

    ![Classic portal](./media/resource-manager-deployment-model/azure-portal.png)
    
    Or, the portal and you specify **Classic** deployment (for Compute, Storage, and Networking).
    
    ![Classic deployment](./media/resource-manager-deployment-model/select-classic.png)
    

  • For versions of Azure PowerShell earlier than 1.0, commands run in the AzureServiceManagement mode (which is the default mode, so if do not you specifically switch to AzureResourceManager, you are running in AzureServiceManagement mode).

        PS C:\> Switch-AzureMode -Name AzureServiceManagement
    

  • For Azure PowerShell 1.0, use the Service Management version of commands. These command names do not have the format verb-AzureRm, as shown below.

        PS C:\> Get-AzureDeployment
    

  • Service Management REST API for REST operations.

  • Azure CLI commands run in asm or default mode.

• The resource type includes (classic) in the name. The image below shows the type as Storage account (classic).

  

You can still use the portal to manage resources that were created through classic deployment.

Benefits of using Resource Manager and resource groups

Resource Manager added the concept of the resource group. Every resource you create through Resource Manager exists within a resource group. The Resource Manager deployment model provide several benefits:

• You can deploy, manage, and monitor all of the services for your solution as a group, rather than handling these services individually.
• You can repeatedly deploy your application throughout the app lifecycle and have confidence your resources are deployed in a consistent state.
• You can use declarative templates to define your deployment.
• You can define the dependencies between resources so they are deployed in the correct order.
• You can apply access control to all services in your resource group because Role-Based Access Control (RBAC) is natively integrated into the management platform.
• You can apply tags to resources to logically organize all of the resources in your subscription.

Prior to Resource Manager, every resource you created through classic deployment did not exist within a resource group. When Resource Manager was added, all resources were retroactively added to default resource groups. If you create a resource through classic deployment now, the resource is automatically created within a default resource group for that service, even though you did not specify that resource group at deployment. However, just existing within a resource group does not mean that the resource has been converted to the Resource Manager model. For Virtual Machines, Storage, and Virtual Networks, if the resource was created through classic deployment, you must continue to operate on it through classic operations.

You can move resources to a different resource group, and add new resources to an existing resource group. So, your resource group can contain a mix of resources created through Resource Manager and classic deployment. This combination of resources can create unexpected results because the resources do not support the same operations.

By using declarative templates, you might be able to simplify your scripts for deployment. Instead of attempting to convert existing scripts from Service Management to Resource Manager, consider re-working your deployment strategy to take advantage of defining your infrastructure and configuration in the template.

Using tags

Tags enable you to logically organize your resources. Only resources created through Resource Manager support tags. You cannot apply tags to classic resources.

For more information about using tags in Resource Manager, see Using tags to organize your Azure resources.

Supported operations for the deployment models

The resources you created in the classic deployment model do not support Resource Manager operations. In some cases, a Resource Manager command can retrieve information about a resource created through classic deployment, or can perform an administrative tasks such as moving a classic resource to another resource group, but these cases should not give the impression that the type supports Resource Manager operations. For example, suppose you have a resource group that contains Virtual Machines that were created with Resource Manager and classic. If you run the following PowerShell command, you will see all of the Virtual Machines:

PS C:\> Get-AzureRmResourceGroup -Name ExampleGroup
...
Resources :
 Name                 Type                                          Location
 ================     ============================================  ========
 ExampleClassicVM     Microsoft.ClassicCompute/domainNames          eastus
 ExampleClassicVM     Microsoft.ClassicCompute/virtualMachines      eastus
 ExampleResourceVM    Microsoft.Compute/virtualMachines             eastus
...

However, if you run the Get-AzureVM command, you will only get Virtual Machines that were created with Resource Manager.

PS C:\> Get-AzureVM -ResourceGroupName ExampleGroup
...
Id       : /subscriptions/xxxx/resourceGroups/ExampleGroup/providers/Microsoft.Compute/virtualMachines/ExampleResourceVM
Name     : ExampleResourceVM
...

In general, you should not expect resources created through classic deployment to work with Resource Manager commands.

When working with resources created through Resource Manager, you should use Resource Manager operations and not switch back to Service Management operations.

Considerations for Virtual Machines

There are some important considerations when working Virtual Machines.

• Virtual machines deployed with the classic deployment model cannot be included in a virtual network deployed with Resource Manager.
• Virtual machines deployed with the Resource Manager deployment model must be included in a virtual network.
• Virtual machines deployed with the classic deployment model don't have to be included in a virtual network.

If you can afford downtime for your Virtual Machines, you can transition them from classic deployment to Resource Manager with the ASM2ARM PowerShell scripts.

For a list of equivalent Azure CLI commands when transitioning from classic deployment to Resource Manager, see Equivalent Resource Manager and Service Management commands for VM operations.

For more details about transitioning Compute, Storage, and Networking resources, see Azure Compute, Network & Storage Providers under the Azure Resource Manager.

To learn about connecting virtual networks from different deployment models, see Connecting classic VNets to new VNets.

What are the different Azure Resource Manager deployment modes?

When using Azure Resource Manager you can use for deployment?

What is Resource Manager deployment model?

What are the different ways we can access Azure Resource Manager?