You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
description: Azure functions provide serverless capabilities across multiple languages (C#, JavaScript, Java) and platforms to provide event-driven instant scale code.
4
4
author: JEREMYLIKNESS
5
5
ms.author: jeliknes
6
-
ms.date: 06/26/2018
6
+
ms.date: 04/06/2020
7
7
---
8
8
# Azure Functions
9
9
10
10
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.
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.
14
+
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.
15
15
16
16
For more information, see [Azure Functions documentation](https://docs.microsoft.com/azure/azure-functions).
17
17
18
-
## Functions v1 vs. v2
19
-
20
-
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.
21
-
22
-
[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.
23
-
24
-
> **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).
25
-
26
-
For more information, see [Compare 1.x and 2.x](https://docs.microsoft.com/azure/azure-functions/functions-versions).
27
-
28
18
## Programming language support
29
19
30
-
The following languages are supported either in general availability (GA), preview, or experimental.
31
-
32
-
|Language |1.x |2.x |
33
-
|--------------|------------|---------|
34
-
|**C#**|GA |Preview |
35
-
|**JavaScript**|GA |Preview |
36
-
|**F#**|GA ||
37
-
|**Java**||Preview |
38
-
|**Python**|Experimental||
39
-
|**PHP**|Experimental||
40
-
|**TypeScript**|Experimental||
41
-
|**Batch**|Experimental||
42
-
|**Bash**|Experimental||
43
-
|**PowerShell**|Experimental||
20
+
The following languages are all supported in general availability (GA).
21
+
22
+
|Language |Supported runtimes|
23
+
|--------------|------------------|
24
+
|**C#**|.NET Core 3.1 |
25
+
|**JavaScript**|Node 10 & 12 |
26
+
|**F#**|.NET Core 3.1 |
27
+
|**Java**|Java 8 |
28
+
|**Python**|Python 3.6, 3.7, & 3.8|
29
+
|**TypeScript**|Node 10 & 12 (via JavaScript)|
30
+
|**PowerShell**|PowerShell Core 6|
44
31
45
32
For more information, see [Supported languages](https://docs.microsoft.com/azure/azure-functions/supported-languages).
46
33
47
34
## App service plans
48
35
49
36
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.
50
37
38
+
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.
39
+
51
40
For more information, see [App service plans](https://docs.microsoft.com/azure/app-service/azure-web-sites-web-hosting-plans-in-depth-overview).
52
41
53
42
## Create your first function
@@ -121,58 +110,6 @@ The example is a simple function that takes the name of the file that was modifi
121
110
122
111
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).
123
112
124
-
## Proxies
125
-
126
-
Proxies provide redirect functionality for your application. Proxies expose an endpoint and map that endpoint to another resource. With proxies, you can:
127
-
128
-
- Reroute an incoming request to another endpoint.
129
-
- Modify the incoming request before it's passed along.
130
-
- Modify or provide a response.
131
-
132
-
Proxies are used for scenarios such as:
133
-
134
-
- Simplifying, shortening, or changing the URL.
135
-
- Providing a consistent API prefix to multiple back-end services.
136
-
- Mocking a response to an endpoint being developed.
137
-
- Providing a static response to a well-known endpoint.
138
-
- Keeping an API endpoint consistent while the back end is moved or migrated.
139
-
140
-
Proxies are stored as JSON definitions. Here is an example:
The `Root` proxy takes anything sent to the root URL (`https://--shorturl--/`) and redirects it to the documentation site.
171
-
172
-
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.
173
-
174
-
For more information about Proxies, see [Work with Azure Functions Proxies](https://docs.microsoft.com/azure/azure-functions/functions-proxies).
-[Compare functions 1.x and 2.x](https://docs.microsoft.com/azure/azure-functions/functions-versions)
130
129
-[Connecting to on-premises data sources with Azure On-premises Data Gateway](https://docs.microsoft.com/azure/analysis-services/analysis-services-gateway)
131
130
-[Create your first function in the Azure portal](https://docs.microsoft.com/azure/azure-functions/functions-create-first-azure-function)
132
131
-[Create your first function using the Azure CLI](https://docs.microsoft.com/azure/azure-functions/functions-create-first-azure-function-azure-cli)
133
132
-[Create your first function using Visual Studio](https://docs.microsoft.com/azure/azure-functions/functions-create-your-first-function-visual-studio)
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.
4
4
author: JEREMYLIKNESS
5
5
ms.author: jeliknes
6
-
ms.date: 06/26/2018
6
+
ms.date: 04/22/2020
7
7
---
8
8
9
9
# Serverless apps: Architecture, patterns, and Azure implementation
10
10
11
-
11
+
12
12
13
-
> DOWNLOAD available at: <https://aka.ms/serverless-ebook>
13
+
**EDITION v3.0** - Updated to Azure Functions v3
14
+
15
+
> DOWNLOAD available at: <https://aka.ms/serverlessbookpdf>
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.
28
30
@@ -38,7 +40,7 @@ All other marks and logos are property of their respective owners.
38
40
39
41
Author:
40
42
41
-
> **[Jeremy Likness](https://twitter.com/jeremylikness)**, Senior Cloud Advocate, Microsoft Corp.
43
+
> **[Jeremy Likness](https://twitter.com/jeremylikness)**, Senior .NET Data Program Manager, Microsoft Corp.
42
44
43
45
Contributor:
44
46
@@ -92,7 +94,7 @@ IaaS still requires heavy overhead because operations is still responsible for v
92
94
- Keeping the operating system up-to-date.
93
95
- Monitoring the application.
94
96
95
-
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:
97
+
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:
96
98
97
99
- What size services are needed?
98
100
- How do the services scale out (add more servers or nodes)?
description: Understand the challenges of architecting serverless applications, from state management and persistent storage to scale, logging, tracing and diagnostics.
4
4
author: JEREMYLIKNESS
5
5
ms.author: jeliknes
6
-
ms.date: 06/26/2018
6
+
ms.date: 04/06/2020
7
7
---
8
8
# Serverless architecture considerations
9
9
@@ -17,7 +17,7 @@ There are several solutions to adopt state without compromising the benefits of
17
17
18
18
- Use a temporary data store or distributed cache, like Redis
19
19
- Store state in a database, like SQL or CosmosDB
20
-
- Handle state through a workflow engine like durable functions
20
+
- Handle state through a workflow engine like [durable functions](https://docs.microsoft.com/azure/azure-functions/durable/durable-functions-overview)
21
21
22
22
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.
23
23
@@ -73,7 +73,7 @@ For more information, see [Implementing the Circuit Breaker pattern](../microser
73
73
74
74
## Versioning and green/blue deployments
75
75
76
-
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.
76
+
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.
0 commit comments