In-process model
- Your function code runs inside the same process as the Azure Functions runtime
- Uses the WebJobs SDK.
What this means
-
Used in:
-
Azure Functions v1–v4 (in-process)
-
-
Namespace:
Microsoft.Azure.WebJobs -
Runs inside the same process as the Azure Functions runtime
-
Uses:
-
ILoggerfor logging -
TimerInfofromMicrosoft.Azure.WebJobs
Characteristics
-
Tight coupling to the Functions runtime
-
Faster startup (historically)
-
More magic / implicit behavior
-
Not recommended for new apps going forward
2. Isolated worker model
- Your function runs in a separate .NET process from the Azure Functions runtime.
- Communicates with the runtime over gRPC.
[Function("TimetriggerFunction")]
What this means
-
Used in:
-
Azure Functions v4+ isolated worker
-
-
Namespace:
Microsoft.Azure.Functions.Worker -
Runs in a separate .NET process from the runtime
-
Uses:
-
FunctionContextinstead ofILogger -
Logging via
context.GetLogger(...)
Characteristics
-
Decoupled from the Functions runtime
-
Better:
-
Dependency injection
-
Versioning control
-
Middleware support
-
-
Required for:
-
.NET 8
-
Future Azure Functions development
Key Differences at a Glance
|
Feature |
[FunctionName] |
[Function] |
|
Hosting model |
In-process |
Isolated worker |
|
Runtime coupling |
Tight |
Loose |
|
Logging |
ILogger |
FunctionContext |
|
Namespace |
WebJobs |
Functions.Worker |
|
.NET 8 support |
❌ No |
✅ Yes |
|
Recommended for new apps |
❌ No |
✅ Yes |
Summary
Isolated worker = modern, decoupled, flexible, future-proof
No comments:
Post a Comment