logicapps VS azure-functions-host

Tip: I make this step sound incredibly easy. From what I can see, the Logic Apps Visual Studio Code tooling doesn't have an option to generate a Dockerfile for you. There were several Dockerfiles in the wild that used a very specific base image name, and didn't feel quite right. After some digging, I found the Azure/LogicApps repository which has a github-sample, including a Dockerfile. I used that Dockerfile to build a docker image from my local machine and push that to the container registry. In a real world scenario, I would have a CI/CD workflow setup for that, but this is not the point of this blog post.

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)