- 1 Tracking Active Directory Operations with PowerShell Commands
- 2 AD Key Health Checks, Part 4: Backing Up AD Partitions
- 3 AD Key Health Checks, Part 3: Designating Bridgehead Servers
- 4 Keeping Active Directory Running Smoothly - Key Health Checks, Part 2
- 5 Why You Need to Reboot Your Domain Controllers Monthly
When to Opt for ARM and When Not to Page 2
When to Opt for ARM and When Not to
While Microsoft has introduced a new way (ARM) to manage Azure resources, which provides the benefits listed above, you might not want to utilize ARM for a number of reasons. Sometimes it can be difficult to determine which Azure mode you should be choosing when both are in use by the Azure public cloud.
Things would have been simpler and easier for users/customers and in fact, you would have been left with no choice if there was only one Azure mode to work with. Since both modes (Classic and ARM) remain viable options, it is necessary to pay attention to the features supported by both the modes as well as the potential restrictions, not just what Microsoft recommends.
Note that Microsoft now recommends using the ARM mode for new Azure deployments. For example, if you are a consultancy service and need to propose a cloud solution to your customers based on Azure public cloud, you are going to compare both Azure modes.
- To decide whether to use classic or the new way (ARM) to deploy Azure resources for your customer, consider the requirements highlighted by your customer. While ARM is a new way to manage Azure resources, you should first consider the requirements versus the limitations imposed by ARM.
ARM cannot simply be judged to be the best of the best if it doesn’t meet all of your customers' requirements. For example, ARM still does not support changing VM size and snapshot for a single VM in a Resource Group. Key questions to ask are what is important for the situation and what are the requirements or use of ARM?
- How are you going to avoid unnecessary complications when it comes to modifying ARM Resource groups/templates in the near future, and do you have the proper documentation to work with ARM schema? This is what we are lacking at the moment. Although Microsoft might improve ARM documentation in the near future, at the time of writing, this is a key part of what ARM is lacking.
- What other benefits will ARM provide apart from managing Azure resources as a single logical unit, securing group resources and some licensing/billing features? Would the Classic mode help in achieving a critical requirement highlighted by your customer? If yes, you should consider using Classic mode. Note that you can create classic resources using the new portal.
- We know that ARM offers other functionalities such as moving resources from one Resource Group to another Resource Group and changing resource dependencies, but how many times are you going to perform a move operation for production VMs in a resource group? How many times are you going to change or remove resource dependencies?
If you believe the Preview portal or ARM is unlikely to meet all of your customer requirements and if the requirement is critical to the customer, then there is no point in using ARM. You should opt for the classic way of doing things, but at the same time also propose a strategy for migrating from Classic Azure resources to ARM Resource Groups.
On a final note, every Azure article page offers a tiny bit of encouragement to Azure customers to switch from ASM (Classic Portal) to ARM (New Portal), but it is important to note that the Azure team is still in the process of building the documentation for ARM, specifically ARM schema.
Although Classic mode is preferred and appreciated by the customers, considering the fact it is Microsoft recommending customers switch from Classic to ARM mode, you should probably be using ARM for all new Azure deployments, provided it helps in achieving all of your cloud solution requirements as well as those of your customers.
Nirmal Sharma is a MCSEx3, MCITP and Microsoft MVP in Directory Services. He specializes in directory services, Microsoft Azure, Failover clusters, Hyper-V, System Center and Exchange Servers, and has been involved with Microsoft technologies since 1994. In his spare time, he likes to help others and share some of his knowledge by writing tips and articles on various sites and contributing to Health Packs for ADHealthProf.ITDynamicPacks.Net solutions. Nirmal can be reached at firstname.lastname@example.org.
Read more on "Server Virtualization Spotlight" »