From the course: Automation with Azure Powershell and ARM Templates

Resource groups - Azure Tutorial

From the course: Automation with Azure Powershell and ARM Templates

Start my 1-month free trial

Resource groups

“

- [Narrator] So let's talk about Resource Groups. What is a resource group? A resource group is a container or a logical grouping of different kinds of resources that you might want to use inside of your application or architecture, inside of your solution. You might have a network, you might have a VM, you might have storage, each of these different resources can be grouped together if they share a common life cycle. For instance, I might have a development environment, and a QA environment, and a production environment. That would be three different resource groups. Because I would want to have all off the management of my dove to be in one place, and separate from how I'm doing my production. Generally speaking, a resource group is a way a logical organization of things, it's not a restrictive, in the sense that it will not limit you from being able to put in resources from different areas and also being able to put dependent resources into different resource groups. You can do that all the time. The way that you can use resource groups to go out and describe your environment, is it allows us to manage it and work with it in a single action, for instance, when I'm going out and doing an example of spinning up an architecture or developing a template or working on a new application team, we'll go out and we'll spin up a resource group with everything in it that we need and then when we're done with it, we can delete it and we can script it, work with it, and be able to manage that whole thing together. Now, you might be thinking, okay, well, can I have multiple resources across different resource groups and the answer to that is "yes". We can have a shared resource group where I might have my application hosting plan for a web app, and then the actual applications would be in a separate resource group for each application. If I wanted to delete that shared resource group, I'd have to delete all of the things that are dependent on that first, so there's a way of managing these resources such that you don't accidentally lose something that you wanted to keep. One of the questions about how do we design and work with resource groups comes back to more of a architectural discussion of what makes sense for your situation. Sometimes it makes sense to have a single resource group that you go out and you provision a whole set of things. For instance, I had a streaming analytic job that was reading from an event hub and writing out to a cosmos data base. So I created a single resource group that would provision all three of those services and then be able to manage them together. And when I went from my proof of concept into my actual development life cycle and the continuous integration of things, I was able take that same single template and be able to work it through. Other times you want to have the ability to span stuff out and maybe have multiple resource groups. For instance, you might have network and a V net an app service environment which is a special kind of isolated application service plan that runs on your own hardware inside your own V net is going to be something that's kind of expensive and you don't necessarily want to provision that in every one of your environments. So you'll put that into it's own back-end network, back-end resource group, and then you'll have your front-end somewhere else. You might have different teams working on these different things, but the idea is that the template that you're developing should be deployable and give you enough infrastucture to be able to do what you need to do.

Contents