Differences between Azure Deployment models - Resource Manager and Service Management(Classic)

When I started learning Azure, there was only one portal(Service Management(Classic)) where we could manage, monitor and provision all the resources. Now, we have another portal(Resource Manager) which can also be used to manage these resources.
The idea is that gradually, all the functionalities will be moved from Classic portal to Resource Manager. So, the question is, why did Microsoft create another portal for managing the same set of resources. The main reason for this change is the underlying architecture of Classic portal.
Due to this architecture change, the following resource providers differentiate between the two models:-

1. Compute
2. Storage
3. Network

Primary Features:-

Following are the features of Resource Manager.

1. The resources of a solution can be managed, deployed and monitored as a group. We can manage resources in the following 4 ways:-
• Using the Azure Portal.
• By using the Powershell cmdlets. For versions earlier than 1.0, we should use “Switch-AzureMode –Name AzureResourceManager” to switch to Resource Manager from Service Management(Classic). For 1.0 and above, new cmdlets have been exposed. We can use the format verb-AzureRm.
• Using the Azure Resource Manager REST APIs.
• Azure command line interface runs in arm mode. “azure config mode arm”.
2. Since Resource Manager is the new type of deployment model, the resources provided by the 3 providers mentioned above do not have any suffix to their names. This is as opposed to Classic model where “Virtual Network” would be mentioned as “Virtual Network(Classic)”.

Following are the features of Service Management(Classic).

1. The segregation in this deployment model is based on the services which are provided. There is no way to group the related resources together in it. We can manage resource using the following 4 ways:-
• Using the Classic Portal.
• By using the Powershell cmdlets. For versions earlier than 1.0, we can use “Switch-AzureMode –Name AzureServiceManagement”. For 1.0 and above, we can use continue to use the cmdlets for Service version i.e. without the Rm in verb-AzureRm.
• Using the Service Management REST APIs.
• Azure command line interface runs in default or asm mode.
2. Since Resource Manager has come out, the 3 resource providers listed above have to be identified separately. To do that, “classic” is added behind resources which are created in the classic portal, as shown below

.

Architecture:-

1. Resource Manager

The Resource Manager is divided into three resource providers. All these resource providers combine together to ensure that a VM is up and running. This componentization of resources allows more flexibility during configuring a VM. A Resource Group is a logical container which holds all these resources together so that they can be managed together. The Resource Manager has the following components(refer to the diagram below):-

• Storage Resource Provider(SRP) – This requires a storage account which contains several VHDs. These VHDs contain the OS running on the VM, temporary and permanent data.
• Compute Resource Provider(CRP) – This consists of VMs(required) and Availability Groups(optional).
• Network Resource Provider(NRP) – This consists of required NIC and Virtual Network and optional Load Balancer and Network Security Groups(NSGs).

2. Service Management(Classic)

The Service Management architecture contains the following components(refer to the diagram below):-

• A Cloud Service(required) which contains a Virtual Machine(required). This VM has a Network Interface Card(NIC) and a private IP address which is provided by Azure. The cloud service also contains a Load Balancer(required) which has a Public IP address and default endpoints for Remote Desktop and Powershell.
• A Storage Account(required) which contains the VHDs for Operating System, temporary data and other permanent data.
• A Virtual Network(optional) which contains a subnetted structure. The VM can be assigned to one of the subnets.

These are the main differences between the two deployment models. I hope that this will give you some idea about why resources are created the way they are in the two deployment models of Azure.