Is it time to start creating C# Azure Functions in isolated mode?

At the time of writing this post, we're close to the release of .NET 6 and Azure Functions version 4 is available in private preview

For the most part, changes to Azure Functions are evolutionary rather than revolutionary. The vast majority of what you already know about writing Azure Functions still applies.

In-Process and Isolated Modes

However, in this post I want to discuss an important decision you need to make when creating new Azure Function apps using C#, and that's whether to use "in-process" or "isolated" mode.

The "in-process" model is the original way .NET Azure Functions ran. The Azure Functions runtime, which itself runs on .NET, simply loaded your functions into the same process. However, all other languages supported by Azure Functions (such as JavaScript, Python etc) use an out-of-process model where the Azure Functions runtime talks to your functions which are running in a separate process.

Both approaches have their benefits, and this means that there is going to be a period of time where the decision of which model to chose is not obvious, because the new isolated mode still has a few limitations.

Let's quickly look at the benefits of the two modes.

Benefits of Isolated Mode

The Azure Functions roadmap makes it clear that the isolated process model is the future and will be the only choice from .NET 7 onwards. This means that if you do choose isolated mode, the upgrade path will be simpler in the future.

One of the key motivations for isolated mode, is that you are not tied to the same version of the .NET runtime and any Azure SDKs that the Azure Functions runtime happens to be using. For most people this is not an issue, but when it does block you from using something you need it is quite frustrating.

Isolated mode also gives you a quicker route to using the latest C# language features (although there are work-arounds for in-process functions).

Isolated mode also will feel more familiar to ASP.NET Core developers allowing you to set up dependency injection and middleware in the exact same way that you are used to.

Benefits of In-Process Mode

One key advantage of staying with in-process mode is that it currently is required for Durable Functions. To write Durable Functions in isolated mode, you need to wait until .NET 7.

In process-mode also enjoys some performance advantages inherent to the way it works. It can allow you to bind directly to types exposed by the Azure SDKs. By contrast, isolated mode does not allow you to directly use IAsyncCollector or ServiceBusMessage which is a bit of a step backwards and hopefully the shortcoming will be rectified in future versions of Azure Functions. (some of these limitations can be worked around as Sean Feldman discusses here)

My Recommendation

If you are using Durable Functions, or still relying on binding to specific types not supported with isolated mode then I recommend staying with in-process functions on .NET 6. Also if you currently rely on any of the binding types not supported in isolated mode then it is also probably simpler to stay with in-process for now.

Of course, if the limitations don't affect you, feel free to start using isolated mode now. The Azure Functions documentation has a good breakdown of the current differences between in-process and out-of-process functions which should help you make the decision.

Hopefully by the time .NET 7 is released, there will be sufficient improvements to the isolated process model to make it an obvious default choice for all new Azure Function Apps.