Service Manager (classic) mode versus Resource Manager mode

Azure has introduced Azure Resource Manager (ARM) to solve the challenges related to the way we manage projects in Azure. Most of the solutions deployed are a combination of two or more services. For example, running a virtual machine requires the deployment of three different services:

• A VM instance
• A storage account that contains the disk images
• A cloud service

A customer solution is more complex that this, and there are two main issues:

• Deploying a solution can be complex due to the number of services that needs to be created and configured
• Organizing and managing all these resources can become cumbersome if we cannot associate some metadata to describe why we have deployed every single resource and the solution it refers. If we can do this, we can then list, group, and filter services by solution and have a more clear and usable view of resources

ARM has changed the way we manage and deploy resources by including the following features:

• The entire solution can be described by a template that describes the resources, the dependencies, the parameters, and the variables of a deployable solution.
• Resources can be tagged to be easily organized and searched.
• Each resource is deployed inside a container called a resource group, a sort of namespace, that contains all the services deployed for that solution. The resource group resources are deployed as a whole in a repeatable way, after ensuring that they are deployed in a consistent state, as dependencies help deployment in the correct order. Deployment will be described in Chapter 8, Deploying Solutions in Azure.

The usage of the new ARM mode is a breaking change in the management of Azure resources. Services managed in the Resource Manager mode appear different from the corresponding services in the Service Manager mode.

At the time of writing this book, we can find these situations:

• New services that are ARM-only
• Some ASM services have equivalent new ARM services, but they are two distinct and different services
• Service that are ASM-only and not yet implemented as ARM
• ASM services that are not able to use other ARM services
• ARM services that are not able to use other ASM services

The migration to ARM is an opportunity for Azure to make enhancements to the service.

For example, in the ASM mode, VMs need an explicit, separated cloud service to make VMs addressable from the Internet. Virtual networks are an optional feature to organize our network in the cloud. In the ARM mode, a cloud service is not necessary to publish a VM. VM networking features are completely deployed to a Virtual Network (VN) associating a subnet, a network interface, a public IP address, and some security policies. In the ARM mode, VNs are mandatory to deploy VMs.

Future Azure services are ARM-based, that is, all new services will be based on resources. So, the investment needs to be done on ARM. Therefore, before deploying our first VM, it is necessary to understand how to explicitly manage a VN and how this relates to the current state.

At the time of writing this book, some limitations popped up. Listed as follows are some of them:

• The creation of a VPN is not allowed in VNet2, at the time of writing this book
• Recovery services for virtual machines work only with Classic VMs
• Classic VMs work only in Classic VNets
• ARM VNets with ARM VMs must connect with Classic VNet to access Classic VMs and VPNs

In summary, here is a diagram of what we want to create: