(2024-03-26 - we've posted a new update that builds upon this one. See the latest update.)
Our last roadmap update was in September 2022, in which we outlined our plans for bringing the Azure Functions isolated worker model to parity with the in-process model. In that post, we also stated that we would have another update in early 2023, but unfortunately this did not happen. However, we’ve made great progress since the last post, and today we’d like to share where we’re at with the isolated worker model, and how we’re thinking about the future.
Isolated worker model assessment
The isolated worker model you author your functions in a way that’s aligned with how the .NET ecosystem has evolved. It offers a rich dependency injection model, full control over main() and app dependencies, improved reliability, additional features like invocation middleware, and more. Our deepest thanks to the community of function authors who have helped us identify and validate enhancements to this modern way to write apps. Since the last roadmap post, we’ve released quite a few updates:
- Support for .NET Framework 4.8
- Support for .NET 7
- Support for Durable Functions
- Support for Application Insights from the worker
- Support for binding to SDK types
- Preview support for ASP.NET Core integration
These bring us within sight of parity, though some applications' needs are not yet addressed. The remaining work is outlined later in this post, but we're confident in it landing in advance of the .NET 8 general availability (GA) release. We are therefore going to start treating the isolated worker model as the default in documentation and client tools. The in-process model can still be selected, but we think most new projects are now better off starting on the isolated worker model.
.NET 8 plans
We are therefore also ready to confirm that we intend for .NET 8 to be the last LTS release to receive in-process model support in Azure Functions. Subsequent LTS versions of .NET would be supported on the isolated worker model only.
.NET 8 will at first only be available on the isolated worker model. There will be an initial preview soon, and we remain committed to full support on the isolated worker model the same day that .NET 8 becomes generally available. However, there will not be an in-process equivalent at the same time. That will come in a subsequent release in early 2024, and we will be doing what we can to make it available as soon as possible. So, if you are looking to use .NET 8 right when it comes out, you will have an option with the isolated worker model. But if you wish to continue using the in-process model, there will be a slight delay.
The preview of .NET 8 on the isolated worker model will initially only support Linux function apps, and support for Windows apps will be added as we move through the preview.
Remaining parity work
We still have a few items to complete as part of our overall parity initiative. However, most apps should be functionally covered for parity once ASP.NET Core integration moves to GA status. That update is just pending completion of a runtime deployment. The same deployment will also enable a preview of optimizations to improve the cold start of your application.
After that, there are two remaining scenarios to close, both of which are actively approaching their previews as well. First is support for message settlement scenarios with Service Bus triggers. Second is support for stateful entities in Durable Functions. We’re also tracking a few smaller items that will be landing soon, too.
If there’s anything we’ve missed, please file an issue on our GitHub repository. We’re very excited to enable more .NET function apps to reap the benefits of the isolated worker model, and we’re looking forward to seeing what kinds of apps you build as we evolve the platform even further.
Updating applications
If you’re interested in moving an existing app using the in-process model to the isolated worker model, we have a migration guide that can help. The .NET Upgrade Assistant also supports Azure Functions projects and can automate many of the changes for you. It can also help you with migrations to version 4.x of the Functions runtime from version 1x or from the no-longer-supported 2.x and 3.x versions. And if you run into issues navigating any of these transitions, the Microsoft Q&A community is a great place to get assistance.
One of the strengths of the isolated worker model is that you can easily target new .NET versions as they become available. Be sure to consult the .NET Support Policy when determining the right target framework for your projects.
Closing thoughts
The isolated worker model after parity is in a great position to tackle things that can’t be done with the in-process model. It’s an exciting time for .NET on Azure Functions, and we want to again thank the community for the invaluable feedback we receive that helps us continue to make the product even better.
- The Azure Functions team