Merge pull request #12310 from johndowns/multitenancy-overviews

Freshness review - Multitenancy overview articles

docs/guide/multitenant/approaches/overview-content.md

@@ -1,27 +1,27 @@
-There are many different ways that you can design and build multitenant solutions in Azure. At one extreme, you can share every resource in your solution among all of your tenants. At the other extreme, you can deploy isolated resources for every tenant. It might seem simple to deploy separate resources for every tenant, and it can work for a small numbers of tenants. However, it typically doesn't provide cost effectiveness, and it can become difficult to manage your resources. There are also various approaches that fit between these extremes, and they all have tradeoffs like scale, isolation, cost efficiency, performance, implementation complexity, and manageability.
+There are many different ways that you can design and build multitenant solutions in Azure. At one extreme, you can share every resource in your solution among all of your tenants. At the other extreme, you can deploy isolated resources for every tenant. It might seem simple to deploy separate resources for every tenant, and it can work for a small numbers of tenants. However, it typically doesn't provide cost efficiency, and it can become difficult to manage your resources. There are also various approaches that fit between these extremes, and they all require tradeoffs between scale, isolation, cost efficiency, performance, implementation complexity, and manageability.
 
 Throughout this section, we discuss the main categories of Azure services that comprise a solution, including [compute](compute.md), [storage and data](storage-data.yml), [networking](networking.md), [deployment](deployment-configuration.yml), [identity](identity.md), [messaging](messaging.md), [artificial intelligence and machine learning](ai-ml.md), and [IoT](iot.md). For each category, we outline the key patterns and approaches you can consider when you're designing a multitenant solution, and some antipatterns to avoid.
 
 ## Deployment Stamps pattern
 
-The [Deployment Stamps pattern](../../../patterns/deployment-stamp.yml) is frequently used in multitenant solutions. It involves deploying dedicated infrastructure for a tenant or for a group of tenants. A single stamp might contain multiple tenants or might be dedicated to a single tenant.
+The [Deployment Stamps pattern](../../../patterns/deployment-stamp.yml) is frequently used in multitenant solutions. It involves deploying dedicated infrastructure for a tenant or for a group of tenants. A single stamp might serve multiple tenants or might be dedicated to a single tenant.
 
-![Diagram showing the Deployment Stamps pattern. Each tenant has their own stamp containing a database.](media/overview/deployment-stamps.png)
+![Diagram showing an example implementation of the Deployment Stamps pattern. In this scenario, each tenant has their own stamp containing a database.](media/overview/deployment-stamps.png)
 
 When using single-tenant stamps, the Deployment Stamps pattern tends to be straightforward to implement, because each stamp is likely to be unaware of any other, so no multitenancy logic or capabilities need to be built into the application layer. When each tenant has their own dedicated stamp, this pattern provides the highest degree of isolation, and it mitigates the [Noisy Neighbor problem](../../../antipatterns/noisy-neighbor/noisy-neighbor.yml). It also provides the option for tenants to be configured or customized according to their own requirements, such as to be located in a specific geopolitical region or to have specific high availability requirements.
 
 When using multitenant stamps, other patterns need to be considered to manage multitenancy within the stamp, and the Noisy Neighbor problem still might apply. However, by using the Deployment Stamps pattern, you can continue to scale as your solution grows.
 
-The biggest problem with the Deployment Stamps pattern, when being used to serve a single tenant, tends to be the cost of the infrastructure. When using single-tenant stamps, each stamp needs to have its own separate set of infrastructure, which isn't shared with other tenants. You also need to ensure that the resources deployed for a stamp are sufficient to meet the peak load for that tenant's workload. Ensure that your [pricing model](../considerations/pricing-models.md) offsets the cost of deployment for the tenant's infrastructure.
+The biggest problem with the Deployment Stamps pattern, when being used to serve a single tenant, tends to be the cost of the infrastructure. Each stamp needs to have its own separate set of infrastructure, and the infrastructure isn't shared with other tenants. You also need to ensure that the resources deployed for a stamp are sufficient to meet the peak load for that tenant's workload. Ensure that your [pricing model](../considerations/pricing-models.md) offsets the cost of deployment for the tenant's infrastructure.
 
-Single-tenant stamps often work well when you have a small number of tenants. As your number of tenants grows, it's possible but increasingly difficult to manage a fleet of stamps ([see this case study as an example](https://devblogs.microsoft.com/azure-sql/running-1m-databases-on-azure-sql-for-a-large-saas-provider-microsoft-dynamics-365-and-power-platform)). You can also apply the Deployment Stamps pattern to create a fleet of multitenant stamps, which can provide benefits for resource and cost sharing.
+Single-tenant stamps often work well when you have a small number of tenants. As your number of tenants grows, it's possible but increasingly difficult to manage a fleet of single-tenant stamps ([see this case study as an example](https://devblogs.microsoft.com/azure-sql/running-1m-databases-on-azure-sql-for-a-large-saas-provider-microsoft-dynamics-365-and-power-platform)). You can also apply the Deployment Stamps pattern to create multitenant stamps, which can provide benefits for resource and cost sharing.
 
