In-process vs Isolated Worker in Azure Functions World

Why This Article?

A few months ago I needed to upgrade some Azure functions to .NET 8 and realised that my functions were using an in-process model, which is not supported anymore. I knew there were 2 models, but didn’t understand the difference between them. They were using different namespaces, so even the syntax was slightly different, so I started to read about this subject.
Going fast-forward, the migration was done, had some small problems due to our internal architecture, but it went fine in the end, but this week someone asked me for a second opinion on his pet project and realized that I don’t really remember the differences between the models. That is why, not, I am doing the research again, and note it down, maybe, you, my dear reader, will need it also.

Differences between models

1. Execution Context — In-proc is using the same process as the runtime (azure functions runtime), which means it uses the same environment variables, libraries, dependencies etc, while the isolated worker is using a separate process. This means it is completely decoupled from the runtime, but it gets a higher cold start than the in-process model.
2. Dependency Management — I already mentioned that in-proc uses the same dependencies as the runtime, so, as you can imagine, you might have conflicts between versions of things (think about Newtonsoft.Json or Azure.Storage)
3. Startup — In the In-process model you get the honour of having a Startup and being able to configure your dependencies using an IServiceCollection (so it is pretty much the same as any other ASP.NET Core app), while in the Isolated Worker model, the configuration is done by using a Program.cs file which gives you the feeling of a console app. You need to use the HostBuilder to register services, configure logging and so on. From my point of view, you need to use different patterns but you can do the same things, without having any limitations.
4. Speed, What’s the speed? — The cold start is slightly higher on the isolated worker (as already mentioned). Now, it depends on how much you care about it. You can use a premium or dedicated plan in which you always have one instance alive, and most likely you won’t feel any difference between the models.
5. Future-Proofing — In proc functions might be affected after a runtime update, and because of one, you might need to change some code, to make “the thing” work again. In an isolated worker model, everything is decoupled so, you don’t really care.
6. Supported .NET Versions — After .NET 6 you don’t have support anymore for the In-Process model. I’ve heard some rumours that this might change, and that Microsoft might support, again, both models in the future, but for the moment how I see it, is that they are pushing only for the isolated model, and this is their long-term vision.

Conclusion

Migrating from the In-process model to the Isolated Worker model may initially seem like a hard task, however, understanding these distinctions helps you make informed decisions and prepare for future-proof solutions.

The Isolated Worker model introduces greater flexibility, decoupling, and control over your application’s lifecycle, making it the preferred approach for modern Azure Functions development. If you’re still on the In-process model, now might be the perfect time to evaluate your setup and plan for migration.

Remember, staying ahead in the “ever-evolving world” of cloud development often involves embracing change and learning from challenges. My migration experience and this comparison aim to make your journey smoother and more predictable.