Merge pull request #453 from MicrosoftDocs/master

Publish to live

docs/guide/index.md

@@ -32,7 +32,7 @@ Relational database<br/>
 Strong consistency<br/>
 Serial and synchronized processing<br/>
 Design to avoid failures (MTBF)<br/>
-Occasional large updates<br/>
+Occasional big updates<br/>
 Manual management<br/>
 Snowflake servers</td>
 <td>
@@ -67,18 +67,16 @@ Learn more:
 
 ### Technology choices
 
-Two technology choices should be decided early on, because they affect the entire architecture. These are the choice of compute service and data stores. *Compute* refers to the hosting model for the computing resources that your applications run on. *Data stores include databases but also storage for message queues, caches, logs, and anything else that an application might persist to storage.
+Two technology choices should be decided early on, because they affect the entire architecture. These are the choice of compute service and data stores. *Compute* refers to the hosting model for the computing resources that your applications runs on. *Data stores* includes databases but also storage for message queues, caches, logs, and anything else that an application might persist to storage.
 
 Learn more:
 
 - [Choosing a compute service](./technology-choices/compute-overview.md)
 - [Choosing a data store](./technology-choices/data-store-overview.md)
 
-While it depends on your application's requirements, there is a high likelihood that you will also need to choose the right load-balancing services for your application early on in the architectural discussions. *Load balancing* defines how the traffic for your application will be distributed to your compute service. Learn more at [Choosing a load balancing service](./technology-choices/load-balancing-overview.md)
-
 ### Design principles
 
-We have identified ten high-level design principles that will make your application more scalable, resilient, and manageable. These design principles apply to any architecture styles. Throughout the design process, keep these ten high-level design principles in mind. Then consider the set of best practices for specific aspects of the architecture, such as autoscaling, caching, data partitioning, API design, and others.
+We have identified ten high-level design principles that will make your application more scalable, resilient, and manageable. These design principles apply to any architecture styles. Throughout the design process, keep these ten high-level design principles in mind. Then consider the set of best practices for specific aspects of the architecture, such as auto-scaling, caching, data partitioning, API design, and others.
 
 Learn more:
 

docs/guide/technology-choices/compute-comparison.md

@@ -12,7 +12,7 @@ ms.custom: seojan19
 
 # Criteria for choosing an Azure compute service
 
-The term *compute* refers to the hosting model for the computing resources that your applications run on. The following tables compare Azure compute services across several axes. Refer to these tables when selecting a compute option for your application.
+The term *compute* refers to the hosting model for the computing resources that your applications runs on. The following tables compare Azure compute services across several axes. Refer to these tables when selecting a compute option for your application.
 
 ## Hosting model
 
@@ -43,7 +43,7 @@ Notes
 | Criteria | Virtual Machines | App Service | Service Fabric | Azure Functions | Azure Kubernetes Service | Container Instances | Azure Batch |
 |----------|-----------------|-------------|----------------|-----------------|-------------------------|----------------|-------------|
 | Local debugging | Agnostic | IIS Express, others <a href="#note1b"><sup>1</sup></a> | Local node cluster | Visual Studio or Azure Functions CLI | Minikube, others | Local container runtime | Not supported |
-| Programming model | Agnostic | Web and API applications, WebJobs for background tasks | Guest executable, Service model, Actor model, Containers | Functions with triggers | Agnostic | Agnostic | Command-line application |
+| Programming model | Agnostic | Web and API applications, WebJobs for background tasks | Guest executable, Service model, Actor model, Containers | Functions with triggers | Agnostic | Agnostic | Command line application |
 | Application update | No built-in support | Deployment slots | Rolling upgrade (per service) | Deployment slots | Rolling update | Not applicable |
 
 Notes
@@ -57,7 +57,7 @@ Notes
 |----------|-----------------|-------------|----------------|-----------------|-------------------------|----------------|-------------|
 | Autoscaling | Virtual machine scale sets | Built-in service | Virtual machine scale sets | Built-in service | Not supported | Not supported | N/A |
 | Load balancer | Azure Load Balancer | Integrated | Azure Load Balancer | Integrated | Integrated |  No built-in support | Azure Load Balancer |
-| Scale limit<a href="#note1c"><sup>1</sup></a> | Platform image: 1000 nodes per virtual machine scale set, Custom image: 100 nodes per virtual machine scale set | 20 instances, 100 with App Service Environment | 100 nodes per virtual machine scale set | 200 instances per Function app | 100 nodes per cluster (default limit) |20 container groups per subscription (default limit). | 20 core limit (default limit). |
+| Scale limit<a href="#note1c"><sup>1</sup></a> | Platform image: 1000 nodes per VMSS, Custom image: 100 nodes per VMSS | 20 instances, 100 with App Service Environment | 100 nodes per VMSS | 200 instances per Function app | 100 nodes per cluster (default limit) |20 container groups per subscription (default limit). | 20 core limit (default limit). |
 
 Notes
 
@@ -68,7 +68,7 @@ Notes
 | Criteria | Virtual Machines | App Service | Service Fabric | Azure Functions | Azure Kubernetes Service | Container Instances | Azure Batch |
 |----------|-----------------|-------------|----------------|-----------------|-------------------------|----------------|-------------|
 | SLA | [SLA for Virtual Machines][sla-vm] | [SLA for App Service][sla-app-service] | [SLA for Service Fabric][sla-sf] | [SLA for Functions][sla-functions] | [SLA for AKS][sla-acs] | [SLA for Container Instances](https://azure.microsoft.com/support/legal/sla/container-instances/) | [SLA for Azure Batch][sla-batch] |
-| Multi region failover | Azure Front Door (HTTP/HTTPS) </br> Traffic manager (Other) | Azure Front Door | Azure Front Door (HTTP/HTTPS) </br> Traffic manager (Other), Multi-Region Cluster | Azure Front Door | Azure Front Door (HTTP/HTTPS) </br> Traffic manager (Other) | Not supported | Not Supported |
+| Multi region failover | Traffic manager | Traffic manager | Traffic manager, Multi-Region Cluster | Not supported | Traffic manager | Not supported | Not Supported |
 
 For guided learning on Service Guarantees, review [Core Cloud Services - Azure architecture and service guarantees](/learn/modules/explore-azure-infrastructure).