Merge master into live

.github/ISSUE_TEMPLATE/dotnet-breaking-change.md

@@ -44,11 +44,12 @@ Also, remove this comment before submitting the issue.
 - C#
 - Core
 - Core .NET libraries
+- Cryptography
 - Data
 - Debugger
 - Deployment for .NET Core
 - Globalization
-- interop
+- Interop
 - JIT
 - LINQ
 - Managed Extensibility Framework (MEF)

docs/architecture/serverless/azure-functions.md

@@ -3,51 +3,40 @@ title: Azure Functions - Serverless apps
 description: Azure functions provide serverless capabilities across multiple languages (C#, JavaScript, Java) and platforms to provide event-driven instant scale code.
 author: JEREMYLIKNESS
 ms.author: jeliknes
-ms.date: 06/26/2018
+ms.date: 04/06/2020
 ---
 # Azure Functions
 
 Azure functions provide a serverless compute experience. A function is invoked by a *trigger* (such as access to an HTTP endpoint or a timer) and executes a block of code or business logic. Functions also support specialized *bindings* that connect to resources like storage and queues.
 
 ![Azure functions logo](./media/azure-functions-logo.png)
 
-There are two versions of the Azure Functions framework. The legacy version supports the full .NET Framework and the new runtime supports cross-platform .NET Core applications. Additional languages besides C# such as JavaScript, F#, and Java are supported. Functions created in the portal provide a rich scripting syntax. Functions created as standalone projects can be deployed with full platform support and capabilities.
+The current runtime version 3.0 supports cross-platform .NET Core 3.1 applications. Additional languages besides C# such as JavaScript, F#, and Java are supported. Functions created in the portal provide a rich scripting syntax. Functions created as standalone projects can be deployed with full platform support and capabilities.
 
 For more information, see [Azure Functions documentation](https://docs.microsoft.com/azure/azure-functions).
 
-## Functions v1 vs. v2
-
-There are two versions of the Azure Functions runtime: 1.x and 2.x. Version 1.x is generally available (GA). It supports .NET development from the portal or Windows machines and uses the .NET Framework. 1.x supports C#, JavaScript, and F#, with experimental support for Python, PHP, TypeScript, Batch, Bash, and PowerShell.
-
-[Version 2.x is also generally available now](https://azure.microsoft.com/blog/introducing-azure-functions-2-0/). It leverages .NET Core and supports cross-platform development on Windows, macOS, and Linux machines. 2.x adds first-class support for Java but doesn't 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 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](https://docs.microsoft.com/azure/azure-functions/functions-versions).
-
 ## Programming language support
 
-The following languages are supported either in general availability (GA), preview, or experimental.
-
-|Language      |1.x         |2.x      |
-|--------------|------------|---------|
-|**C#**        |GA          |Preview  |
-|**JavaScript**|GA          |Preview  |
-|**F#**        |GA          |         |
-|**Java**      |            |Preview  |
-|**Python**    |Experimental|         |
-|**PHP**       |Experimental|         |
-|**TypeScript**|Experimental|         |
-|**Batch**     |Experimental|         |
-|**Bash**      |Experimental|         |
-|**PowerShell**|Experimental|         |
+The following languages are all supported in general availability (GA).
+
+|Language      |Supported runtimes|
+|--------------|------------------|
+|**C#**        |.NET Core 3.1     |
+|**JavaScript**|Node 10 & 12      |
+|**F#**        |.NET Core 3.1     |
+|**Java**      |Java 8            |
+|**Python**    |Python 3.6, 3.7, & 3.8|
+|**TypeScript**|Node 10 & 12 (via JavaScript)|
+|**PowerShell**|PowerShell Core 6|
 
 For more information, see [Supported languages](https://docs.microsoft.com/azure/azure-functions/supported-languages).
 
 ## App service plans
 
 Functions are backed by an *app service plan*. The plan defines the resources used by the functions app. You can assign plans to a region, determine the size and number of virtual machines that will be used, and pick a pricing tier. For a true serverless approach, function apps may use the **consumption** plan. The consumption plan will scale the back end automatically based on load.
 
+Another hosting option for function apps is the [Premium plan](https://docs.microsoft.com/azure/azure-functions/functions-premium-plan). This plan provides an "always on" instance to avoid cold start, supports advanced features like VNet connectivity, and runs on premium hardware.
+
 For more information, see [App service plans](https://docs.microsoft.com/azure/app-service/azure-web-sites-web-hosting-plans-in-depth-overview).
 
 ## Create your first function
@@ -121,58 +110,6 @@ The example is a simple function that takes the name of the file that was modifi
 
 For a full list of triggers and bindings, see [Azure Functions triggers and bindings concepts](https://docs.microsoft.com/azure/azure-functions/functions-triggers-bindings).
 
-## Proxies
-
-Proxies provide redirect functionality for your application. Proxies expose an endpoint and map that endpoint to another resource. With proxies, you can:
-
-- Reroute an incoming request to another endpoint.
-- Modify the incoming request before it's passed along.
-- Modify or provide a response.
-
-Proxies are used for scenarios such as:
-
-- Simplifying, shortening, or changing the URL.
-- Providing a consistent API prefix to multiple back-end services.
-- Mocking a response to an endpoint being developed.
-- Providing a static response to a well-known endpoint.
-- Keeping an API endpoint consistent while the back end is moved or migrated.
-
-Proxies are stored as JSON definitions. Here is an example:
-
-```json
-{
-  "$schema": "http://json.schemastore.org/proxies",
-  "proxies": {
-    "Domain Redirect": {
-      "matchCondition": {
-        "route": "/{shortUrl}"
-      },
-      "backendUri": "http://%WEBSITE_HOSTNAME%/api/UrlRedirect/{shortUrl}"
-    },
-    "Root": {
-      "matchCondition": {
-        "route": "/"
-      },
-      "responseOverrides": {
-        "response.statusCode": "301",
-        "response.statusReason": "Moved Permanently",
-        "response.headers.location": "https://docs.microsoft.com/"
-      }
-    }
-  }
-}
-```
-
-The `Domain Redirect` proxy takes a shortened route and maps it to the longer function resource. The transformation looks like:
-
-`https://--shorturl--/123` -> `https://--longurl--.azurewebsites.net/api/UrlRedirect/123`
-
-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.
-
-For more information about Proxies, see [Work with Azure Functions Proxies](https://docs.microsoft.com/azure/azure-functions/functions-proxies).
-
 >[!div class="step-by-step"]
 >[Previous](azure-serverless-platform.md)
 >[Next](application-insights.md)

docs/architecture/serverless/event-grid.md

@@ -3,7 +3,7 @@ title: Azure Event Grid - Serverless apps
 description: Azure Event Grid is a serverless solution for reliable event delivery and routing at massive scale on a pay-per-event model.
 author: JEREMYLIKNESS
 ms.author: jeliknes
-ms.date: 06/26/2018
+ms.date: 04/06/2020
 ---
 # Event Grid
 
@@ -126,14 +126,12 @@ In this chapter you learned about the Azure serverless platform that is composed
 - [Azure Logic Apps](https://docs.microsoft.com/azure/logic-apps)
 - [Azure Service Bus](https://docs.microsoft.com/azure/service-bus-messaging)
 - [Azure Table Storage](https://docs.microsoft.com/azure/cosmos-db/table-storage-overview)
-- [Compare functions 1.x and 2.x](https://docs.microsoft.com/azure/azure-functions/functions-versions)
 - [Connecting to on-premises data sources with Azure On-premises Data Gateway](https://docs.microsoft.com/azure/analysis-services/analysis-services-gateway)
 - [Create your first function in the Azure portal](https://docs.microsoft.com/azure/azure-functions/functions-create-first-azure-function)
 - [Create your first function using the Azure CLI](https://docs.microsoft.com/azure/azure-functions/functions-create-first-azure-function-azure-cli)
 - [Create your first function using Visual Studio](https://docs.microsoft.com/azure/azure-functions/functions-create-your-first-function-visual-studio)
 - [Functions supported languages](https://docs.microsoft.com/azure/azure-functions/supported-languages)
 - [Monitor Azure Functions](https://docs.microsoft.com/azure/azure-functions/functions-monitoring)
-- [Work with Azure Functions Proxies](https://docs.microsoft.com/azure/azure-functions/functions-proxies)
 
 >[!div class="step-by-step"]
 >[Previous](logic-apps.md)

docs/architecture/serverless/index.md

@@ -3,14 +3,16 @@ title: "Serverless apps: Architecture, patterns, and Azure implementation"
 description: Guide to serverless architecture. Learn when, why, and how to implement a serverless architecture (as opposed to Infrastructure as a Service [IaaS] or Platform as a Service [PaaS]) for your enterprise applications.
 author: JEREMYLIKNESS
 ms.author: jeliknes
-ms.date: 06/26/2018
+ms.date: 04/22/2020
 ---
 
 # Serverless apps: Architecture, patterns, and Azure implementation
 
-![Screenshot that shows the Serverless Apps e-book cover.](./media/index/serverless-apps-cover.jpg)
+![Screenshot that shows the Serverless Apps e-book cover.](./media/index/serverless-apps-cover-v3.png)
 
-> DOWNLOAD available at: <https://aka.ms/serverless-ebook>
+**EDITION v3.0** - Updated to Azure Functions v3
+
+> DOWNLOAD available at: <https://aka.ms/serverlessbookpdf>
 
 PUBLISHED BY
 
@@ -22,7 +24,7 @@ One Microsoft Way
 
 Redmond, Washington 98052-6399
 
-Copyright © 2018 by Microsoft Corporation
+Copyright &copy; 2018-2020 by Microsoft Corporation
 
 All rights reserved. No part of the contents of this book may be reproduced or transmitted in any form or by any means without the written permission of the publisher.
 
@@ -38,7 +40,7 @@ All other marks and logos are property of their respective owners.
 
 Author:
 
-> **[Jeremy Likness](https://twitter.com/jeremylikness)**, Senior Cloud Advocate, Microsoft Corp.
+> **[Jeremy Likness](https://twitter.com/jeremylikness)**, Senior .NET Data Program Manager, Microsoft Corp.
 
 Contributor:
 
@@ -92,7 +94,7 @@ IaaS still requires heavy overhead because operations is still responsible for v
 - Keeping the operating system up-to-date.
 - Monitoring the application.
 
-The next evolution reduced the overhead by providing Platform as a Service (PaaS). With PaaS, the cloud provider handles operating systems, security patches, and even the required packages to support a specific platform. Instead of building a VM then configuring the .NET Framework and standing up Internet Information Services (IIS) servers, developers simply choose a "platform target" such as "web application" or "API endpoint" and deploy code directly. The infrastructure questions are reduced to:
+The next evolution reduced the overhead by providing Platform as a Service (PaaS). With PaaS, the cloud provider handles operating systems, security patches, and even the required packages to support a specific platform. Instead of building a VM then configuring .NET and standing up Internet Information Services (IIS) servers, developers simply choose a "platform target" such as "web application" or "API endpoint" and deploy code directly. The infrastructure questions are reduced to:
 
 - What size services are needed?
 - How do the services scale out (add more servers or nodes)?

docs/architecture/serverless/serverless-architecture-considerations.md

@@ -3,7 +3,7 @@ title: Serverless architecture considerations - Serverless apps
 description: Understand the challenges of architecting serverless applications, from state management and persistent storage to scale, logging, tracing and diagnostics.
 author: JEREMYLIKNESS
 ms.author: jeliknes
-ms.date: 06/26/2018
+ms.date: 04/06/2020
 ---
 # Serverless architecture considerations
 
@@ -17,7 +17,7 @@ There are several solutions to adopt state without compromising the benefits of
 
 - Use a temporary data store or distributed cache, like Redis
 - Store state in a database, like SQL or CosmosDB
-- Handle state through a workflow engine like durable functions
+- Handle state through a workflow engine like [durable functions](https://docs.microsoft.com/azure/azure-functions/durable/durable-functions-overview)
 
 The bottom line is that you should be aware of the need for any state management within processes you're considering to implement with serverless.
 
@@ -73,7 +73,7 @@ For more information, see [Implementing the Circuit Breaker pattern](../microser
 
 ## Versioning and green/blue deployments
 
-A major benefit of serverless is the ability to upgrade a specific function without having to redeploy the entire application. For upgrades to be successful, functions must be versioned so that services calling them are routed to the correct version of code. A strategy for deploying new versions is also important. A common approach is to use "green/blue deployments." The green deployment is the current function. A new "blue" version is deployed to production and tested. When testing passes, the green and blue versions are swapped so the new version comes live. If any issues are encountered, they can be swapped back. Supporting versioning and green/blue deployments requires a combination of authoring the functions to accommodate version changes and working with the serverless platform to handle deployments. One possible approach is to use proxies, which are described in the [Azure serverless platform](azure-functions.md#proxies) chapter.
+A major benefit of serverless is the ability to upgrade a specific function without having to redeploy the entire application. For upgrades to be successful, functions must be versioned so that services calling them are routed to the correct version of code. A strategy for deploying new versions is also important. A common approach is to use "green/blue deployments." The green deployment is the current function. A new "blue" version is deployed to production and tested. When testing passes, the green and blue versions are swapped so the new version comes live. If any issues are encountered, they can be swapped back. Supporting versioning and green/blue deployments requires a combination of authoring the functions to accommodate version changes and working with the serverless platform to handle deployments.
 
 >[!div class="step-by-step"]
 >[Previous](serverless-architecture.md)