How to model and organize Azure resource groups in a microservices environment?

This blog post introduces some principles to consider when modeling and organizing resource groups & resources in a 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. The governance model provides management tools to ensure that services across multiple subscriptions are created according to agreed patterns and that security & compliance requirements are fulfilled. Some actions in the governance model can be automatized using ex. azure policies.  I'll write more later about the governance model in Azure.

Management Hierarchy in Azure

This blog post concentrates on the lowest hierarchy level and especially how to model resource groups in an environment that utilizes 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 management hierarchy in Azure:

Source: Organize your Azure resources effectively

Scaling Azure subscriptions

Let's discuss first briefly about Azure subscriptions. As shown in the previous section you need to have an Azure subscription to create resource groups and resources. It's important to carefully define a strategy for scaling your Azure subscriptions. Subscriptions are a powerful way to organize Azure environment and make it more manageable.

This blog post doesn't concentrate on modeling 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 principles 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 reflects a specific domain area. Let's imagine a product that has multiple independent microservices where one is responsible for invoicing and another about user management. Typically microservice is loosely coupled, independently 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. The resource group contains all required Azure resources for that specific microservice. If a 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 ensures 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 the pros and cons of that decision. More info about this in the next section.

Resource group also enables you to easily manage access to these resources at a resource group level. Basically, you can determine that only Team X has access to specific microservices.

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 microservices. In this kind of scenario, it's logical to group workload resources (App Service Plans) into a separate resource group (see below picture Workload Resource Group). Of course, you need to be aware that then you cannot any longer scale microservices independently from a compute/memory point of view. 

You need to carefully evaluate what resources are worth sharing between microservices.

The group shared resources by function

Shared resources are worth grouping by function. For example, operations/maintenance-related resources should be located in 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 the easiest way is just to create a separate resource group and grant permissions at a resource group level. A typical scenario like this could be ex. add network related to resources to separate resource groups and assign permissions at a resource group level only for the 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 a user who has a WebSite Contributor RBAC role it enables that user can modify all App Service Plans across resource groups.

Cost reporting

You can easily monitor Azure costs at a resource group level. Sometimes might be justified to group resources so that cost reporting is as 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 areas. The core area could have different policies than the products area.

Resource share-ability

The sample environment is designed so that services and resources can be shared from two levels. The first core level enables resource and service sharing to multiple subscriptions and the second level is 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.

The core management group provides specific policies and compliance only for Core subscriptions. 

Product-specific Azure subscription

The product development department has multiple teams developing their own products and each team has its own Azure subscription (called Azure Subscription Product). Each product-specific Azure subscription is owned by different product teams and these teams have 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 their own resource groups.