Merge pull request #12350 from johndowns/multitenant-freshness

Multitenancy - Freshness reviews
MicrosoftDocs · Jul 17, 2024 · fab01da · fab01da
2 parents 9187e38 + de72e4a
commit fab01da
Show file tree

Hide file tree

Showing 4 changed files with 18 additions and 18 deletions.
diff --git a/docs/guide/multitenant/considerations/domain-names-content.md b/docs/guide/multitenant/considerations/domain-names-content.md
@@ -4,7 +4,7 @@ In many multitenant web applications, a domain name can be used as a way to iden
 
 Each tenant might get a unique subdomain under a common shared domain name, using a format like `tenant.provider.com`.
 
-Let's consider an example multitenant solution built by Contoso. Customers purchase Contoso's product to help manage their invoice generation. All of Contoso's tenants might be assigned their own subdomain, under the `contoso.com` domain name. Or, if Contoso uses regional deployments, they might assign subdomains under the `us.contoso.com` and `eu.contoso.com` domains. In this article, we refer to these as *stem domains*. Each customer gets their own subdomain under your stem domain. For example, Tailwind Toys might be assigned `tailwind.contoso.com`, and Adventure Works might be assigned `adventureworks.contoso.com`.
+Let's consider an example multitenant solution built by Contoso. Customers purchase Contoso's product to help manage their invoice generation. All of Contoso's tenants might be assigned their own subdomain, under the `contoso.com` domain name. Or, if Contoso uses regional deployments, they might assign subdomains under the `us.contoso.com` and `eu.contoso.com` domains. In this article, we refer to these as *stem domains*. Each customer gets their own subdomain under your stem domain. For example, Tailwind Toys might be assigned `tailwind.contoso.com`, and in a regional deployment model, Adventure Works might be assigned `adventureworks.us.contoso.com`.
 
 > [!NOTE]
 > Many Azure services use this approach. For example, when you create an Azure storage account, it is assigned a set of subdomains for you to use, such as `<your account name>.blob.core.windows.net`.
@@ -15,7 +15,7 @@ When you create subdomains under your own domain name, you need to be mindful th
 
 ### Wildcard DNS
 
-Consider using wildcard DNS entries to simplify the management of subdomains. Instead of creating DNS entries for `tailwind.contoso.com`, `adventureworks.contoso.com`, and so forth, you could instead create a wildcard entry for `*.contoso.com` and direct all subdomains to single IP address (A record) or canonical name (CNAME record).
+Consider using wildcard DNS entries to simplify the management of subdomains. Instead of creating DNS entries for `tailwind.contoso.com`, `adventureworks.contoso.com`, and so forth, you could instead create a wildcard entry for `*.contoso.com` and direct all subdomains to single IP address (A record) or canonical name (CNAME record). If you use regional stem domains, you might need multiple wildcard entries, such as `*.us.contoso.com` and `*.eu.contoso.com`.
 
 > [!NOTE]
 > Make sure that your web-tier services support wildcard DNS, if you plan to rely on this feature. Many Azure services, including Azure Front Door and Azure App Service, support wildcard DNS entries.
@@ -66,7 +66,7 @@ You might want to enable your customers to bring their own domain names. Some cu
 
 Ultimately, each domain name needs to be resolved to an IP address. As you've seen, the approach by which name resolution happens can depend on whether you deploy a single instance or multiple instances of your solution.
 
-Let's return to our example. One of Contoso's customers, Fabrikam, has asked to use `invoices.fabrikam.com`, as their custom domain name to access Contoso's service. Because Contoso has multiple deployments of their platform, they decide to use subdomains and CNAME records to achieve their routing requirements. Contoso and Fabrikam configure the following DNS records:
+Let's return to our example. One of Contoso's customers, Fabrikam, has asked to use `invoices.fabrikam.com` as their custom domain name to access Contoso's service. Because Contoso has multiple deployments of their multitenant platform, they decide to use subdomains and CNAME records to achieve their routing requirements. Contoso and Fabrikam configure the following DNS records:
 
 | Name | Record type | Value | Configured by |
 |-|-|-|-|
@@ -111,12 +111,14 @@ Common strategies to protect against dangling DNS attacks are:
 
 Transport Layer Security (TLS) is an essential component when working with modern applications. It provides trust and security to your web applications. The ownership and management of TLS certificates is something that needs careful consideration for multitenant applications.
 
-Typically, the owner of a domain name will be responsible for issuing and renewing its certificates. For example, Contoso is responsible for issuing and renewing TLS certificates for `us.contoso.com`, as well as a wildcard certificate for `*.contoso.com`. Similarly, Fabrikam would generally be responsible for managing any records for the `fabrikam.com` domain, including `invoices.fabrikam.com`. The CAA (Certificate Authority Authorization) DNS record type can be used by a domain owner. CAA records ensure that only specific authorities can create certificates for the domain.
+Typically, the owner of a domain name is responsible for issuing and renewing its certificates. For example, Contoso is responsible for issuing and renewing TLS certificates for `us.contoso.com`, as well as a wildcard certificate for `*.contoso.com`. Similarly, Fabrikam would generally be responsible for managing any records for the `fabrikam.com` domain, including `invoices.fabrikam.com`.
 
-If you plan to allow customers to bring their own domains, consider whether you plan to issue the certificate on the customer's behalf, or whether the customers must bring their own certificates. Each option has benefits and drawbacks.
+The CAA (Certificate Authority Authorization) DNS record type can be used by a domain owner. CAA records ensure that only specific authorities can create certificates for the domain.
 
