Azure Isolated Function | Host and worker process initialization and execution flow

Question

I'm bit unclarified with Azure Functions Isolated model.

Below are the points gathered from the web.

1. Azure Function code runs in the different process (worker process) and Function host runs in the different process.
2. Both processes are communicated over Inter-Process Communication (context switching)

Scenario: Azure Isolated function with Service Bus queue trigger

Execution flow (My understanding):

1. Function Host process starts (Host.json configurations are applied). Sets service bus queue listener
2. Creates worker process as defined in the Program.cs
3. When a message received in service bus queue, host process fetches it and sending to worker process through IPC (context switching).
4. Worker process process the message as per the code written by user.
5. After the message processed, Host process again invoked and service bus message completed.

Help me with below questions

1. What are the roles of Function host process and Worker process. How both contributes in the function execution pipeline. (I'm trying to understand the clear view on execution pipeline)
2. Configuration in Host.json is applied for Function Host and appsettings.json for worker process?

People, if you feel any unclarities in the above, please add a comment to resolve it.

I hope this thread might help others as well.

Answer 1

History: Principles of In-process Functions

Previously your Function code and the Azure Functions runtime shared the same process. It's a web host, and it's your Functions code, all running in one process.

The runtime handled the inbound HTTP requests by directly calling your method handler.

Background: Principles of Isolated Functions

The Azure Functions Host runtime is still responsible for handling the inbound HTTP requests. But, your Functions app is a totally separate .NET application, running as a different process. Even in a different version of the .NET runtime.

If you run it locally you'll see two processes:

1. The Functions Host process (Func.exe on Windows, dotnet WebHost on Debian Linux)
2. A separate .NET process launched with your Functions app

Your Isolated Functions app isn't too much different from a console app. It's definitely not a web host.

This makes even more sense when you consider that the entrypoint is Program.cs. It's clear that no other code is involved in initialising your app. That's quite different from In-process where you define a Startup class - i.e. a method called by the Azure Functions runtime code because they're part of the same process.

Actual answer: How the pipeline works

So if your Functions are running in something similar to a console app, how is it handling HTTP triggers if it's not a web host any more?

The answer is that your Functions app, although isolated, has a gRPC channel exposed. The Functions Host process handles the HTTP requests for you, and passes them to your Functions app through the gRPC channel.

The gRPC channel in your Functions app isn't obvious, and it's not something you explicitly open or have control over. You might stumble across it in a stack trace if you hit a breakpoint or have an unhandled exception.

The pipeline becomes:

1. Host process receives HTTP request
2. Host process calls your Functions app via gRPC
3. Functions app calls your Middleware classes, if you registered any
4. Functions app calls your Function method, and you return a response
5. Functions app returns the response back to the Host process via gRPC
6. Host process returns the HTTP response back to the caller

Other notable differences in the pipeline

As mentioned above, Isolated lets you add your own Middleware classes into the processing pipeline. These run in your Function code immediately before the actual Function method is called, for every request. In-process had no convenient way to achieve this.

Even though your Functions aren't handling the HTTP call directly, helpfully your Middleware classes can still access a representation of the HTTP request that's passed in from the Host. This enables you to check HTTP headers, for example. It's particularly useful in your Middleware classes because you can perform mandatory tasks like authentication, and it's guaranteed to execute before handling the request.

host.json

This part of your question has a good answer here: https://stackoverflow.com/a/79061613/2325216

References

https://learn.microsoft.com/en-us/azure/azure-functions/dotnet-isolated-in-process-differences https://github.com/Azure/azure-functions-dotnet-worker