(2023-08-29 - we've posted a new update that builds upon this one. See the latest update.)
As we look ahead toward .NET 7, it’s a good time to provide an update on the isolated worker model and how we are thinking about the .NET roadmap for Azure Functions. In a previous post, we introduced the isolated process model, which decouples your function code from the core Azure Functions host, in contrast to the traditional model where we run them together in the same process. Functions V4 supports .NET 6 in both models, and the isolated process model also supports .NET 7 (public preview) and Framework 4.8 (public preview). In this update, we’ll re-cap some of our recent updates, outline some changes to look forward to, and expand on our thinking about future versions.
We will provide another roadmap update in early 2023.
Recent updates
One of the strengths of the isolated process model is that you can just switch the `TargetFramework` for your project to try out new .NET versions. You’re also separately in control of the version of the Functions experience and can take changes there completely independently if you want to stay on a given framework version.
No matter which framework version you target, you can now register middleware for your function executions, which can help with exception handling, stamping common HTTP response headers, and more. We’ve also added a public preview for Durable Functions support, which allows you to define complex orchestrations easily in code. We also just introduced a preview for Application Insights support, which supports correlation and the Application Map.
Looking ahead
To get an idea of what’s coming for the isolated worker model, you can always refer to our public roadmap. Much of our work ahead is focused on delivering experiences currently unique to the in-process model, and you can track overall resolution of these gaps on GitHub.
General availability of current previews
The existing previews are all moving toward general availability (GA), with several currently tracking to land in the next couple of months. Support for .NET Framework 4.8 should be the first to see an update, and you can track progress for GA .NET Framework 4.8 support on GitHub. Durable Functions support will follow, and you can track progress for GA Durable Functions support on GitHub. We look forward to announcing general availability of our .NET 7 support when that version becomes available November 2022. You can also track progress for GA .NET 7 support on GitHub.
Because support for Application Insights just recently entered preview, we are still in the process of gathering feedback and assessing our plans for a GA timeline. You can track progress for GA Application Insights support on GitHub.
Additional investments
With Durable Functions becoming generally available, the isolated process model will have the full range of triggers and bindings. However, the types a function can use from its bindings do not yet include the rich SDK types that one might expect from the in-process model, such as BlobClient and ServiceBusMessageActions. Work is now underway on this for triggers and input bindings, and we will be enabling support on an extension-by-extension basis. You can track progress for SDK type support on GitHub. Similarly, we will be exposing full control over the HTTP request and response through HttpRequest and ActionResult. You can track HTTP type improvements on Github.
The programming model will also be getting an update to support cancellation tokens. You can track cancellation token support on GitHub.
Performance is an evergreen investment area, and we are constantly working on both throughput and cold start. In the near term, we expect to make great strides on throughput, and we’re lining up some longer-term cold start work. You can track throughput improvements on GitHub and track cold start improvements on GitHub.
.NET version support
We remain committed to providing day-1 support for future LTS and non-LTS .NET versions. Our intent is to eventually phase out the in-process model, but the timeline for this is not fixed and depends upon improvements we will cover later in this post. Until those improvements to the isolated process model have been made, we will continue to add in-process support for new .NET LTS releases.
The previous post implied a specific timeline for phasing out the in-process model, with .NET 8 only supported on the isolated process model, which is possible but not guaranteed. That change would only occur if the isolated process has reached sufficient parity with the in-process model as outlined in this post. If it does not, there would be an in-process version of .NET 8 support.
We will announce this transition before the initial preview of the first impacted LTS version. Parity will have to have been reached before then; it will be possible at that point to seamlessly uprade an app on the in-process model to its corresponding isolated process model for that .NET version. There will be no compromise in experience resulting from this transition. With that said, you will have plenty of time to navigate the transition as works best for your process and schedule. All .NET LTS versions receive patches for 3 years, so whenever this transition occurs, the last in-process version would still be supported for a full year after the release of the first LTS version that only supports the isolated process model.
A reminder about older versions
Azure Functions support for a given version of a stack ends when formal support for that stack ends. Because .NET Core 3.1 will reach end of support on December 13, 2022, that date is also end of support for function apps targeting .NET Core 3.1. Support for .NET Core 2.2 has already ended, but some apps compiled against it were able to be moved at runtime to .NET Core 3.1, and they will also now be impacted. If your function app is running on Functions V2 or V3, you should plan to move to .NET 6 on Functions V4 to ensure that you receive security updates and have access to the latest features of .NET and Azure Functions.
If you have apps targeting .NET Framework 4.8 on Functions V1, you should also consider migrating those to V4 to take advantage of newer features and dependencies. Many apps on V1 should be able to move to .NET 6 on Functions V4 today. If an app does need .NET Framework 4.8 for any reason, it will be able to move to the isolated process model once support for that framework is generally available in Functions V4.
Be sure to check out our migration guidance for summaries of changes between versions and step-by-step instructions.