Merge pull request #434 from MicrosoftDocs/master

8/8/2019 AM Publish

docs/best-practices/naming-conventions.md

@@ -43,6 +43,8 @@ A recommended pattern for naming subscriptions is:
 | Contoso |IT |InternalApps |Production |Contoso IT InternalApps Production |
 | Contoso |IT |InternalApps |Dev |Contoso IT InternalApps Dev |
 
+Like all Azure services, there are limits placed on the value of Subscription Names. The length must be 1-64 characters and they must be alphanumeric and cannot contain these characters: `<` `>` `;` `|`.
+
 For more information on how to organize subscriptions for larger enterprises, see [Azure enterprise scaffold - prescriptive subscription governance](/azure/architecture/cloud-adoption/appendix/azure-scaffold).
 
 ## Use affixes to avoid ambiguity
@@ -99,11 +101,11 @@ In general, avoid having any special characters (`-` or `_`) as the first or las
 | --- | --- | --- | --- | --- | --- | --- |
 |Storage account name (data) |Global |3-24 |Lowercase |Alphanumeric |`<globally unique name><number>` (use a function to calculate a unique guid for naming storage accounts) |`profxdata001` |
 |Storage account name (disks) |Global |3-24 |Lowercase |Alphanumeric |`<vm name without hyphens>st<number>` |`profxsql001st0` |
-| Container name |Storage account |3-63 |Lowercase |0-9, a-z, A-Z and - |`<context>` |`logs` |
+| Container name |Storage account |3-63 |Lowercase |0-9, a-z and - |`<context>` |`logs` |
 |Blob name | Container |1-1024 |Case sensitive |Any URL characters |`<variable based on blob usage>` |`<variable based on blob usage>` |
-|Queue name |Storage account |3-63 |Lowercase |0-9, a-z, A-Z and - |`<service short name>-<context>-<num>` |`awesomeservice-messages-001` |
+|Queue name |Storage account |3-63 |Lowercase |0-9, a-z and - |`<service short name>-<context>-<num>` |`awesomeservice-messages-001` |
 |Table name | Storage account |3-63 |Case insensitive |Alphanumeric |`<service short name><context>` |`awesomeservicelogs` |
-|File share name | Storage account |3-63 |Lowercase | 0-9, a-z, A-Z and - |`<variable based on file share usage>` |`<variable based on file share usage>` |
+|File share name | Storage account |3-63 |Lowercase | 0-9, a-z and - |`<variable based on file share usage>` |`<variable based on file share usage>` |
 |Data Lake Store | Global |3-24 |Lowercase | Alphanumeric |`<name>dls` |`telemetrydls` |
 |Managed Disk name | Resource Group | 1-80 | Case insensitive |Alphanumeric, hyphen and underscore but not on character 1|`<disktype>disk<number>`|`OSdisk1`|
 

docs/cloud-adoption/migrate/azure-migration-guide/manage-costs.md

@@ -22,7 +22,7 @@ The tools in this article include:
 > - Azure Migrate
 > - Azure pricing calculator
 > - Azure TCO calculator
-> - Azure Cost Management by Cloudyn
+> - Azure Cost Management
 > - Azure Advisor
 
 The processes described in this article may also require a partnership with IT managers, finance, or line-of-business application owners. For guidance on partnering with these roles, see the Cloud Adoption Framework article on establishing a cost-conscious organization (coming in Q3 2019).

docs/cloud-adoption/migrate/index.md

@@ -15,12 +15,6 @@ layout: LandingPage
 
 Any enterprise-scale [cloud adoption plan](../plan/index.md), will include workloads which do not warrant significant investments in the creation of new business logic. Those workloads could be moved to the cloud through any number of approaches; Lift & Shift, Lift & Optimize, or Modernize. Each of which is considered a migration. The following exercises will help establish the iterative processes to assess, migrate, optimize, secure and manage those workloads.
 
-## Iterative migration process
-
-At its core, migration to the cloud consists of four simple phases: Assess, Migrate, Optimize, and Secure & Manage. This section of CAF teaches readers to maximize the return from each phase of the process and align those phases with your cloud adoption plan. The following graphic illustrates those phases in an iterative approach:
-
-![Cloud Adoption Framework migration model](../_images/operational-transformation-migrate.png)
-
 ## Getting started
 
 To prepare you for this phase of the cloud adoption lifecycle, the framework suggests the following five exercises:
@@ -125,6 +119,12 @@ To prepare you for this phase of the cloud adoption lifecycle, the framework sug
 </ul>
 <!-- markdownlint-enable MD033 -->
 
+## Iterative migration process
+
+At its core, migration to the cloud consists of four simple phases: Assess, Migrate, Optimize, and Secure & Manage. This section of CAF teaches readers to maximize the return from each phase of the process and align those phases with your cloud adoption plan. The following graphic illustrates those phases in an iterative approach:
+
+![Cloud Adoption Framework migration model](../_images/operational-transformation-migrate.png)
+
 ## Creating a balanced cloud portfolio
 
 Any balanced technology portfolio has a mixture of assets in various states. Some applications are scheduled for retirement and given minimal support. Other applications or assets are supported in a maintenance state, but the features of those solutions are stable. For newer business processes, changing market conditions will likely spur ongoing feature enhancements or modernization. When opportunities to drive new revenue streams arise, new applications or assets are introduced into the environment. At each stage of an asset's lifecycle, the impact any investment has on revenue and profit will change. The later the lifecycle stage, the less likely a new feature or modernization effort will yield a strong return on investment.
