Previously, Azure used to provide its services via two portals, but recently, Microsoft discontinued the ASM (Classic) portal. However, if you have any services that were running in the classic portal you do not have to worry about them because they have been migrated to Azure ARM portal. Considering that these services would follow the old ASM model. Also, you will note that in the new Azure portal there are two flavors for them. For example, there will be Virtual Machines, and Virtual Machines (Classic).

Historically, Azure services were provided via one portal before 2014, the classic portal, which can be accessed via the following link https://manage.windowsazure.com/. As of now, this portal will redirect to the ARM portal.

The model that was used for that portal is called the ASM model, within which each resource existed independently. You could not manage your resources together, you had to build up and track each resource. For example, you will have to manage the networks from the NETWORKS blade, and the same goes for the storage, virtual machines, and so on. So, when your environment gets bigger, there will be chaos in the management scheme. You will have to know which Azure Virtual Machines are using which virtual networks to do its communications, and that might lead to some critical situations, such as reaching the limits of the allowed number of public IPs, and whenever you need to add a new public IP to be used for a VM in your environment, you would not be able to do so because of the poor management of resources. This would not be your only concern while working with the ASM model. If you want to delete a solution with multiple resources, you will have to do it with each resource manually, and so on.

This is how the classic portal looked:

 Figure 1.1: Azure Classic portal

Azure portal (ARM model)

In 2014, Microsoft launched a new portal that follows a new model, called the ARM model, which can be accessed via the following link https://portal.azure.com/.

When you open the Azure portal, it will look as follows:

Figure 1.2: Azure portal

This model depends on the concept of resource groups, which means you can group all your resources within a container, resulting in resources being deployed in parallel. As a result, you will not face the same problems as you did with the ASM model.

The following diagram describes the deployed resources through the ARM model:

Figure 1.3: Resource manager management model at a high level

Here are the benefits you will gain using that portal:

• Ability to manage your resources as a group instead of managing them separately.
• Using Role-Based Access Control (RBAC) to control access to resources, so that you can assign permissions to a user on a resource or some resources, but not to other resources (as it was in the classic portal).
• Using tags to organize and classify your resources, which can help you with billing. For example, you might want to monitor the billing of some resources that make up a solution, for example, a web server. By assigning a tag to the resources that make up that solution, you would be able to monitor its billing, and so on.
• Support the usability of JSON to deploy resources instead of using the portal:
  • Deploy resources in parallel instead of deploying them sequentially, and waiting until every resource deployment finishes to deploy another one.
  • Specify dependencies during the resources deployment. For example, a VM will not be created until a storage account and a virtual network get deployed, because the VM VHD would need a place to be stored in and an IP address from a virtual network.
  • Reuse of the JSON template to deploy solutions with the same specifications.

ARM key points

For a better understanding of the ARM model, you might need to consider the following key points:

• Resources with the same lifecycle should be gathered in the same resource group
• Resources in different regions can be in the same resource group
• Every resource must be assigned to a resource group, so whenever you want to move a resource between resource groups you must remove it from its current resource group and then add it to the new resource group
• Resource groups support RBAC, wherein a user can have access to some specific resources, and have no access to the others
• Some resources can be shared across resource groups such as storage accounts
• ARM virtual machines can only be placed in ARM storage accounts
• You cannot create a virtual machine using the ARM model and assign it to a virtual network built using the ASM model
• You cannot use a prebuilt image that was created by ASM APIs to build a VM using the ARM model, but as a workaround you can copy the VHD files from the storage account in the classic portal to a storage account created in the ARM model
• You can migrate assets from the ASM model to the ARM model
• Every resource must be assigned to a resource group, so whenever you want to move a resource between resource groups you must remove it from its current resource group, and then add it to the new resource group

Note

You can change the background of the portal by double-clicking on any unused area of the dashboard. You can navigate between four colors (blue, dark blue, white, and black). For further information about the difference between the ARM and ASM models, check out the following article: https://blogs.technet.microsoft.com/meamcs/2016/12/22/difference-between-azure-service-manager-and-azure-resource-manager/.