Azure Functions support two different worker processes. With the introduction of .NET 5, Microsoft decided to make an isolated worker process, which is the only future model, and we s developer need to gradually move in that direction.
In this session, I show you how to build Azure Functions with the Isolated worker process in .NET 7. He will also dive into the .NET 8 roadmap and how that affects Azure Functions.
Getting started with Azure Functions in Isolated Mode
1. Getting started with Azure Functions
using Isolated worker process
Callon Campbell
Microsoft MVP | Azure
@flying_maverick
2. About me
Callon Campbell
Azure Architect | Developer
Adastra
Microsoft MVP | Azure
20 years enterprise development with Microsoft technologies – .NET (C#),
Azure, ASP.NET, Desktop, SQL, and Mobile
Passionate about serverless and cloud-native application development,
with focus on app migration and modernization, app integration and data
analytics
Blogging at https://TheFlyingMaverick.com
Speaker at community events and meetups
Organizer of “Canada’s Technology Triangle .NET User Group” in
Kitchener, Ontario
3. Agenda Overview of serverless
Different hosting models
Preparing for .NET 8
Demos
Wrap-up
Q&A
4. Azure Functions
Run code when events occur
Event-driven scaling
No infrastructure management
Consumption pricing with free grant
6. .NET functions hosting models
In-process
Your function code runs in the same process as the Functions host
process. Only supports LTS versions of .NET
Isolated worker
Your function code runs in a separate .NET worker process.
This is what all non .NET languages use.
7. Why .NET Functions isolated worker process?
When it was introduced, Azure Functions only supported a tightly
integrated mode for .NET functions called in-process.
Your code runs in the same process as the host, resulting in a tight
coupling between the host process and the .NET function app.
In-process function can only run on the LTS version of .NET.
Non-LTS required you to use an isolated worker process that debut
in .NET 5.
Isolated worker process aligns with the evolution of .NET.
8. Comparing Azure Functions hosting models
In-process
Migrate from .NET Core 3.1 in-
process
Need Durable Functions Entities or
“rich” SDK type bindings that are
Support for .NET 6 and .NET
Framework 4.8
Performance and cold-start
optimization
Isolated worker
Migrate from .NET 5 or .NET 6
isolated process
Added support for middleware
Support for .NET 6, .NET 7, .NET
Framework 4.8, and .NET 8
(preview)
Which one do I use?
Details: https://learn.microsoft.com/en-us/azure/azure-functions/dotnet-isolated-in-process-differences
10. Azure Functions .NET Roadmap
In-process
Isolated process
.NET 5 .NET 6 LTS .NET 7 .NET 8 LTS
.NET Core 3.1 LTS .NET 6 LTS
with Durable Functions
Nov 2021
Nov 2022 Nov 2023
11. Strengths of Isolated worker process
Fewer conflicts: Assemblies used in your app won't conflict with
different version of the same assemblies used by the host process.
Full control of the process: You control the start-up of the app and
can control the configurations used and the middleware started.
Dependency injection: Use current .NET behaviors for
dependency injection and incorporating middleware into your
function app.
Target new versions: Easily target new versions of .NET as they
become available.
13. Migrating to the Isolated worker process
.NET 6 In-process .NET 7 Isolated worker
Project file changes
14. Migrating to the Isolated worker process
.NET 6 In-process .NET 7 Isolated worker
• The packages for these extensions will all be under the
Microsoft.Azure.Functions.Worker.Extensions prefix.
• Be sure to install the latest stable version of any packages you are targeting.
• Your application should not reference any packages in the Microsoft.Azure.WebJobs.*
namespaces. If you have any remaining references to these, they should be removed.
Microsoft.NET.Sdk.Functions Microsoft.Azure.Functions.Worker
Microsoft.Azure.Functions.Worker.Sdk
15. Migrating to the Isolated worker process
Code changes: new Program.cs
file
In-process Isolated worker
[FunctionName("Function1")] [Function("Function1")]
Code changes: Function
attribute
16. Migrating to the Isolated worker process
In-process Isolated worker
Configuration changes
"FUNCTIONS_WORKER_RUNTIME":
"dotnet"
"FUNCTIONS_WORKER_RUNTIME":
"dotnet-isolated"
Tip
If you are moving to an LTS or STS version of .NET, the .NET Upgrade Assistant can be used to
automatically make many of the changes mentioned.
17. Update your function app in Azure
Upgrading your function app to the isolated model consists of two
steps:
1. Change the configuration of the function app to use the isolated model by
setting the FUNCTIONS_WORKER_RUNTIME application setting to "dotnet-
isolated". Make sure that any deployment automation is similarly updated.
2. Publish your upgraded project to the upgraded function app.
Use a staging slot to test and verify your upgraded code /
configuration. Then perform a swap operation when ready to deploy
to the production slot.
20. Azure Functions .NET 8 roadmap
Isolated worker process reaching feature parity.
Isolated worker will be initially supported on .NET 8 release.
In-process for .NET 8 will be the last LTS release and will be
released slightly after the .NET 8 release.
21. .NET 8 (preview) for Azure Functions
Preview support for .NET 8 function apps is currently limited to Linux
applications.
Requires .NET 8 Preview SDKs in Visual Studio (Visual Studio 2022
Preview).
Performance optimizations is coming…
Placeholder for cold-start
Optimized executor
ReadyToRun (form of AOT)
.NET 8 AOT compilation
23. What we covered
Comparison of in-process and isolated worker processes.
Benefits of the isolated worker process and migration path.
Sneak peak at .NET 8
24. Closing
The isolated worker is in position to tackle things that can’t be done
with the in-process model.
Try the isolated worker process and plan your migration.
If performance and certain key features are critical, stick to the in-
process model for the time being since with .NET 8 it will still be
supported.
25. References
Azure functions runtime versions overview
C# Azure Functions in an isolated worker process
.NET on Azure Functions — August 2023 roadmap update
.NET Upgrade Assistant
Quick overview of Azure Functions
- Run code based on an event (http, storage account, cosmos db, event grid, service bus and many more)
- Don’t have to worry about infrastructure, that’s handled for you.
- It will scale from not running to 1000s of instances and back down as needed.
- As it scales you only pay for what you use.
Functions is open source – runtime, core tools, docker images.
Run it locally, its exactly what you see in the cloud. Very easy to get going and publish.
Publish to Azure Functions services – consumption, app service, and premium (best of both worlds)
There is also other places to run functions – Raspberry Pi, Kubernetes cluster, or on non-azure hosts and on-prem.
- However, this integration also requires a tight coupling between the host process and the .NET function.
- This means that you're in-process functions can only run on version of .NET with Long Term Support (LTS).
- To enable you to run on non-LTS version of .NET, you can instead choose to run in an isolated worker process. This process isolation lets you develop functions that use current .NET releases not natively supported by the Functions runtime, including .NET Framework.
- It offers a rich dependency injection model, full control over main() and app dependencies, improved reliability, additional features like invocation middleware, and more.
- The isolated worker process in functions is now aligned with how the .NET ecosystem has evolved.
For .NET, Azure Functions supports both in-process and isolated (out-of-process) execution models. Choose in-process if you are upgrading from .NET Core 3.1 Azure Functions or if you are looking for features, such as Durable Functions, that are currently only available to in-process apps.
Isolated function apps provide more control of the function worker process and greater compatibility with libraries.
If you’re using the in-process model, you can continue to use this for a while its supported on LTS branch, but as you can see all new .NET versions will be targeting the isolated process.
Support for middleware which can help with exception handling, stamping common HTTP response headers, and more.
A diagram showing the change in release patterns after parity. .NET 8 has an in-process model option on a delay after the isolated worker model. All subsequent updates use the isolated worker model.