From 13aed6dffbcec9577166c703e5fffb4c813b8caf Mon Sep 17 00:00:00 2001 From: Dave Lusty <35692266+dalusty@users.noreply.github.com> Date: Mon, 29 Jul 2019 11:29:41 +0100 Subject: [PATCH 1/4] Added data lake example Data lakes and analytics platforms are a very common first use-case for cloud adoption so I've added this as an example --- docs/cloud-adoption/business-strategy/first-adoption-project.md | 1 + 1 file changed, 1 insertion(+) 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 From c706c56889649e7288d561a984df4b12069027b5 Mon Sep 17 00:00:00 2001 From: Adam Boeglin Date: Thu, 1 Aug 2019 09:34:45 -0700 Subject: [PATCH 2/4] Build experimental TOC --- docs/docfx.json | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) 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", From 0fc852d2227a9c983552ccd6c3d435f6dd65152f Mon Sep 17 00:00:00 2001 From: Brian Blanchard Date: Thu, 1 Aug 2019 14:17:15 -0500 Subject: [PATCH 3/4] Remove Storage Decision Tree per PG requirements. --- docs/cloud-adoption/ready/considerations/storage-guidance.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) 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 From e9767409d1b66f00dc843177995c91211e0401cc Mon Sep 17 00:00:00 2001 From: DixitArora-MSFT <46984568+DixitArora-MSFT@users.noreply.github.com> Date: Fri, 2 Aug 2019 00:51:42 +0530 Subject: [PATCH 4/4] Correcting Doc in Auto Scale (#1675) (AzureCXP) fixes MicrosoftDocs/architecture-center#1669 --- .../contoso-migration-refactor-linux-app-service-mysql.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) 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)