Subscriptions and Resource Groups in Azure (Oct 09, 2017)


This post is an introduction to Azure subscription and resource group. Working with azure we need an account and after having an account, then we can create subscriptions in our accounts.

You might create subscriptions based on functionality, so your company SAAS software as service product is in one subscription e.g. Accounting_System_Subscription, while research and development takes place in a different subscription e.g. RD_Subscription, or you might create subscriptions based on business departments at the company or your divisions or the geographic locations of your offices.

Whatever the strategy, once you have a subscription, you can create a resource like a database, or a website, or a VM, but these resources never live in the subscription.

Every resource you create will be part of a resource group. Most resource group will have multiple resources inside, and most subscriptions will have multiple resource groups and they have a one to many relationship.

Let's see the true nature and power of resource groups. Resource groups are more than just logical containers to organize resources. I can use resource groups as security boundaries and I can use resource groups to define a unit of deployment when I automate azure. In general, all the resources in a resource group will share the same life cycle.

In this diagram, in the resource group to the left, when I create the app service here, I'll always want to create an associated SQL SERVER database. When I'm done with the app service, I want to delete both the app service and the database. So, I'll just delete the entire resource group.

Now, if the database was also being used by a service running on a virtual machine in the resource group in the middle of the diagram, I would probably not put the database and the app service in the same group. I would create a new third group for the database, because the database and the app service, they don't have the same life cycle. I do not create and destroy them at the same time.

In order to create and delete these resources and resource groups, I might sometimes use the Azure Portal and click around in my web browser to create everything that I need. That is ok if I am a single developer, putting up a website to experiment with Azure, but I am in a product team that requires reliable provisioning, or I'm doing dev ops and I need to roll out new service environments quickly, then the portal is not an answer. I need to do some programming with Visual Studio or Visual Studio Code, or use a language like PowerShell and come up with scripts and programs to provision my resources and resource groups in an automated fashion.

What is important to understand is that all these options, the portal, PowerShell, Visual Studio, behind the scene they all use what we call the Azure Resource Manager. The Azure Resource Manager or ARM is the service responsible for provisioning resources and managing resources in my Azure subscriptions.

Resource manager provides an HTTP-based API. So you can create resources by sending HTTP messages to the correct ARM endpoint. So, when I create an app service in Visual Studio, Visual Studio is contacting ARM behind the scenes, the same with PowerShell, and when I work inside the portal, the portal is also suing ARM in the background to create and manage my resources.

Resource manager also provides templates. So instead of making taw HTTP calls or writing PowerShell scripts, to tell ARM to create this resource and that resource, I can use a Resource Manager Template, which is a file in JSON format to declare what I need in Azure.

 

Templates are the quickest and easiest approach to automate the creation of resources for most scenarios. Resource Manager also supports policies and auditing. If I want to enforce specific naming conventions inside my subscription, I can do that with Resource Manager.

And now one other point that you'll need to know is that Resource Manager doesn't work to create resources directly. There is another layer that Resource Manager talks to, and this is the layer known as the Azure Resource Providers. Knowing about resource providers and learning some of the names of the resource providers will be helpful when you are automating azure.

Every resource in Azure has a resource provider, and it is the resource providers that know all the little details about how to manage a given resource. It is the providers for example that can tell you when regions are supported for a given resource. Microsoft.Compute is the name of the resource provider for virtual machines and availability sets. Microsoft.Storage is the resource provider for storage accounts. Resource providers also expose HTTP-based APIs and I can go to a specific provider, like Microsoft.Compute and I can ask for the list of regions where I am allowed to create a virtual machine in my subscription.

Back to All Articles

Number of Views:1385