abccccc.pdf

in this lesson, we're going to explore the benefits and usage of Azure Resource Manager and actually explain what an Azure resource is. The Azure we know about today is really the v2 of Azure. There was an initial Azure service manager-based Azure version, but it had a lot of limitations. It couldn'...

in this lesson, we're going to explore the benefits and usage of Azure Resource Manager and actually explain what an Azure resource is. The Azure we know about today is really the v2 of Azure. There was an initial Azure service manager-based Azure version, but it had a lot of limitations. It couldn't do very granular control and roles, and it couldn't do many things in parallel, so it was hard to do mass deployments. There were a lot of challenges with that. So they introduced this Azure Resource Manager. This is built around the idea of resource providers. So if I think about Azure as this big cloud service, we have Azure, and it's actually built up of these resource providers that define all of the different types of resources that are available to us. If we were to jump over to the command line for a second, we can quickly see what are all of these. If I do a 'get-azresourceprovider,' we'll see there's a whole number of different resource providers actually available to us. We can see things about support and features and cost management and commerce, for example. One that might make more sense to us is let's look at something like Microsoft.Compute, and we'll just care about the resource types that are actually available in Microsoft.Compute. What we'll see is, okay, this seems more familiar. If we look at what's within here, we have constructs like a virtual machine, extensions for virtual machines, the idea of locations, VM sizes, and run commands. We'll see things like disks, shared VM images, snapshots. These are all defined in the Compute resource provider. So within those, it's defining all of the different types of resources that actually make up Azure. So everything in Azure is really its own resource. We looked before at a resource group, and what we saw before was even for something as basic as a virtual machine, a single VM was actually made up of five different resources. We had the VM itself, which was its own resource. Then there was a network interface, which was connected to a public IP that itself was connected to a virtual network, which is in a different resource group. It has a disk, it has a network security group for the network interface. Every single one of those is its own resource. So even a network interface, it has its own access control, it has its own set of tags available to it, it has its own activity log. So everything has its own set of information, its own set of metadata, and the management layer and the deployment layer, well, that is the Azure Resource Manager, or ARM. Everything we do, any interaction, is going through the Azure Resource Manager. This is a RESTful endpoint, so we're typically talking web protocols to this. So if I am sitting somewhere and I'm sitting at a machine, it doesn't matter what I'm using. If I'm using the portal, if I'm using PowerShell and the Az module, if I'm using the AzCLI, if I'm using REST directly, if I'm using an API, it doesn't matter; all of these things are talking to the Azure Resource Manager. There's no other route in, and that's super powerful because when I think of features like policy, when I think of features like authorization, these are applying at the Azure Resource Manager level, so there is no working around these. I can't bypass a policy or bypass permissions; they are enforced at the Azure Resource Manager, and everything goes through these. Now, we often talk about the portal. I've shown the portal a couple of times, and if we look at it, the portal is very nice because it's super intuitive. It's clicking buttons, but it's really not very scalable. Trying to create things through the portal, how do I make sure I've done it the same way across four different environments? How do I create 20 of something in an efficient manner? Click, click, click, click; it's really not. So when I think about how we want to provision things, what we actually want to do, and what ARM enables, is behind the scenes in Azure, everything is stored as JSON. This is a particular notation format to describe what is the state of the resource. I can create a JSON file, I can create using JSON what I want to deploy, and it's something we call declarative. What that means is I'm not telling it how to do something; I'm telling what I want the end state to be. I can send this JSON template through ARM, and it will make it so. Now, if those resources already exist that match my description in the template, it doesn't have to do anything. Maybe I change something, or it will go and change the resource to make it match the template. So the idea of these JSON ARM templates is very powerful as a declarative way to provision resources. When I think about, "Hey, I want to deploy things, I want to do it in a very consistent manner," we want to use these JSON ARM templates. I can actually see that if I go back for a second, and we look at our resource, that network interface card. We'll see there's this idea of exporting a template. This will show me the JSON that would be required to create this. Here, I can see the idea of, well, what is it doing? I can see various parameters; then the resource itself is the bit we care about. It's creating a resource of type - well, it's the Microsoft.Network resource provider, of type network interface, and then it just has various attributes, a name, a location, the tags; it has various properties. So I could take that and essentially recreate it using that JSON file. So ARM provides us that ability to use that declarative technology. Now, there is a new one available as well; you might also hear the idea of Bicep. So Bicep is a more human-friendly language, and when I use a Bicep file, it actually gets transpiled into a JSON file behind the scenes. We don't see that happening, but if you see the term Bicep, realize Bicep is just another declarative technology, but it's more human-friendly than JSON, which really isn't that friendly for us to use as humans. So any resource I have can be defined using an ARM JSON template, and again, because it's declarative, I can run this as many times as I want and create a storage account, and I have it defined as locally resilient storage. I could change it to GRS (geo-redundant) and it would go and change it in there. So that's some of the big powers, but think about Azure Resource Manager as the management and deployment construct for Azure. It's that control plane through which all of our interactions go. It doesn't matter what tooling we're using; it's going through there. That's where policy and authorization are enforced. And if I want to provision resources, I can use ARM JSON templates, or maybe I use Bicep, which gets transpiled into an ARM JSON template.