@@ -135,8 +135,6 @@ The cloud provides various adoption mechanisms, each with similar degrees of inv
 
 An effective journey needs a target destination. Establish a rough vision of the end state before taking the first step. This infographic outlines a starting point consisting of existing applications, data, and infrastructure, which defines the digital estate. During the migration process, each asset is transitioned via one of the options on the right.
 
-![Infographic of the migration options](../_images/migration/migration-options.png)
-
 ## Migration implementation
 
 These articles outlines two journeys, each with a similar goal&mdash;to migrate a large percentage of existing assets to Azure. However, the business outcomes and current state will significantly influence the processes required to get there. Those subtle deviations result in two radically different approaches to reaching a similar end state.

docs/data-guide/technology-choices/data-science-and-machine-learning.md

@@ -51,6 +51,7 @@ The following development platforms and tools are available for machine learning
 | [Azure Databricks](#azure-databricks) | Spark-based analytics platform | Build and deploy models and data workflows |
 | [ML.NET](#mlnet) | Open-source, cross-platform machine learning SDK | Develop machine learning solutions for .NET applications |
 | [Windows ML](#windows-ml) | Windows 10 machine learning platform | Evaluate trained models on a Windows 10 device |
+| [MMLSpark](#mmlspark) | Open-source, distributed, machine learning and microservice framework for Apache Spark | Create and deploy scalable machine learning applications for Scala and Python. |
 
 ## Azure Machine Learning service
 
@@ -182,6 +183,19 @@ Use Windows ML when you want to use trained machine learning models within your
 |**Type**                   |Inference engine for trained models in Windows devices|
 |**Languages supported**    |C#/C++, JavaScript|
 
+## MMLSpark
+[Microsoft ML for Apache Spark](https://aka.ms/spark/) (MMLSpark) is an open source library that expands the distributed computing framework [Apache Spark](https://spark.apache.org/). MMLSpark adds many deep learning and data science tools to the Spark ecosystem, including seamless integration of [Spark Machine Learning](https://spark.apache.org/docs/latest/ml-guide.html) pipelines with [Microsoft Cognitive Toolkit (CNTK)](https://docs.microsoft.com/en-us/cognitive-toolkit/), [LightGBM](https://github.com/microsoft/LightGBM), [LIME (Model Interpretability)](https://www.oreilly.com/learning/introduction-to-local-interpretable-model-agnostic-explanations-lime), and [OpenCV](https://opencv.org/). You can use these tools to create powerful predictive models on any Spark cluster, such as [Azure Databricks](#azure-databricks) or [Cosmic Spark](https://docs.microsoft.com/en-us/azure/cosmos-db/spark-api-introduction).
+
+MMLSpark also brings new networking capabilities to the Spark ecosystem. With the HTTP on Spark project, users can embed any web service into their SparkML models. Additionally, MMLSpark provides easy-to-use tools for orchestrating [Microsoft Cognitive Services](https://azure.microsoft.com/en-us/services/cognitive-services/) at scale. For production-grade deployment, the Spark Serving project enables high throughput, sub-millisecond latency web services, backed by your Spark cluster.
+
+|||
+|-|-|
+|**Type**                    |Open-source, distributed machine learning and microservice framework for Apache Spark|
+|**Languages supported**     |Scala 2.11, Java, Python 3.5+, R (beta)|
+|**Machine learning phases** |Data preparation<br>Model training<br>Deployment|
+|**Key benefits**            |Scalability<br>Streaming + Serving compatible<br>Fault-tolerance|
+|**Considerations**          |Requires Apache Spark|
+
 ## Next steps
 
 - To learn about all the Artificial Intelligence (AI) development products available from Microsoft, see [Microsoft AI platform](https://www.microsoft.com/ai)

docs/guide/index.md

@@ -87,3 +87,7 @@ Learn more:
 A successful cloud application will focus on five pillars of software quality: Scalability, availability, resiliency, management, and security. Use our design review checklists to review your architecture according to these quality pillars.
 
 - [Quality pillars](./pillars.md)
+
+### More Learning
+
+For an guided introduction to common cloud computing services, benefits of cloud computing, and cloud deployment modules,  review the [Cloud Concepts - Principles of Cloud Computing](/learn/modules/principles-cloud-computing/) on [Microsoft Learn](/learn/).

docs/reference-architectures/enterprise-integration/basic-enterprise-integration.md

@@ -51,7 +51,7 @@ Your specific requirements might differ from the generic architecture shown here
 
 Use the API Management Basic, Standard, or Premium tiers. These tiers offer a production service level agreement (SLA) and support scale out within the Azure region. Throughput capacity for API Management is measured in *units*. Each pricing tier has a maximum scale-out. The Premium tier also supports scale out across multiple Azure regions. Choose your tier based on your feature set and the level of required throughput. For more information, see [API Management pricing][apim-pricing] and [Capacity of an Azure API Management instance][apim-capacity].
 
-Each Azure API Management instance has a default domain name, which is a subdomain of `azure-api.net` &mdash, for example, `contoso.azure-api.net`. Consider configuring a [custom domain][apim-domain] for your organization.
+Each Azure API Management instance has a default domain name, which is a subdomain of `azure-api.net`, for example, `contoso.azure-api.net`. Consider configuring a [custom domain][apim-domain] for your organization.
 
 ### Logic Apps