diff --git a/docs/cloud-adoption/business-strategy/first-adoption-project.md b/docs/cloud-adoption/business-strategy/first-adoption-project.md index cbaa6d6ac83..c120143af0b 100644 --- a/docs/cloud-adoption/business-strategy/first-adoption-project.md +++ b/docs/cloud-adoption/business-strategy/first-adoption-project.md @@ -58,6 +58,7 @@ Additional examples of first adoption projects include: - **Dev/test:** Remove dev/test from on-premises environments to give developers control, agility, and self-service capacity. - **Simple apps (less than five):** Modernize and migrate a simple app to quickly gain developer and operations experience. - **Performance labs:** When you need high-scale performance in a lab setting, use the cloud to quickly and cost-effectively provision those labs for a short time. +- **Data Platform:** Creating a data lake with scalable compute for analytics, reporting or machine learning workloads. ## Next steps diff --git a/docs/cloud-adoption/migrate/azure-best-practices/contoso-migration-refactor-linux-app-service-mysql.md b/docs/cloud-adoption/migrate/azure-best-practices/contoso-migration-refactor-linux-app-service-mysql.md index dc1ec2779c8..6bef99d785c 100644 --- a/docs/cloud-adoption/migrate/azure-best-practices/contoso-migration-refactor-linux-app-service-mysql.md +++ b/docs/cloud-adoption/migrate/azure-best-practices/contoso-migration-refactor-linux-app-service-mysql.md @@ -300,7 +300,7 @@ Finally, they set up automatic scaling for the app. This ensures that as agents ![Autoscale](./media/contoso-migration-refactor-linux-app-service-mysql/autoscale1.png) -3. They configure the same setting on **APP-SRV-CUS** to ensure that the same behavior applies if the app fails over to the secondary region. The only difference is that they set the instance limit to 1 since this is for failovers only. +3. They configure the same setting on **APP-SRV-CUS** to ensure that the same behavior applies if the app fails over to the secondary region. The only difference is that they set the default instance to 1 since this is for failovers only. ![Autoscale](./media/contoso-migration-refactor-linux-app-service-mysql/autoscale2.png) diff --git a/docs/cloud-adoption/ready/considerations/storage-guidance.md b/docs/cloud-adoption/ready/considerations/storage-guidance.md index 361e0711e18..cc2ce796c4a 100644 --- a/docs/cloud-adoption/ready/considerations/storage-guidance.md +++ b/docs/cloud-adoption/ready/considerations/storage-guidance.md @@ -18,9 +18,10 @@ Storage capabilities are critical for supporting workloads and services that are [Azure Storage](/azure/storage) is the Azure platform's managed service for providing cloud storage. Azure Storage is composed of several core services and supporting features. Storage in Azure is highly available, secure, durable, scalable, and redundant. Review the scenarios and considerations described here to choose the relevant Azure services and the correct architectures to fit your organization's workload, governance, and data storage requirements. -For each application or service you'll deploy to your landing zone environment, use the following decision tree as a starting point to help you determine your storage resources requirements: + ### Key questions diff --git a/docs/docfx.json b/docs/docfx.json index 565041459d8..2c4a21f33b0 100644 --- a/docs/docfx.json +++ b/docs/docfx.json @@ -7,6 +7,7 @@ "files": [ "**/*.md", "**/toc.yml", + "**/toc.experimental.yml", "**/*context.yml" ], "exclude": [ @@ -66,9 +67,6 @@ ] }, "fileMetadata": { - "tocRel": { - "reference-architectures/**.md": "../toc.json" - }, "feedback_product_url": { "example-scenario/**/*.md": "https://azure-architecture.uservoice.com/forums/918625-architecture-guidance", "guide/**/*.md": "https://azure-architecture.uservoice.com/forums/918628-cloud-fundamentals",