Review complete with small revisions. (#6044)

Author: ardalis

docs/standard/serverless-architecture/application-insights.md

@@ -7,7 +7,7 @@ ms.date: 05/24/2018
 ---
 # Telemetry with Application Insights
 
-[Application Insights](/azure/application-insights) is a serverless diagnostics platform that enables developers to detect, triage, and diagnose issues in web apps, mobile apps, desktop apps, and microservices. You can turn on Application Insights for function apps simply by flipping a switch in the portal. Application insights provides all of these capabilities without you having to configure a server or set up your own database. All of Application Insight's capabilities are provided as a service that automatically integrates with your apps.
+[Application Insights](/azure/application-insights) is a serverless diagnostics platform that enables developers to detect, triage, and diagnose issues in web apps, mobile apps, desktop apps, and microservices. You can turn on Application Insights for function apps simply by flipping a switch in the portal. Application Insights provides all of these capabilities without you having to configure a server or set up your own database. All of Application Insights' capabilities are provided as a service that automatically integrates with your apps.
 
 ![Application Insights logo](./media/application-insights-logo.png)
 

docs/standard/serverless-architecture/architecture-approaches.md

@@ -25,7 +25,7 @@ Many business applications follow a monolith pattern. Legacy applications are of
 
 There are several advantages to the monolith approach. It is often easy to pull down a single code base and start working. Ramp up time may be less, and creating test environments is as simple as providing a new copy. The monolith may be designed to include multiple components and applications.
 
-Unfortunately, the monolith pattern tends to breakdown at scale. Major disadvantages of the monolith approach include:
+Unfortunately, the monolith pattern tends to break down at scale. Major disadvantages of the monolith approach include:
 
 * Difficult to work in parallel in the same code base
 * Any change, no matter how trivial, requires deploying a new version of the entire application

docs/standard/serverless-architecture/architecture-deployment-approaches.md

@@ -52,7 +52,7 @@ Virtualization of hardware, via "virtual machines" enables Infrastructure-as-a-S
 
 For more information, see: [virtual machine N-tier reference architecture](/azure/architecture/reference-architectures/virtual-machines-windows/n-tier).
 
-Although virtualization and Infrastructure-as-a-Service (IaaS) address many concerns, it still leaves much responsibility in the hands of the infrastructure team. The team maintains operating system versions, applies security patches, and installs third-party dependencies on the target machines. Apps often behave differently on production machines compared to the test environment. Issues arise due to different dependency versions and/or OS SKU levels. Although to deploy N-Tier applications to these targets, many companies benefit from deploying to a more cloud native model such as Platform-as-a-Service (covered in the next section). Architectures with microservices are more challenging due to the requirements to scale out for elasticity and resiliency.
+Although virtualization and Infrastructure-as-a-Service (IaaS) address many concerns, it still leaves much responsibility in the hands of the infrastructure team. The team maintains operating system versions, applies security patches, and installs third-party dependencies on the target machines. Apps often behave differently on production machines compared to the test environment. Issues arise due to different dependency versions and/or OS SKU levels. Although many organizations deploy N-Tier applications to these targets, many companies benefit from deploying to a more cloud native model such as Platform-as-a-Service (covered in the next section). Architectures with microservices are more challenging due to the requirements to scale out for elasticity and resiliency.
 
 For more information, see: [virtual machines](/azure/virtual-machines/).
 

docs/standard/serverless-architecture/azure-functions.md

@@ -21,7 +21,7 @@ There are two versions of the Azure Functions runtime: 1.x and 2.x. Version 1.x
 
 Version 2.x is in preview. It leverages .NET Core and supports cross-platform development on Windows, macOS, and Linux machines. 2.x adds first-class support for Java but does not yet directly support any of the experimental languages. Version 2.x uses a new binding extensibility model that enables third-party extensions to the platform, independent versioning of bindings, and a more streamlined execution environment.
 
-> **There is a known issue in 1.x with [binding redirect support](https://github.com/Azure/azure-functions-host/issues/992).** The issue is specific to .NET development. Projects with dependencies on libraries that are a different version from the libraries included in the runtime are impacted. The functions team has committed to make concrete progress on the problem. The team will address binding redirects in 2.x before it goes into general availability. The official team statement with suggested fixes and workarounds is available here: [Assembly resolution in Azure Functions](https://github.com/Azure/azure-functions-host/wiki/Assembly-Resolution-in-Azure-Functions).
+> **There is a known issue in 1.x with [binding redirect support](https://github.com/Azure/azure-functions-host/issues/992).** The issue is specific to .NET development. Projects with dependencies on libraries that are a different version from the libraries included in the runtime are impacted. The functions team has committed to making concrete progress on the problem. The team will address binding redirects in 2.x before it goes into general availability. The official team statement with suggested fixes and workarounds is available here: [Assembly resolution in Azure Functions](https://github.com/Azure/azure-functions-host/wiki/Assembly-Resolution-in-Azure-Functions).
 
 For more information, see: [Compare 1.x and 2.x](/azure/azure-functions/functions-versions).
 
@@ -169,7 +169,7 @@ The `Domain Redirect` proxy takes a shortened route and maps it to the longer fu
 
 The `Root` proxy takes anything sent to the root URL (`https://--shorturl--/`) and redirects it to the documentation site.
 
-An example of using proxies is shown in the video [Azure: Bring your app to the cloud with serverless Azure Functions](https://channel9.msdn.com/events/Connect/2017/E102). In real time, an ASP. NET Core application running on local SQL Server is migrated to the Azure Cloud. Proxies are used to help refactor a traditional Web API project to use functions.
+An example of using proxies is shown in the video [Azure: Bring your app to the cloud with serverless Azure Functions](https://channel9.msdn.com/events/Connect/2017/E102). In real time, an ASP.NET Core application running on local SQL Server is migrated to the Azure Cloud. Proxies are used to help refactor a traditional Web API project to use functions.
 
 For more information about Proxies, see: [Work with Azure Functions Proxies](/azure/azure-functions/functions-proxies).
 

docs/standard/serverless-architecture/azure-serverless-platform.md

@@ -13,7 +13,7 @@ You can also use Application Insights, a serverless platform for capturing diagn
 
 ![Azure serverless platform](./media/azure-serverless-platform.png)
 
-The chapter breaks down the fundamentals of each component.
+This chapter breaks down the fundamentals of each component.
 
 >[!div class="step-by-step"]
 [Previous] (./serverless-design-examples.md)

docs/standard/serverless-architecture/durable-azure-functions.md

@@ -7,21 +7,21 @@ ms.date: 05/24/2017
 ---
 # Durable Azure functions
 
-When creating serverless applications with Azure Functions, your operations will typically be designed to run in a stateless manner. The reason for this design choice is because as the platform scales, it becomes difficult to know what servers the code is running on. It also becomes difficult to know how many instances are active at any given point. However, there are classes of applications that require the current state of a process to be known. Take into consideration the process of submitting an order via an online store. The checkout operation might be a workflow that is composed of multiple operations that need to know the state of the process. Such information may include the product inventory, if the customer has any credits on their account, and also the results of processing the credit card. These mentioned operations could easily be their own internal workflows or even services from third-party systems.
+When creating serverless applications with Azure Functions, your operations will typically be designed to run in a stateless manner. The reason for this design choice is because as the platform scales, it becomes difficult to know what servers the code is running on. It also becomes difficult to know how many instances are active at any given point. However, there are classes of applications that require the current state of a process to be known. Consider the process of submitting an order to an online store. The checkout operation might be a workflow that is composed of multiple operations that need to know the state of the process. Such information may include the product inventory, if the customer has any credits on their account, and also the results of processing the credit card. These operations could easily be their own internal workflows or even services from third-party systems.
 
-Various patterns exist today that assists with the coordination of application state between internal and external systems. It is common to come across solutions that rely on centralized queuing systems, distributed key-value stores, or shared databases to manage that state. However, these are all additional resources that now need to be provisioned and managed. In a serverless environment, your code could become cumbersome trying to coordinate with these resources manually. Azure Functions offers an alternative for creating stateful functions called Durable Functions.
+Various patterns exist today that assist with the coordination of application state between internal and external systems. It is common to come across solutions that rely on centralized queuing systems, distributed key-value stores, or shared databases to manage that state. However, these are all additional resources that now need to be provisioned and managed. In a serverless environment, your code could become cumbersome trying to coordinate with these resources manually. Azure Functions offers an alternative for creating stateful functions called Durable Functions.
 
-Durable Functions is an extension to the Azure Functions runtime that enables the definition of stateful workflows in code. By breaking down workflows into activities, the Durable Functions extension is able to manage state, create progress checkpoints, and handle the distribution of function calls across servers. In the background, it makes use of an Azure Storage account to persist execution history, schedule activity functions and retrieve responses. Your serverless code should never interact with persisted information in that storage account, and is typically not something developers need to interact with.
+Durable Functions is an extension to the Azure Functions runtime that enables the definition of stateful workflows in code. By breaking down workflows into activities, the Durable Functions extension is able to manage state, create progress checkpoints, and handle the distribution of function calls across servers. In the background, it makes use of an Azure Storage account to persist execution history, schedule activity functions and retrieve responses. Your serverless code should never interact with persisted information in that storage account, and is typically not something with which developers need to interact.
 
 ## Triggering a stateful workflow
 
-Stateful workflows in Durable Functions can be broken down into two intrinsic components; orchestration and activity triggers. Triggers and bindings are core components used by Azure Functions to enable your serverless functions to notified when to start, receive input and return results.
+Stateful workflows in Durable Functions can be broken down into two intrinsic components; orchestration and activity triggers. Triggers and bindings are core components used by Azure Functions to enable your serverless functions to be notified when to start, receive input, and return results.
 
 ### Working with the Orchestration client
 
 Orchestrations are unique when compared to other styles of triggered operations in Azure Functions. Durable Functions enables the execution of functions that may take hours or even days to complete. That type of behavior comes with the need to able to check the status of a running orchestration, preemptively terminate, or send notifications of external events.
 
-For such cases, the Durable Functions extension provides the DurableOrchestrationClient class that allows you to interact with orchestrated functions. You get access to the orchestration client by using the OrchestrationClientAttribute binding. Generally, you would include this attribute with another trigger type, such as a HttpTrigger or ServiceBusTrigger. Once the source function gets trigger, the orchestration client can be used to start an orchestrator function.
+For such cases, the Durable Functions extension provides the DurableOrchestrationClient class that allows you to interact with orchestrated functions. You get access to the orchestration client by using the OrchestrationClientAttribute binding. Generally, you would include this attribute with another trigger type, such as an HttpTrigger or ServiceBusTrigger. Once the source function has been triggered, the orchestration client can be used to start an orchestrator function.
 
 ```csharp
 [FunctionName("KickOff")]
@@ -71,7 +71,7 @@ The completed Task\<string\> from StartNewAsync should contain the unique ID of
 
 Activity functions are the discrete operations that get composed together within an orchestration function to create the workflow. Here is where most of actual work would take place. They represent the business logic, long running processes, and the puzzle pieces to a larger solution.
 
-The ActivityTriggerAttribute is used to annotate a function parameter of type DurableActivityContext. Using the annotation let's the runtime know that the function is intended to be used as an activity function. Input values to activity functions have been retrieved by using the GetInput\<T\> method of the DurableActivityContext parameter.
+The ActivityTriggerAttribute is used to annotate a function parameter of type DurableActivityContext. Using the annotation informs the runtime that the function is intended to be used as an activity function. Input values to activity functions are retrieved using the GetInput\<T\> method of the DurableActivityContext parameter.
 
 Similar to orchestration functions, the return types of activity functions must be either void, Task, or a JSON serializable value.
 

docs/standard/serverless-architecture/event-grid.md

@@ -51,7 +51,7 @@ For a more in-depth comparison, see: [Compare messaging services](/azure/event-g
 
 Using Event Grid you can take advantage of the following performance guarantees:
 
-* Sub second end-to-end latency in the 99th percentile
+* Sub-second end-to-end latency in the 99th percentile
 * 99.99% availability
 * 10 million events per second per region
 * 100 million subscriptions per region

docs/standard/serverless-architecture/index.md

@@ -10,7 +10,7 @@ ms.date: 5/24/2018
 
 # Serverless Apps. Architecture, Patterns, and Azure Implementation
 
-DOWNLOAD available at: **TBD**
+> DOWNLOAD available at: **TBD**
 
 PUBLISHED BY
 
@@ -50,14 +50,16 @@ Editors:
 
 Participants and reviewers:
 
+> **[Steve Smith](https://twitter.com/ardalis)**, Owner, Ardalis Services.
+
 ## Introduction
 
 Serverless is the evolution of cloud platforms in the direction of pure cloud native code. Serverless brings developers closer to business logic while insulating them from infrastructure concerns. It's a pattern that doesn't imply "no server" but rather, "less server." Serverless code is event-driven. Code may be triggered by anything from a traditional HTTP web request to a timer or the result of uploading a file. The infrastructure behind serverless allows for instant scale to meet elastic demands and offers micro-billing to truly "pay for what you use." Serverless requires a new way of thinking and approach to building applications and is not the right solution for every problem. As a developer, you must decide:
 
 * What are the pros and cons of serverless?
 * Why should you consider serverless for your own applications?
 * How can you build, test, deploy, and maintain your serverless code?
-* Where does it make sense to migrate code to serverless in existing applications, and what is the best way to accomplish transformation?
+* Where does it make sense to migrate code to serverless in existing applications, and what is the best way to accomplish this transformation?
 
 ## About this guide
 
@@ -67,14 +69,14 @@ This guide explains the components of the Azure serverless platform and focuses
 
 ## Evolution of cloud platforms
 
-Serverless is the culmination of several iterations of cloud platforms. The evolution began with physical metal in the data center progressed through Infrastructure-as-a-Service (IaaS) and Platform-as-a-Service (PaaS).
+Serverless is the culmination of several iterations of cloud platforms. The evolution began with physical metal in the data center and progressed through Infrastructure-as-a-Service (IaaS) and Platform-as-a-Service (PaaS).
 
 ![Evolution from on-premises to serverless](./media/serverless-evolution-iaas-paas.png)
 
-Before the cloud, a discernable boundary existed between development and operations. Deploying an application meant answering myriad questions like:
+Before the cloud, a discernible boundary existed between development and operations. Deploying an application meant answering myriad questions like:
 
 * What hardware should be installed?
-* How is physical access secured to the machine?
+* How is physical access to the machine secured?
 * Does the data center require an Uninterruptible Power Supply (UPS)?
 * Where are storage backups sent?
 * Should there be redundant power?
@@ -118,7 +120,7 @@ This guide was written for developers and solution architects who want to build
 
 * Understanding the pros and cons of serverless development
 * Learning how to approach serverless architecture
-* Interested in example implementations of serverless apps
+* Example implementations of serverless apps
 
 ## How to use the guide
 
@@ -128,7 +130,7 @@ The first part of this guide examines why serverless is a viable option by compa
 
 The guide and related samples are constantly evolving, so your feedback is welcomed! If you have comments about how this guide can be improved, send them to:
 
-[link tbd](mailto:)
+[link tbd](mailto:) **Note: Should this link be to create an issue on GitHub?**
 
 >[!div class="step-by-step"]
 [Next] (architecture-approaches.md)

docs/standard/serverless-architecture/logic-apps.md

@@ -23,7 +23,7 @@ Once the app is triggered, you can use the visual designer to build out steps, l
 
 ![Logic App workflow](./media/logic-app-workflow.png)
 
-The Logic Apps dashboard shows the history of running your workflows and whether or not each run completed successfully or not. You can navigate into any given run and inspect the data used by each step for troubleshooting. Logic Apps also provides existing templates you can edit and are suited for complex enterprise workflows.
+The Logic Apps dashboard shows the history of running your workflows and whether or not each run completed successfully or not. You can navigate into any given run and inspect the data used by each step for troubleshooting. Logic Apps also provides existing templates you can edit and are well suited for complex enterprise workflows.
 
 To learn more, see: [Azure Logic Apps](/azure/logic-apps).