You would typically use Azure Functions to run bits of your overall application logic on-demand in the same way that you use any other HTTP-accessible endpoint. Just as with any other API endpoint or library function, you create a serverless Azure Function to do some compute work as a part of a larger logic landscape. You can configure Azure Functions and pass data to and from them using a wide range of architectures.

As I mentioned, Azure Functions are just HTTP endpoints that you can call in the same way that you call any other API endpoint from within your code or other process. However, instead of residing on a standard web server that is operational 24/7/365, your Azure Function is available, quote, on demand whenever you call it. The endpoint is not provisioned into the cloud until it is called. As a result, because your cloud services charge you per minute for any resource in use, an Azure Function is typically less costly to operate than a typical API endpoint web server that's running and available all the time.

And when do you use Azure Functions? Well, Azure Functions have triggers that cause them to execute. So they are especially useful when responding to events such as data coming or going, timers going off, or even HTTP requests coming in. If you have some code that you want to execute based only on a particular event, one that may or may not occur regularly, Azure Functions can be a solution.

As I mentioned, triggers for your Azure Function can include timers, data operations, and standard HTTP calls or webhooks. Triggers are created in a configuration file that is a companion to your Azure Function. As we'll see when we write our first Azure Function, the trigger type you choose actually defines your project.

Azure Functions connect to your data stores and resources through the use of bindings. Input bindings provide any needed data to your Azure Function and output bindings receive any results. Bindings are created in the same configuration file I mentioned that is the companion to your Azure Function when you publish it.

We will cover the implementation of triggers and bindings in the first part of the course.

Because Azure Functions employ the on-demand services model I mentioned earlier, they are typically stateless. Azure Functions are serverless meaning there is no host server to hold or store information between calls. Your Azure Function is provisioned into the cloud when it needs to run and de-provisioned immediately afterwards so there is no concept of state connected to it.

However, there is an extension to standard Azure Functions called Durable Functions that does allow you to manage state/coordination of different Azure Functions. It's a very useful feature in a serverless environment. We will cover the use of Durable Functions in the second part of the course.