-To implement the Deployment Stamps pattern, it's important to use automated deployment approaches. Depending on your deployment strategy, you might consider managing your stamps within your deployment pipelines, by using declarative infrastructure as code, such as Bicep, ARM templates, or Terraform templates. Alternatively, you might consider building custom code to deploy and manage each stamp, such as by using [Azure SDKs](https://azure.microsoft.com/downloads).
+To implement the Deployment Stamps pattern, it's important to use automated deployment approaches. Depending on your deployment strategy, you might consider managing your stamps within your deployment pipelines, by using declarative infrastructure as code, such as Bicep files or Terraform templates. Alternatively, you might consider building custom code to deploy and manage each stamp, such as by using [Azure SDKs](https://azure.microsoft.com/downloads).
 
 ## Intended audience
 
 The articles in this section are intended to be useful for solution architects and lead developers of multitenant applications, including independent software vendors (ISVs) and startups who develop SaaS solutions. Much of the guidance in this section is generic and applies to multiple Azure services within a category.
 
 ## Next steps
 
-We recommend you review the [approaches for resource organization in a multitenant solution](resource-organization.yml) before reviewing the guidance about specific categories of Azure services.
+We recommend you review the [approaches for resource organization in a multitenant solution](resource-organization.yml) before reviewing the guidance about specific categories of Azure services.

docs/guide/multitenant/approaches/overview.yml

@@ -4,11 +4,12 @@ metadata:
   description: This article introduces the approaches you can consider when planning a multitenant architecture.
   author: johndowns
   ms.author: jodowns
-  ms.date: 02/28/2023
+  ms.date: 07/11/2024
   ms.topic: conceptual
   ms.service: architecture-center
   ms.subservice: azure-guide
-  ms.custom: fcp
+  ms.custom:
+  - arb-saas
 azureCategories:
   - management-and-governance
   - security

docs/guide/multitenant/overview.md

@@ -4,7 +4,7 @@ titleSuffix: Azure Architecture Center
 description: Learn how to build multitenant solutions on Azure through the guidance we provide in this series.
 author: johndowns
 ms.author: jodowns
-ms.date: 02/28/2023
+ms.date: 07/11/2024
 ms.topic: conceptual
 ms.service: architecture-center
 ms.subservice: azure-guide
@@ -13,10 +13,8 @@ products:
 categories:
   - management-and-governance
   - security
-ms.category:
-  - fcp
 ms.custom:
-  - guide
+  - arb-saas
 ---
 
 # Architect multitenant solutions on Azure
@@ -34,7 +32,7 @@ In this series, we provide guidance about how to design, build, and operate your
 > [!NOTE]
 > In this series, we use the term *tenant* to refer to **your** tenants, which might be your customers or groups of users. Our guidance is intended to help you to build your own multitenant software solutions on top of the Azure platform.
 >
-> Microsoft Entra ID also includes the concept of a tenant to refer to individual directories, and it uses the term *multitenancy* to refer to interactions between multiple Microsoft Entra tenants. Although the terms are the same, the concepts are not. When we need to refer to the Microsoft Entra concept of a tenant, we disambiguate it by using the full term *Microsoft Entra tenant*.
+> Microsoft Entra ID also includes the concept of a *tenant* to refer to individual directories, and it uses the term *multitenancy* to refer to interactions between multiple Microsoft Entra tenants. Although the terms are the same, the concepts are not. When we need to refer to the Microsoft Entra concept of a tenant, we disambiguate it by using the full term *Microsoft Entra tenant*.
 
 ## Scope
 
@@ -69,7 +67,7 @@ The content in this series is composed of three main sections:
 
   The service-specific guidance is useful for architects, lead developers, and anyone building or implementing Azure components for a multitenant solution.
 
-Additionally, we provide a [list of related resources and links](related-resources.md) for architects and developers of multitenant solutions.
+We also provide a [checklist to use when designing and building a multitenant solution](checklist.md), and a [list of related resources and links](related-resources.md) for architects and developers of multitenant solutions.
 
 ## Video
 

docs/guide/multitenant/service/overview.md

@@ -4,18 +4,16 @@ titleSuffix: Azure Architecture Center
 description: This article introduces the guidance we provide for using many distinct Azure services in a multitenant solution.
 author: johndowns
 ms.author: jodowns
-ms.date: 02/28/2023
+ms.date: 07/11/2024
 ms.topic: conceptual
 ms.service: architecture-center
 ms.subservice: azure-guide
 products:
   - azure
 categories:
   - management-and-governance
-ms.category:
-  - fcp
 ms.custom:
-  - guide
+  - arb-saas
 ---
 
 # Service-specific guidance for a multitenant solution