Why You Should Switch to the Azure Function Isolated Worker Model

Are you already using the Isolated Worker Model for your Azure Functions?

If yes, you are safe! Otherwise, see just a glimpse of what you are missing below:

- Custom dependencies: Developers have full control over the dependencies and configurations of the function app. You can use many thing that you already use to make a good maintainable codebase in .NET. Dependency injection, Logging, Middleware etc. Cool, yeah?

- Improved Diagnostics: The isolated worker model offers enhanced diagnostics and better observability into function execution. Local debugging is easier, and more flexibility in how & what is logged in App insights.

- Future-Proof: The isolated worker model is part of Azure’s long-term strategy, supporting the latest .NET versions and future features, while Microsoft is gradually phasing out the default runtime model, making adoption essential for staying current. Support will end for the in-process model on November 10, 2026. This sounds good for the business.

But wait, we need some understanding. What exactly are these models?

There is nothing too technical here! Basically, Azure functions can execute/run in two modes or models.

For Azure functions to run, they rely on the Azure Function Host. (The Microsoft background managed service that handles things like orchestrating function invocations, managing resources, and monitoring and logging of function executions.)

The two modes:

- In-Process: The default or classic one which probably you are using. This means both your code & Azure Function Host share the same resources and are served from the same source. Meaning they are tightly coupled and would need to be in sync in many ways.

- Isolated Worker: Function code runs in its own separate .NET worker process separate from the one that the Host uses. You have full control over the .NET runtime and environment for your function because it's not being shared with the Host.

The isolated worker model for Azure Functions is available starting from .NET 5 and later versions, including .NET 6 and .NET 7. It is not available in the older .NET Framework (e.g., .NET Framework 4.x).

What is different in the development experience? I would say quite a lot. As somethings would need to be expressly setup and configured.

Creating a project it is easy from visual studios, we just need to select the functions worker:

Here is how the function class looks like:

Then you also have a program.cs file, this is where you configure your startup processes, register services if using DI, etc:

There are also a few new things in the .csproj files. You still have the regular host.json file that defines configuration shared by functions in your project and local.settings.json

For more details on building this: Microsoft Isolated Process Guide

For guide on migrating from in-process to isolated: Microsoft Migrate to Isolated

I encourage you to migrate and also choose the isolated worker model for new projects going forward.

Leave me a comment if you have got questions.

That's all for today. See you in the next one.