slides.pptx

Editor's Notes

• #3: Link to published module on Learn: https://docs.microsoft.com/en-us/learn/modules/learn-pr/azure/create-serverless-logic-with-azure-functions/
• #4: You’ll need a Microsoft account to activate the Azure sandbox environments inside of Microsoft Learn
• #8: You want to use infrared sensors at each table that provide you with data from all of the locations, and you want to develop a reusable service that can process the data from all of the different sources. With *serverless computing*, you can use a cloud provider, like Azure, to manage the infrastructure of your project. Azure Functions is a key component of the serverless computing offering from Azure that enables you to run pieces of code, or *functions*, written in the programming language of your choice, in the cloud.
• #10: Serverless compute can be thought of as a function as a service (FaaS), or a microservice that is hosted on a cloud platform. Your business logic runs as functions and you don't have to manually create or scale infrastructure. The cloud provider manages infrastructure. Your app is automatically scaled out or down depending on load. Azure has several ways to build this sort of architecture. The two most common approaches are Azure Logic Apps and Azure Functions, which we'll focus on in this module.
• #11: Azure Functions is a serverless application platform. It enables developers to host business logic that can be executed without provisioning infrastructure. Functions provides intrinsic scalability and you are charged only for the resources used. You can write your function code in the language of your choice, including C#, F#, JavaScript, Python, and PowerShell Core. Support for package managers like NuGet and NPM is also included, so you can use popular libraries in your business logic.
• #12: Serverless compute is a great option for hosting business logic code in the cloud. With serverless offerings such as Azure Functions, you can write your business logic in the language of your choice. You get automatic scaling, you have no servers to manage, and you are charged based on what is used - not on reserved time. Let’s walk through some of the advantages, and the drawbacks.
• #13: Suppose you've provisioned virtual machine (VM) servers and configured them with enough resources to handle your peak load times. When the load is light, you are potentially paying for infrastructure you're not using. Serverless computing helps solve the allocation problem by scaling up or down automatically, and you're only billed when your function is processing work.
• #14: Stateless functions are great candidates for serverless compute; function instances are created and destroyed on demand. If state is required, it can be stored in an associated storage service.
• #15: Functions are event driven. This means they run only in response to an event (called a "trigger"), such as receiving an HTTP request, or a message being added to a queue. You configure a trigger as part of the function definition. This approach simplifies your code by allowing you to declare where the data comes from (trigger/input binding) and where it goes (output binding). You don't need to write code to watch queues, blobs, hubs, and so on. You can focus purely on the business logic.
• #16: Functions are a key component of serverless computing, but they are also a general compute platform for executing any type of code. Should the needs of your app change, you can take your project and deploy it in a non-serverless environment, which gives you the flexibility to manage scaling, run on virtual networks, and even completely isolate your functions.
• #17: Serverless compute will not always be the appropriate solution to hosting your business logic. Here are a few characteristics of functions that may affect your decision to host your services in serverless compute.
• #18: By default, functions have a timeout of five (5) minutes. This timeout is configurable to a maximum of 10 minutes. If your function requires more than 10 minutes to execute, you can host it on a VM. Additionally, if your service is initiated through an HTTP request and you expect that value as an HTTP response, the timeout is further restricted to 2.5 minutes. Finally, there's also an option called Durable Functions that enables you to orchestrate the executions of multiple functions without any timeout.
• #19: The second characteristic is execution frequency. If you expect your function to be executed continuously by multiple clients, it would be prudent to estimate the usage and calculate the cost of using functions accordingly. It might be cheaper to host your service on a VM. While scaling, only one function app instance can be created every 10 seconds, for up to 200 total instances. Keep in mind, each instance can service multiple concurrent executions, so there is no set limit about how much traffic a single instance can handle. Different types of triggers have different scaling requirements, so research your choice of trigger and investigate its limits.
• #20: Link to published module on Learn: https://docs.microsoft.com/en-us/learn/modules/learn-pr/azure/create-serverless-logic-with-azure-functions/3-create-an-azure-functions-app-in-the-azure-portal
• #21: https://docs.microsoft.com/en-us/learn/modules/learn-pr/azure/create-serverless-logic-with-azure-functions/3-create-an-azure-functions-app-in-the-azure-portal For the purposes of this workshop, we will work with an example that checks for safe temperature levels.
• #23: Now that we have created a function app, let's look at how to build, configure, and execute a function. Functions are event driven, which means they run in response to an event. The type of event that starts a function is called a trigger. Each function must be configured with exactly one trigger. Azure supports triggers for the following services. [Table was here] A binding is a declarative way to connect data and services to your function. Bindings know how to interact with different services, which means you don't have to write code in your function to connect to data sources and manage connections. The platform takes care of that complexity for you as part of the binding code. Each binding has a direction - your code reads data from input bindings, and writes data to output bindings. Each function can have zero or more bindings to manage the input and output data processed by the function. A trigger is a special type of input binding that has the additional capability of initiating execution. Azure provides a large number of bindings to connect to different storage and messaging services. Let's look at an example of configuring a function with an input binding (trigger) and an output binding. Let's say we want to write a new row to Azure Table storage whenever a new message appears in Azure Queue Storage. This scenario can be implemented using an Azure Queue Storage trigger and an Azure Table storage output binding. The following snippet is the function.json file for this scenario. { "bindings": [ { "name": "order", "type": "queueTrigger", "direction": "in", "queueName": "myqueue-items", "connection": "MY_STORAGE_ACCT_APP_SETTING" }, { "name": "$return", "type": "table", "direction": "out", "tableName": "outTable", "connection": "MY_TABLE_STORAGE_ACCT_APP_SETTING" } ] } Our JSON configuration specifies that our function will be triggered when a message is added to a queue named myqueue-items. The return value of our function is then written to outTable in Azure Table storage. For PowerShell functions, output bindings are explicitly written to with the Push-OutputBinding cmdlet. This example is a simple illustration of how we configure bindings for a function. We could change the output to be an email using a SendGrid binding, or put an event onto a Service Bus to notify some other component in our architecture, or even have multiple output bindings to push data to various services. [!TIP] To view and edit the contents of function.json in the Azure portal, from the Home page, select your function app, and in the right pane, select JSON View. The Resource JSON view displays the Resource ID and the editable JSON code. To close the JSON view, select the X in the top right corner of the pane.
• #24: Azure provides several predefined function templates for common scenarios: Quickstart Custom functions
• #25: When adding your first function, you are presented with the Add function pane in which you can select the trigger for your function. Based on your selections, Azure will generate the function code and configuration with sample code provided to display the input data received in the log.
• #26: Selecting a template from the Add function pane provides easy access to the most common templates. Azure provides over 30 additional templates you can start with. These can be selected from the template list when creating subsequent functions.
• #27: When you create a function from a template, several files are created. For example, if you opted to use the Webhook + API Quickstart using JavaScript, the files generated would be a configuration file, function.json, and a source code file, index.js. The functions you create in a function app appear by selecting Functions under the Functions category in the left menu pane of your function app. When you select a function in your function app, your function pane appears. To display and edit your code for your function, in the left menu pane, under Developer, select Code + Test. In the function's path above the code box, select function.json from the dropdown list, and then select Test/Run from the top menu bar for the Input/Output pane to appear. See the following screenshot. As you can see, the pane on the right has tabs for Input and Output. Selecting the Input tab provides parameters to test the HTTP request for your function.
• #28: After you've created a function, you'll want to test it. There are two approaches: Running it manually Testing it from within the Azure portal itself
• #29: You can start a function by manually triggering the configured trigger. For instance, if you are using an HTTP trigger, you can use a tool, such as Postman or cURL, to initiate an HTTP request to your function endpoint URL, which is available from the function definition (Get function URL).
• #30: The portal also provides a convenient way to test your functions. As previously described, after selecting Test/Run from the top menu bar, on the right side of the code box, a tabbed Test pane appears. Here, you can provide parameters to test the HTTP request. When you select Run in this pane, the results appear in the Output tab, along with a status code in the Logs pane.
• #31: The ability to monitor your functions is critical during development and in production. The Azure portal provides a monitoring dashboard, which you turn on by enabling Application Insights integration. In the menu of your function app, under Settings, select Application Insights, select Turn on Application Insights, and then select Apply. In the dialog box, select Yes. The Application Insights dashboard provides a quick way to view the history of function operations by displaying the timestamp, result code, duration, and operation ID populated by Application Insights.
• #32: After you've enabled Application Insights in the Azure portal, you're also able to add logging statements to your function for debugging. The called methods for each language are passed a "logging" object, which may be used to log information to the Logs pane located at the bottom of the code window in the Code + Test pane after running a test. The following JavaScript code snippet shows how to log a message using the context.log method (the context object is passed to the handler). context.log('Enter your logging statement here'); We could do the same thing in C# using the log.LogInformation method. In this case, the log object is passed to the C# method processing the function. log.LogInformation("Enter your logging statement here"); In PowerShell, use Write-Host to write to the log: Write-Host "Enter your logging statement here"
• #33: You can locate the errors and warnings tab in the same menu as the log tab. This tab shows compilation errors and warnings within your code.
• #34: Link to published module on Learn: https://docs.microsoft.com/en-us/learn/modules/learn-pr/azure/create-serverless-logic-with-azure-functions/5-add-logic-to-the-function-app
• #35: https://docs.microsoft.com/en-us/learn/modules/learn-pr/azure/create-serverless-logic-with-azure-functions/5-add-logic-to-the-function-app
• #37: You've learned how to use Azure Functions to host business logic services in the cloud. It's a great way to add hosted services to your solution that can scale and grow with your business. You focus on the code using the language of your choice, and Azure manages the infrastructure. Functions can integrate with other services, like Event Grid, GitHub, Twilio, Microsoft Graph, and Logic Apps to create complex and robust serverless workflows quickly and easily.
• #39: Explanation: Serverless doesn't mean there are no servers - it just means the developer doesn't have to worry about servers. Instead, a cloud provider such as Azure, manages servers.
• #40: Explanation: Serverless doesn't mean there are no servers - it just means the developer doesn't have to worry about servers. Instead, a cloud provider such as Azure, manages servers.
• #41: Explanation: A function app is a way to organize and collectively manage your functions. A function app is comprised of one or more individual functions that are managed together by Azure App Service. All the functions in a function app share the same pricing plan, continuous deployment, and runtime version.
• #42: Explanation: A function app is a way to organize and collectively manage your functions. A function app is comprised of one or more individual functions that are managed together by Azure App Service. All the functions in a function app share the same pricing plan, continuous deployment, and runtime version.
• #43: Explanation: The API can be included in a query string variable named "code", or it can be included in an x-functions-key HTTP header.
• #44: Explanation: The API can be included in a query string variable named "code", or it can be included in an x-functions-key HTTP header.