Description
(This item is an epic, aggregating a suite of items so that overall progress can be tracked at a high-level. It is not intended to convey specific timing on its own.)
There are features of the in-process model which are not present in the isolated worker at time of this issue being filed. These need to be brought into the worker.
The scope of the core gaps we aim to close and differences that will remain is defined by the rest of this work item. The work captured here is viewed as necessary but not sufficient for a declaration of parity - over time the epic may be edited to include new work. When all items here are resolved, we will reassess the state and either update this item with new work or decide it is indeed ready to be closed out.
Definition of success
This initiative seeks to reduce gaps around:
- capability differences for functions (what the functions can do)
- runtime behavioral differences (how the functions operate)
We are not seeking equivalence for code (how the functions are written). Some differences should still be expected, such as the different namespaces for worker packages, different mechanisms for handling startup configuration, etc.
The work here is also one-way. We are only interested in addressing the isolated model. Any feature unique to the isolated model will not be added to the in-process model.
Current state
Our public documentation on docs.microsoft.com offers an overview of the current comparison, and Differences between in-process and isolated worker process .NET Azure Functions.
We will endeavor to keep it up to date as the work captured by this epic is resolved.
Capability differences to address
Areas we are tracking the following areas:
- https://github.com/Azure/azure-functions-dotnet-worker/labels/application-insights
- https://github.com/Azure/azure-functions-dotnet-worker/labels/durable-functions
- https://github.com/Azure/azure-functions-dotnet-worker/labels/feature%3A%20SDK%20bindings
- https://github.com/Azure/azure-functions-dotnet-worker/labels/feature%3A%20HTTP%20types
- https://github.com/Azure/azure-functions-dotnet-worker/labels/feature%3A%20Configuration
The following work items are also considered requirements:
- Handle InvocationCancel message and signal cancellation for in-flight invocations #976
- Remote Debugging for Isolated mode #905
- [Epic] Support SDK-type bindings for out-of-proc workers #1081
Runtime differences to address
This topic mainly deals with performance behaviors. These are tracked by the following areas:
- https://github.com/Azure/azure-functions-dotnet-worker/labels/throughput
- https://github.com/Azure/azure-functions-dotnet-worker/labels/coldstart
The work here is intended to drive equivalent or improved results in comparative benchmarks. It may be that additional investigations and work will be required beyond what is captured already.
Permanent differences
We accept some differences between the models as permanent. There are behaviors of the in-process model which we will not bring into the isolated worker. These are outlined in the following subsections.
Out parameters
In early versions of WebJobs and Functions, out parameters were used to support multiple different output bindings in the same function. However, out parameters cannot be used in asynchronous functions, and the isolated process model offers richer options for return values which may include multiple binding results.
Recommended approach in Isolated: Leverage return values for multiple output binding results.
Imperative bindings
The in-process model supported creating binding definitions at runtime, which was helpful when binding parameters needed to be computed at runtime. However, the corresponding service SDKs tend to be less verbose and have advantages for error handling and debugging purposes.
Recommended approach in Isolated: When you need to interact with a service with parameters determined at runtime, using the corresponding service SDKs directly is recommended.