7/3/2018 – 5 minutes to read - Edit Online
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.
For more information, see Azure Functions documentation.
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 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 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. 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.
For more information, see Compare 1.x and 2.x.
The following languages are supported either in general availability (GA), preview, or experimental.
For more information, see Supported languages.
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.
For more information, see App service plans.
There are three common ways you can create function apps.
For more information on creating a scripted function in the portal, see Create your first function in the Azure portal.
To build from the Azure CLI, see Create your first function using the Azure CLI.
To create a function from Visual Studio, see Create your first function using Visual Studio.
Functions are invoked by a trigger and can have exactly one. In addition to invoking the function, certain triggers also serve as bindings. You may also define multiple bindings in addition to the trigger. Bindings provide a declarative way to connect data to your code. They can be passed in (input) or receive data (output). Triggers and bindings make functions easy to work with. Bindings remove the overhead of manually creating database or file system connections. All of the information needed for the bindings is contained in a special functions.json file for scripts or declared with attributes in code.
Some common triggers include:
Examples of bindings include:
CosmosDB: easily connect to the database to load or save files.
Table Storage: work with key/value storage from your function app.
Queue Storage: easily retrieve items from a queue, or place new items on the queue.
The following example functions.json file defines a trigger and a binding:
In this example, the function is triggered by a change to blob storage in the images container. The information for the file is passed in, so the trigger also acts as a binding. Another binding exists to put information onto a queue named images.
Here is the C# script for the function:
The example is a simple function that takes the name of the file that was modified or uploaded to blob storage, and places it on a queue for later processing.
For a full list of triggers and bindings, see Azure Functions triggers and bindings concepts.
Proxies provide redirect functionality for your application. Proxies expose an endpoint and map that endpoint to another resource. With proxies, you can:
Proxies are used for scenarios such as:
Proxies are stored as JSON definitions. Here is an example:
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. 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.
7/3/2018 – 2 minutes read – Edit Online
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.
Adding Application Insights to existing apps is as easy as adding an instrumentation key to your application's settings. With Application Insights you can:
Use Analytics to search, query, and create custom charts over your function data
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:
The following code measures how long it takes to insert a new row into an Azure Table Storage instance:
The resulting performance graph is shown:
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.