Azure Functions – Josh's Space

Isolation - good for Azure Functions, bad for people — Isolation – good for Azure Functions, bad for people

A short while ago I posted a summary of the current state of play of Azure Functions and .NET 5. In short, to run your function in .NET 5 you need to use the new Isolated Process. It’s so new that it’s missing a lot of the Azure Functions features, e.g. several bindings and Durable Functions. So Durable Functions users are stuck on .NET Core 3.1 until .NET 6 is supported in the In-process version.

Whilst all that is still true, there is now an update from the team on where they’re intending to go in future. The In-process version will end with the .NET 6 release and development will concentrate on bringing the Isolated Process up to feature parity in time for .NET 7. Read their post here. After that they are promising to support .NET versions as and when they are released.

This is best illustrated by reposting their roadmap from that link:

The Durable Functions support in the Isolated Process is said to arrive in “2022 or possibly earlier”. I look forward to it.

.NET 5 was released on November 10th 2020 and contains features (specifically C#9 support and thus Record Types) that we were keen to use in our products at Matchnet.

As we’re heavily based on Azure Functions, I was happy to see an announcement of a preview of Azure Functions on .NET 5. We went ahead and evaluated it, and here’s what we found:

No support for rich function types such as Durable Functions.
Visual Studio support is not there yet, but promised soon
HTTP trigger interface uses simplistic HTTP message abstraction (HttpMessageData instead of HttpRequest)

Durable Functions

This was the most disappointing issue, as we’re using Durable Functions in a few places. They’re a useful implementation of a saga/orchestration.

The implementation of the .NET 5 Azure Functions is based around “an out-of-process model where a .NET worker process runs alongside the runtime”. On the face of it this sounds good, as it decouples us from the runtime’s version support. However, it means we also don’t have access to the extension code running in the host, which is what Durable Functions relies on. See this GitHub issue comment.

The team will be updating the host to the .NET 6 LTS, which will mean .NET based functions being deployed in the conventional way, directly to the host and not out of process, so Durable Functions should work fine. Roll on November 2021.

Visual Studio

As of Visual Studio 16.8.4 there isn’t a project template for the out-of-process .NET 5 functions. Instead you create an ASP.NET Core project and build around that. The readme on the GitHub preview site has the details.

We had trouble getting local debugging running. The only way that seemed successful was to start the program then attach to the “dotnet.exe” process, if you can find the right one. It’s a bit of a hassle but I expect that will get sorted out with official Visual Studio support.

HTTP Trigger’s HttpMessageData

This is the class used to convey the payload for an HTTP trigger. It’s a wrapper on top of a RpcHttp class, part of a .NET implementation of gRPC. As such it has a very simple interface and doesn’t provide for the full suite of normal HTTP capabilities including cookies and attaching files, both of which are possible in the standard Azure Functions HTTP trigger via the HttpRequest class.

Conclusion

We’re going to skip it for now, though we’ll keep an eye on where it goes. It doesn’t sound to me like the out-of-process model is where the function team’s heart is at right now for .NET functions, so I hold out more hope for the upgrade of the host to .NET 6.