Azure constantly changes to meet new IT demands, so management tools have to keep up. ARM replaces the classic Azure management portal, but be smart about moving your resources.

As Microsoft expands its Azure public cloud, managing the environment becomes more complicated, particularly for organizations with many applications, users, subscriptions and cloud development projects. Such complexity revealed shortcomings in the legacy Azure admin interface, now called the classic deployment model, and was the impetus for the new Azure Resource Manager.

In the classic version of the management portal, Azure resources were completely independent; admins couldn't group or bundle them into resource collections by application, project or workgroup. Admins needed to independently create and manage each resource, and the only way to automate the deployment of dependent services, such as a web server that requires a MySQL database, was through a PowerShell script.

To decommission a multi-tier application using several services, admins had to delete each resource individually. This inability to group related Azure resources also made it impossible to share common security and user-access policies. In addition, the classic model didn't support resource tagging, which makes it easier to aggregate usage and billing information.

A closer look at ARM

ARM is designed for a new era of cloud adoption, in which organizations use the Azure public cloud for large-scale application development and deployment, often in conjunction with DevOps. As such, ARM incorporates several features to address these needs. These include:

New Azure users should start with ARM, but those who have been running or adding Azure services via the classic portal should start migration, using a prioritized to-do list.

Resource groups are logical containers that admins can use to bundle Azure resources for a particular application or project. Resources in a group should have the same lifecycle for deployment, updating and decommissioning, meaning if a particular resource, such as a database, is used for multiple applications, it should be in a separate group.

Resource templates are standard descriptions of Azure service configurations. Since templates can also apply to a resource group, they can define the dependencies and relationships between the Azure services that an application uses. Templates are declarative JSON descriptions that describe the resources, variables, parameters and, if needed, outputs for a resource group. Templates, which replace the ad hoc scripts used in the classic portal, let Azure users deploy the same set of services, configured the same way, with the same security policy.

Role-based access controls (RBAC) improve security by ensuring users can only access the Azure services and functions they need to do their job. Admins can apply RBAC across a subscription, resource group or single resource. This means a particular user might have access to all databases within a subscription, but nothing else, while another user can only work with the VMs used for a particular application, as defined by a resource group.

Tags are metadata that admins can apply to Azure resources for logical organization within a subscription. Tags are useful for grouping resources by department, workgroup, project or location code, and for summarizing resource usage and charges. With tags, admins can flag users or projects that are over budget.

ARM is available through a web portal that is distinct from that used in the classic admin model, but can also be controlled via PowerShell scripts or a command-line interface. ARM supports most, but not all, Azure services. Services that are only available on the old portal include API management, BizTalk services, multifactor authentication and RemoteApp. As a result, some users will need to use both portals until Microsoft migrates all functionality to ARM.

Test your knowledge of Microsoft Azure

How much do you know about Microsoft Azure, the latest version of Microsoft’s Azure cloud software? This quiz will test your knowledge.

Switching from Azure classic portal to ARM

Before switching to ARM from the classic portal, understand that the two management interfaces aren't completely compatible. This is one reason Microsoft has been deliberate about transitioning users to ARM, which was first introduced in 2014.

To smooth the transition, use ARM to manage new Azure resources and then redeploy existing resources through ARM, where possible.

New Azure users should start with ARM, but those who have been running or adding Azure services via the classic portal should start migration, using a prioritized to-do list:

Add new resources using ARM, either via the new portal or a PowerShell script using the REST API.

Automate the migration of resources that are already setup and managed via the classic model using Microsoft's recommended steps. Understand that migrating from the old model to ARM is purely a management construct; VMs, storage and other Azure services continue to operate on the same hardware, network and configurations.

Organizations with extensive Azure deployments looking to automate the migration should investigate a number of tools, but beware that these are user-contributed and not Microsoft products.

Join the conversation

1 comment

Register

I agree to TechTarget’s Terms of Use, Privacy Policy, and the transfer of my information to the United States for processing to provide me with relevant information as described in our Privacy Policy.

Please check the box if you want to proceed.

I agree to my information being processed by TechTarget and its Partners to contact me via phone, email, or other means regarding information relevant to my professional interests. I may unsubscribe at any time.