This blog post introduces some principals to consider when modelling and organizing resource groups & resources in microservices environment. Resource groups are one piece in the puzzle and you should also check Microsoft's great documentation (Cloud Adoption Framework) about how to model management groups and subscriptions. You can find more information from these links management groups and subscriptions.
Overall each Azure environment should have a governance model. Governance model provides management tools to ensure that services across multiple subscriptions are created according to agreed patterns and security & compliance requirements are fulfilled. Some actions in governance model can be automatized using ex. azure policies. I'll write more later about governance model in Azure.
Management hierarchy in Azure
This blog post concentrates to lowest hierarchy level and especially how to model resource groups in environment which is utilizing decentralized architecture (microservices). Azure building blocks like management groups, subscriptions and resource groups are flexible tools to model your technical environment based on your requirements.
But before starting it's important to understand in general about management hierarchy in Azure:
Source: Organize your Azure resources effectively
Scaling Azure subscriptions
Let's discuss first briefly about Azure subscriptions. Like shown in the previous section you need to have Azure subscription to create resource groups and resources. It's important to carefully define a strategy for scaling your Azure subscriptions. Subscriptions are powerful way to organize Azure environment and make it more manageable.
This blog post doesn't concentrate modelling subscriptions and management groups because there is already a lot of good documentation provided by Microsoft. You can find more information from these sources: Create additional subscriptions to scale your Azure environment, What is an Azure landing zone? and Azure landing zone design principles.
How to model Resource Groups?
Consider the following principals when planning and organizing resource groups in a microservices environment. These are not in a prioritized order and you need to think case by case if one is important than another one.
Group by Microservice
Microservice architecture is a collection of independent microservices where each service typically reflect specific domain area. Let's imagine a product which has multiple independent microservices where one is responsible for invoicing and another about user management. Typically microservice is loosely coupled, independent deployable and scalable. Individual microservice owns the data and it's published to consumers via API.
In Azure it's natural to create a resource group per microservice. Resource group contains all required Azure resources for that specific microservice. If microservice needs an API and SQL database then all resources are in the same resource group. Typically resources are dedicated only for that specific microservice which ensure independence. There might be some exceptions if you need to optimize resource utilization from the cost efficiency point of view but you need to understand pros and cons of that decision. More info about this in the next section.
Resource group also enables that you easily manage access these resources in a resource group level. Basically you can determine that only Team X has access to specific microservice.
Cost efficiency
Even though microservices are independent sometimes might be wise from the cost efficiency point of view to share ex. compute and memory resources between multiple microservice. In this kind of scenario it's logical to group workload resources (App Service Plans) to a separate resource group (see below picture Workload Resource Group). Of course you need to be aware that then you cannot no longer scale microservices independently from compute/memory point of view.
You need to carefully evaluate what resources are worth to share between microservices.
Group shared resources by function
Shared resources are worth to group by the function. For example operations / maintenance related resources should be located to same resource group. This approach enables a powerful way to handle permissions to specific functions of the system.
Access policy and permissions
In Azure you can determine permissions in different levels of management hierarchy including also a resource and resource group level. Sometimes there might be situations where easiest way is just create a separate resource group and grant permissions in a resource group level. Typical scenario like this could be ex. add network related to resources to separate resource group and assign permissions in a resource group level only for network team.
It's also good to remember that Azure has multiple built-in RBAC (role-based access control) roles which enables you to control access above resource groups. For example if you have user which has WebSite Contributor RBAC role it enables that user can modify all App Service Plan across resource groups.
Cost reporting
You can easily monitor Azure costs in a resource group level. Sometimes might be justified to group resources so that cost reporting is easy as possible.
Sample microservices environment in Azure
This section introduces a sample microservice environment and how subscriptions and resource groups are organized.
Management Groups and Subscriptions
Management Groups are used here to help manage access, policy, and compliance across multiple subscriptions and area. Core area could have different policies than products area.
Resource share-ability
Sample environment is designed so that services and resources can be shared from two levels. First core level enables resource and services sharing to multiple subscriptions and second level inside individual subscription.
Core Azure subscription
Centralized resources and services like Express Route, Firewall and Audit Log storage are available for all subscriptions from Core Azure subscription. Core subscription has restricted access and product teams do not have direct access to these resources.
Core management group provides specific policies and compliance only for Core subscription.
Product specific Azure subscription
Product development department has multiple teams developing their own products and each team have own Azure subscription (called Azure Subscription Product). Each product specific Azure subscription is owned by different product teams and these teams has access only to their own Azure subscription.
Resource groups are categorized based on the following types
Shared Infra
Product specific Azure subscription has shared resources and services which are scope only for this specific Product Azure subscription. These shared resource groups are defined based on share-ability, cost efficiency and function.
Microservices
Each microservice ex. invoicing and user management have own resource groups.
Comments