azure-functions-host VS azure-functions-dotnet-worker

True but I was baffled to find out that structured logging simply doesn't work in Azure Functions in Isolated Mode! The solution is to use Serilog.

Investigating and reporting issues with timer triggered functions not firing

As someone whose job involves maintaining uptime of a critical system that's dependent on Cosmos DB this sort of thing is scary. Where there's been other reliability issues with Cosmos before we've not had an understanding customer base, and it feels very out of my control.

I'm finding a lot of the reliability guarantees of Azure PaaS services are overblown or come with big caveats when you start to work with them in a serious way. For example I've had some bad reliability issues with Azure Functions not firing, or the hosts becoming unresponsive. And it seems like there's a large set of outstanding issues with them beyond that https://github.com/Azure/azure-functions-host/issues

I think people need to look more carefully at these PaaS guarantees and look at what that 99.999% reliability Microsoft are claiming actually means.

See the answers of this issue on GitHub.

Before we move on, so what really is a custom handler and how does it work? Custom handlers let your Function app to accept events (eg. HTTP requests) from the Global host (aka Function host - that powers your Function apps) - as long as your chosen language supports HTTP primitives.

Functions can be triggered in multiple ways: HTTP, Queue, Db, Blob Storage Change and many more. More on this can be found here. This was one of the major reasons why I thought Azure Functions are great. I mostly needed the HTTP and Queue trigger. With HTTP functions comes also the requirement for Authentication and Authorization. I'm using Auth0 as an authentication provider. The implementation is usually straightforward. The frontend obtains an access token and the API validates the token and authenticates the request. OpenID connect is well documented and somewhat easy to use in asp.net core for example. Not with Azure Functions I googled for days, opened an issue and tried everything I could think of and came to the conclusion: Microsoft doesn’t provide you with proper SDKs to handle authentication adequately.

ODBC drivers in most (if not all) cases are slower than native libraries. I didn't check what does binding for python uses, you can check their repo if you want to https://github.com/Azure/azure-functions-host

Technically the Azure Function host reaches out to a CDN and installs the function based on some constants hidden in the Azure Functions Host (see https://github.com/Azure/azure-functions-host/blob/9bdb40b2d517f32c5052956ba8c9cf662ea36a9e/src/WebJobs.Script/ScriptConstants.cs => search for ExtensionBundleDefaultSourceUri)

The official example also doesn't use that. https://github.com/Azure/azure-functions-dotnet-worker/blob/main/samples/FunctionApp/Program.cs

Found that newer versions of the function runtime is completely broken (Incidentally i need to use durable functions, so this is annoying on multiple levels). https://github.com/Azure/azure-functions-dotnet-worker/issues/556

The Azure Functions .NET worker has been out for a while, and it finally enabled developers to use C# 9 and .NET 5 on function apps. This is a new way to create C# function apps, it now has a Program.cs class, with the good old generic Host builder and all the extension methods that we're used to see on regular ASP.NET Core and Worker service projects. This is how it can look:

name: Build & Deploy on: push: branches: - master pull_request: env: FUNCTION_PACKAGE_PATH: .publish/function RESOURCE_GROUP: az-function-fsharp-net5 jobs: build-and-deploy: runs-on: ubuntu-18.04 steps: - name: Checkout code uses: actions/checkout@master with: fetch-depth: 0 - name: Setup dotnet SDK 3.1 (https://github.com/Azure/azure-functions-dotnet-worker/issues/480) uses: actions/setup-dotnet@v1 with: dotnet-version: "3.1.409" - name: Setup dotnet SDK uses: actions/setup-dotnet@v1 with: dotnet-version: "5.0.300" - name: Publish Function run: dotnet build src/Function -c Release -o ${{ env.FUNCTION_PACKAGE_PATH }} - name: Login to Azure uses: azure/login@v1 with: creds: ${{ secrets.AZURE_RBAC_CREDENTIALS }} - name: Deploy to Azure uses: azure/CLI@v1 with: inlineScript: ./deploy.sh ${{ env.FUNCTION_PACKAGE_PATH }} -g ${{ env.RESOURCE_GROUP }}

There is a GitHub issue for this as well. https://github.com/Azure/azure-functions-dotnet-worker/issues/283

But how does this work? The idea is pretty straight forward, you create a class with properties for all the output values and decorate them with output binding attributes. Here is an example borrowed from the official Samples.

The biggest change is the way output bindings are changed and not clear from the example above, if you want to use multiple outputs you need to define them in a class and use it a a return type. This is illustrated in the example below that I have borrowed from the official repository.