Understand Azure Resource Manager - Azure Tutorial

Let's start with the chapter, Understand Management and Monitoring. Here, I'll explain the functioning of the core management layer in Azure. We'll talk about the tools that are available for us to use for managing resources, monitoring them, and optimizing your cloud environment. So let us begin with understand Azure Resource Manager. This is the most important layer in the Azure management ecosystem. Without it, you won't be able to perform a single task in Azure. Let me explain. Here's what we think happens when a user requests resources. We think they are just straight away provisioned in Azure, but the process is a bit more intricate than that. Here's how it really works. We use tools to interact with Azure. The one we've used so far has been the Azure Portal, which is web-based and has a graphical user interface, but there are more options. You can use PowerShell, which is Microsoft's popular scripting platform, or you can use the Azure Command Line Interface, CLI, or even other custom client apps. We'll talk more about them shortly. These are called your management tools. Irrespective of which tool you use, all requests are passed on to the Azure Resource Manager, also known as ARM or ARM. This component is the heart and soul of Azure administration. Before deploying any requested resource, Azure Resource Manager performs a series of checks. It authenticates the user, sees if the user is authorized to deploy the requested resource, and if the request itself is valid with all the information required to deploy that resource. Another important role of ARM is to standardize the request. So it doesn't matter which tool you use, all requests at the end look the same in ARM because of standardization. The next step is for ARM to reach out to the designated resource provider. For example, if you want a virtual machine or any other compute resource, ARM will communicate with the Microsoft.Compute resource provider. Resource providers are like authorized stores from where you can get a category of resource you want. For compute resources, ARM passes on the request to Microsoft.Compute, and that is how you get a virtual machine. For networking resources, the resource provider is Microsoft.Network, and for storage resources, the resource provider is Microsoft.Storage. For other types of resources, there are other resource providers. We don't have to worry about those right now, but remember, what resource providers are and what they do. Once the requested resource is deployed successfully, an Azure Resource Manager template file, also known as an ARM template or ARM template is generated. This file is the script version of the entire deployment operation you perform for a resource in the Azure Portal. Everything you specify, like the resource name, subscription, resource group, region, configuration, and all the other parameters are saved in this file. This is especially useful when you want to deploy a new resource with a similar configuration as an existing one. In such a case, you can simply use the ARM template for the new deployment instead of clicking again through the pages in the Azure portal. This, in essence, is how the Azure Resource Manager works. Its primary goal is to give you a consistent management experience across various tools and services. So it doesn't matter if you're using the Azure Portal, PowerShell, CLI or any other custom app, the final result is going to be the same. This gives you the freedom to choose whatever tool you are comfortable with. Then these management tools connect to ARM over an encrypted TLS 1.2 connection. This prevents bad actors from intercepting your request and potentially modifying it before it reaches ARM. You can be rest assured that you will get what you request for and not something else. Next, as I mentioned, Azure Resource Manager standardizes the request irrespective of which tool you use. This is important because if it's not standardized, the validation can fail or the resource provider may not process the request correctly. This can lead to inconsistent end results, but luckily this problem does not exist. Thanks to ARM. The authentication and authorization of this request is done using Azure Active Directory and Role-based Access Control. Azure AD does the authentication, and are RBAC takes care of the authorization. Only if the user is successfully authenticated and is authorized to deploy resource, will the ARM move on to the next step, which is, sending the request to the registered resource provider. I use the word "registered" here because resource providers need to be registered in a subscription. The most common ones are registered by default, while others are not. So based on your requirement, you can either register or unregister resource providers to limit what category of resources can be deployed. After that, ARM deploys the resource and generates an ARM template in JSON format. ARM templates store all the deployment parameters and configuration for a resource. This enables consistency and reusability in redeployment of similar resources. And then lastly, if you want to take this script-based method of deployment even further, you can use the Azure Bicep language, which enables infrastructure as code. You can define and deploy resources using precise pieces of code instead of clicking through a user interface. This becomes more useful as your environment scales.