Serverless ebook (#6260)

* Adding eBook to refactored docs

* Update to master TOC

* Fix links, begin app insights

* Write app insights, logic apps articles

* Event Grid article

* durable functions articles

* Start business cases chapter

* Finish business scenarios chapter

* Addressing @BillWagner review.

* Updates per @mairaw feedback

* Formatting updates

* update toc

* addressing review feedback

* Key takeaways.

* Refactor for SEO, run Gauntlet verification, run and respond to Acrolinx

* Fixes based on publishing build

* Review complete with small revisions. (#6044)

* Updates from requests in pull request 6044 (#6127)

* Update dates, links, and cover (#6194)

* last edit pass

* typo

Per offline convo with @JeremyLikness

Author: BillWagner

docfx.json

@@ -186,6 +186,7 @@
         "docs/standard/microservices-architecture/**/**.md": "dotnet-ebooks",
         "docs/standard/modern-web-apps-azure-architecture/**/**.md": "dotnet-ebooks",
         "docs/standard/modernize-with-azure-and-containers/**/**.md": "dotnet-ebooks",
+        "docs/standard/serverless-architecture/**/**.md": "dotnet-ebooks",
         "docs/standard/security/**/**.md": "dotnet-security",
         "docs/visual-basic/language-reference/error-messages/**/**.md": "vb-diagnostics"
       }

docs/standard/guidance-architecture.md

@@ -22,4 +22,8 @@ This guide is an introduction to the recommended architecture, design, and deplo
 
 ## [Architecting Container and Microservice Based Applications](microservices-architecture/index.md)
 
-This guide is an introduction to developing microservices-based applications and managing them using containers. It discusses architectural design and implementation approaches using .NET Core and Docker containers. 
+This guide is an introduction to developing microservices-based applications and managing them using containers. It discusses architectural design and implementation approaches using .NET Core and Docker containers.
+
+## [Serverless apps: Architecture, patterns, and Azure implementation](serverless-architecture/index.md)
+
+This is a guide for building serverless applications with examples using Azure. It discusses various architecture and design approaches, the benefits and challenges that come with serverless, and provides scenarios and use cases for serverless apps.

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

@@ -0,0 +1,56 @@
+---
+title: Application Insights - Serverless apps
+description: 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.
+author: JEREMYLIKNESS
+ms.author: jeliknes
+ms.date: 06/26/2018
+---
+# Telemetry with Application Insights
+
+[Application Insights](https://docs.microsoft.com/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)
+
+Adding Application Insights to existing apps is as easy as adding an instrumentation key to your application's settings. With Application Insights you can:
+
+* Create custom charts and alerts based on metrics such as number of function invocations, the time it takes to run a function, and exceptions
+* Analyze failures and server exceptions
+* Drill into performance by operation and measure the time it takes to call third-party dependencies
+* Monitor CPU usage, memory, and rates across all servers that host your function apps
+* View a live stream of metrics including request count and latency for your function apps
+* Use [Analytics](https://docs.microsoft.com/azure/application-insights/app-insights-analytics) to search, query, and create custom charts over your function data
+
+![Metrics explorer](./media/metrics-explorer.png)
+
+In addition to built-in telemetry, it's also possible to generate custom telemetry. The following code snippet creates a custom telemetry client using the instrumentation key set for the function app:
+
+```csharp
+public static TelemetryClient telemetry = new TelemetryClient()
+{
+    InstrumentationKey = Environment.GetEnvironmentVariable("APPINSIGHTS_INSTRUMENTATIONKEY")
+};
+```
+
+The following code measures how long it takes to insert a new row into an [Azure Table Storage](https://docs.microsoft.com/azure/cosmos-db/table-storage-overview) instance:
+
+```csharp
+var operation = TableOperation.Insert(entry);
+var startTime = DateTime.UtcNow;
+var timer = System.Diagnostics.Stopwatch.StartNew();
+await table.ExecuteAsync(operation);
+telemetry.TrackDependency("AzureTableStorageInsert", "Insert", startTime, timer.Elapsed, true);
+```
+
+The resulting performance graph is shown:
+
+![Custom telemetry](./media/custom-telemetry.png)
+
+The custom telemetry reveals the average time to insert a new row is 32.6 milliseconds.
+
+Application Insights provides a powerful, convenient way to log detailed telemetry about your serverless applications. You have full control over the level of tracing and logging that is provided. You can track custom statistics such as events, dependencies, and page view. Finally, the powerful analytics enable you to write queries that ask important questions and generate charts and advanced insights.
+
+For more information, see [Monitor Azure Functions](https://docs.microsoft.com/azure/azure-functions/functions-monitoring).
+
+>[!div class="step-by-step"]
+[Previous](azure-functions.md)
+[Next](logic-apps.md)

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

@@ -0,0 +1,95 @@
+---
+title: Architecture approaches - Serverless apps
+description: An introduction to architecture approaches for building cloud-based enterprise applications, from N-tier architectures to serverless.
+author: JEREMYLIKNESS
+ms.author: jeliknes
+ms.date: 06/26/2018
+---
+# Architecture approaches
+
+Understanding existing approaches to architecting enterprise apps helps clarify the role played by serverless. There are many approaches and patterns that evolved over decades of software development, and all have their own pros and cons. In many cases, the ultimate solution may not involve deciding on a single approach but may integrate several approaches. Migration scenarios often involve shifting from one architecture approach to another through a hybrid approach.
+
+This chapter provides an overview of both logical and physical architecture patterns for enterprise applications.
+
+## Architecture patterns
+
+Modern business applications follow a variety of architecture patterns. This section represents a survey of common patterns. The patterns listed here aren't necessarily all best practices, but illustrate different approaches.
+
+For more information, see [Azure application architecture guide](https://docs.microsoft.com/azure/architecture/guide/).
+
+## Monoliths
+
+Many business applications follow a monolith pattern. Legacy applications are often implemented as monoliths. In the monolith pattern, all application concerns are contained in a single deployment. Everything from user interface to database calls is included in the same codebase.
+
+![Monolith architecture](./media/monolith-architecture.png)
+
+There are several advantages to the monolith approach. It's 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 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.
+* Refactoring potentially impacts the entire application.
+* Often the only solution to scale is to create multiple, resource-intensive copies of the monolith.
+* As systems expand or other systems are acquired, integration can be difficult.
+* It may be difficult to test due to the need to configure the entire monolith.
+* Code reuse is challenging and often other apps end up having their own copies of code.
+
+Many businesses look to the cloud as an opportunity to migrate monolith applications and at the same time refactor them to more usable patterns. It's common to break out the individual applications and components to allow them to be maintained, deployed, and scaled separately.
+
+## N-Layer applications
+
+N-layer application partition application logic into specific layers. The most common layers include:
+
+* User interface
+* Business logic
+* Data access
+
+Other layers may include middleware, batch processing, and API. It's important to note the layers are logical. Although they're developed in isolation, they may all be deployed to the same target platform.
+
+![N-Layer architecture](./media/n-layer-architecture.png)
+
+There are several advantages to the N-Layer approach, including:
+
+* Refactoring is isolated to a layer.
+* Teams can independently build, test, deploy, and maintain separate layers.
+* Layers can be swapped out, for example the data layer may access multiple databases without requiring changes to the UI layer.
+
+Serverless may be used to implement one or more layers.
+
+## Microservices
+
+**[Microservices](https://docs.microsoft.com/azure/architecture/guide/architecture-styles/microservices)** architectures contain common characteristics that include:
+
+* Applications are composed of several small services.
+* Each service runs in its own process.
+* Services are aligned around business domains.
+* Services communicate over lightweight APIs, typically using HTTP as the transport.
+* Services can be deployed and upgraded independently.
+* Services aren't dependent on a single data store.
+* The system is designed with failure in mind, and the app may still run even when certain services fail.
+
+Microservices don't have to be mutual to other architecture approaches. For example, an N-Tier architecture may use microservices for the middle tier. It's also possible to implement microservices in a variety of ways, from virtual directories on IIS hosts to containers. The characteristics of microservices make them especially ideal for serverless implementations.
+
+![Microservices architecture](./media/microservices-architecture.png)
+
+The pros of microservices architectures include:
+
+* Refactoring is often isolated to a single service.
+* Services can be upgraded independently of each other.
+* Resiliency and elasticity can be tuned to the demands of individual services.
+* Development can happen in parallel across disparate teams and platforms.
+* It's easier to write comprehensive tests for isolated services.
+
+Microservices come with their own challenges, including:
+
+* Determining what services are available and how to call them.
+* Managing the lifecycle of services.
+* Understanding how services fit together in the overall application.
+* Full system testing of calls made across disparate services.
+
+Ultimately there are solutions to address all of these challenges, including tapping into the benefits of serverless that are discussed later.
+
+>[!div class="step-by-step"]
+[Previous](index.md)
+[Next](architecture-deployment-approaches.md)