Azure Functions is a serverless compute service in Azure which lets you run event-triggered code without managing infrastructure. It is used for lightweight, single-purpose tasks. Azure Functions charges only for the compute time used. This service is ideal for scenarios where you would like to respond to events or perform background tasks without needing a dedicated server.

Azure Functions currently supports six different languages, C#, Java, JS, PowerShell, Python & Typescript. Most people tend to opt for Python as their language of choice when creating functions, because functions are mostly used for micro applications, and Python is great for this.

I have found it incredibly useful to complete background tasks that are typically manual. An example being that we needed to automatically generated reports based on log queries that are run in Microsoft Sentinel. Currently at the time, we would just have a list of KQL queries in a document, then just fill out a template with the results. It’s not a hard task to do manually, but it can be automated. To automate this, you could have a timer trigger, so it automatically generates a report say daily, weekly, or monthly. You could do that, or you can do it ad hoc via an API trigger. All the function would need to do is call Log Analytics via REST POST request with the query & workspace ID. In this example, you want to have it generate a word document with the results and maybe some other logic based on the results, you could use the docxtpl Python module to render the results (In Word) and upload it to Azure Blob Storage. When creating an Azure Function, it requires a Azure Storage Account to be created (You can use an existing one), and you could store the data in here, or you could upload to SharePoint, send it as an email, etc.

Authentication in Azure Function apps to other Azure Resources is incredibly easy. Once you’ve created the function resource, you can turn on it’s system-assigned managed identity, which will create a object in Entra ID, which you can assign to different resources. So if it would need to interact with a storage account, you can just give it access to that storage account via an RBAC role on the MI resource. Alternatively, you can use different authentication methods via an app registration, or storage account key (If a storage account). When developing applications, it is best practice to use a managed identity as it’s tied to the resource. You can also use user-assigned managed identities which is like system assigned, however, it is not tied to a single resource and can be used against different resources.

When developing Azure Functions, I’ve found it is best to use Visual Studio Code which is a commonly used IDE for developing small applications. There is an extension called Azure Function Core Tools which allows you to run your Azure Functions locally. So before you release to Azure, test it locally first before deploying to Azure. I have found it to be quite slow to startup, so generally I develop the application first (Normally a python script), once done I turn it into a function project (Using Core Tools). Once the application is developed, you can simply push it to Azure directly through VS Code.

In conclusion, as someone who develops a load of random things in Azure – It’s incredibly powerful, especially since you do not have to manage the underlying infrastructure.