-- If you issue a certificate for a customer, you can handle the renewal of the certificate, so the customer doesn't have to remember to keep it updated. However, if the customers have CAA records on their domain names, they might need to authorize you to issue certificates on their behalf.
-- If you expect customers should issue and provide you with their own certificates, you are responsible for receiving and managing the private keys in a secure manner, and you might have to remind your customers to renew the certificate before it expires, to avoid an interruption in their service.
+If you plan to allow customers to bring their own domains, consider whether you plan to issue the certificate on the customer's behalf, or whether the customers must bring their own certificates. Each option has benefits and drawbacks:
+
+- **If you issue a certificate for a customer,** you can handle the renewal of the certificate, so the customer doesn't have to remember to keep it updated. However, if the customers have CAA records on their domain names, they might need to authorize you to issue certificates on their behalf.
+- **If you expect customers to issue and provide you with their own certificates,** you are responsible for receiving and managing the private keys in a secure manner, and you might have to remind your customers to renew the certificate before it expires, to avoid an interruption in their service.
 
 Several Azure services support automatic management of certificates for custom domains. For example, Azure Front Door and App Service provide certificates for custom domains, and they automatically handle the renewal process. This removes the burden of managing certificates, from your operations team. However, you still need to consider the question of ownership and authority, such as whether CAA records are in effect and configured correctly. Also, you need to ensure your customers' domains are configured to allow the certificates that are managed by the platform.
 
@@ -126,7 +128,7 @@ Several Azure services support automatic management of certificates for custom d
 
 Principal author:
 
- * [John Downs](http://linkedin.com/in/john-downs) | Principal Customer Engineer, FastTrack for Azure
+ * [John Downs](http://linkedin.com/in/john-downs) | Principal Software Engineer
 
 Other contributors:
 

diff --git a/docs/guide/multitenant/considerations/domain-names.yml b/docs/guide/multitenant/considerations/domain-names.yml
@@ -4,7 +4,7 @@ metadata:
   description: This article describes the considerations you need to give to domain names when building multitenant web applications.
   author: johndowns
   ms.author: jodowns
-  ms.date: 02/28/2023
+  ms.date: 07/18/2024
   ms.topic: conceptual
   ms.service: architecture-center
   ms.subservice: azure-guide

diff --git a/docs/guide/multitenant/considerations/overview-content.md b/docs/guide/multitenant/considerations/overview-content.md
@@ -1,23 +1,21 @@
 When you're considering a multitenant architecture, there are several decisions you need to make and elements you need to consider.
 
-In a multitenant architecture, you share some or all of your resources between tenants. This process means that a multitenant architecture can give you cost and operational efficiency. However, multitenancy introduces complexities, including the following:
+In a multitenant architecture, you share some or all of your resources between tenants. This process means that a multitenant architecture can give you cost and operational efficiency. However, multitenancy introduces complexities. You need to ask yourself the following questions:
 
-- How do you define what a *tenant* is, for your specific solution? Does a tenant correspond to a customer, a user, or a group of users (like a team)?
+- How do you define what a *tenant* is, for your specific solution? Does a tenant correspond to a customer, a user, or a group of users like a team or a family?
 - How will you deploy your infrastructure to support multitenancy, and how much isolation will you have between tenants?
 - What commercial pricing models will your solution offer, and how will your pricing models affect your multitenancy requirements?
-- What level of service do you need to provide to your tenants? Consider performance, resiliency, security, and compliance requirements, like data residency.
-- How do you plan to grow your business or solution, and will it scale to the number of tenants you expect?
+- What level of service do you need to provide to your tenants, across dimensions like performance, resiliency, security, and compliance requirements like data residency?
+- How do you plan to grow your business or solution? Will it scale to the number of tenants you expect?
 - Do any of your tenants have unusual or special requirements? For example, does your biggest customer need higher performance or stronger guarantees than others?
-- How will you monitor, manage, automate, scale, and govern your Azure environment, and how will multitenancy impact this?
+- How will you monitor, manage, automate, scale, and govern your Azure environment, and how will multitenancy impact your management strategy?
 - Which components of your solution handle tenant onboarding and management, and how should these components be designed?
 
-## Requirements
-
 Whatever your architecture, it's essential that you have a clear understanding of your customers' or tenants' requirements. If you have made sales commitments to customers, or if you have contractual obligations or compliance requirements to meet, then you need to know what those requirements are when you architect your solution. But equally, your customers might have implicit expectations about how things *should* work, or how you *should* behave, which could affect the way you design a multitenant solution.
 
 As an example, imagine you're building a multitenant solution that you sell to businesses in the financial services industry. Your customers have very strict security requirements, and they need you to provide a comprehensive list of every domain name that your solution uses, so they can add it to their firewall's allowlist. This requirement affects the Azure services you use and the level of isolation that you have to provide between your tenants. They also require that their solution has a minimum level of resiliency. There might be many similar expectations, both explicit and implicit, that you need to consider across your whole solution.
 
-In this section, we outline the considerations that you should give, the requirements you should elicit, and some of the tradeoffs you need to make, when you are planning a multitenant architecture.
+In this section, we outline some of the considerations that you should give, the requirements you should elicit, and some of the tradeoffs you need to make, when you are planning a multitenant architecture.
 
 ## Intended audience
 

diff --git a/docs/guide/multitenant/considerations/overview.yml b/docs/guide/multitenant/considerations/overview.yml
@@ -4,7 +4,7 @@ metadata:
   description: This article introduces the key considerations when planning a multitenant architecture.
   author: johndowns
   ms.author: jodowns
-  ms.date: 02/28/2023
+  ms.date: 07/18/2024
   ms.topic: conceptual
   ms.service: architecture-center
   ms.subservice: azure-guide