Planning Azure Resource Groups
When building a Continuous Integration/Continuous Deployment pipeline in Azure it's important to plan out your resource groups ahead of time. The unit of containment in Azure for a resource, e.g. database, VM(virtual machine), or blob storage, is a RG(resource group).
Resource Group Facts
- When you create a new RG you must select a region. A region must be selected because that's where the metadata about a RG will be stored.
- When creating a resource in Azure, e.g. database or VM, you must pick a RG that will contain that resource. You can have a database in Central US be assigned to a RG that is in West US. A resource can be in only one RG at anytime.
- Administrative control in Azure can be managed at the RG level.
- A resource in a RG can communicate with resources in a different RG. A website and it's database don't have to be in the same RG.
- Most resources can be moved easily from one RG to another RG.
- Some resources can not be moved easily or at all from one RG to another RG, e.g. AD Domain Services, Application Gateway, Managed Disks, etc...
The guidance from the Microsoft Azure documentation states:
All the resources in your group should share the same lifecycle. You deploy, update, and delete them together. If one resource, such as a database server, needs to exist on a different deployment cycle it should be in another resource group.
In order to understand how many resource groups you need you need to know two dimensions:
- number of environments
- number of deployable software "units" with distinct lifecycles