Understand Azure Functions Hosting Model: In-Process vs Isolated Model

4 min readAug 17, 2024

Azure Functions offer two primary hosting models: Isolated Process and In-Process. Here’s a real-life example of how both models might be used in a scenario like processing incoming orders in an e-commerce platform.

Scenario: Order Processing System

Imagine an e-commerce platform where orders are placed by customers and need to be processed in various ways: validating payment, sending confirmation emails, updating inventory, etc. The system uses Azure Functions to handle these tasks asynchronously.

1. In-Process Model

The in-process model runs the Azure Functions runtime and your function code within the same process. This allows for tighter integration with ASP.NET Core features but might have limitations in terms of customization and flexibility.

Order Processing Flow:

Function 1: Validate Order (HTTP Trigger)
This function is triggered when a new order is placed (via an HTTP POST request).
It validates the order details (product availability, user authentication, etc.).
If validation is successful, it sends the order to the next function via a Queue output binding.
Function 2: Process Payment (Queue Trigger)
This function is triggered when a new message (order details) appears in the queue.
It processes the payment using an external payment gateway.
If the payment is successful, it sends an order confirmation email by calling another function.
Function 3: Send Confirmation Email (HTTP Trigger)
This function is called by the payment function.
It sends a confirmation email to the customer.
The function logs the successful sending of the email to Application Insights.

Benefits of In-Process:

Tight Integration: Direct access to ASP.NET Core features like dependency injection, middleware, and logging.
Simplicity: Easier to develop and debug, especially if you are familiar with ASP.NET Core.

Drawbacks of In-Process:

Less Customization: Limited in terms of customizing the runtime and managing dependencies.
Potential Version Conflicts: Dependency version conflicts may arise between your code and the Azure Functions runtime.

2. Isolated Process Model

The isolated process model allows your function code to run in a separate process from the Azure Functions runtime. This provides more flexibility and isolation but may require more setup.

Order Processing Flow:

Function 1: Validate Order (HTTP Trigger)
The function runs in an isolated process.
It validates the order details similarly to the in-process example.
Sends the order to the next function via a Queue output binding.
Function 2: Process Payment (Queue Trigger)
Also running in an isolated process.
Processes the payment using an external payment gateway.
If successful, it sends an order confirmation email by invoking another function via an HTTP call.
Function 3: Send Confirmation Email (HTTP Trigger)
Running as an isolated process function, it sends a confirmation email.
Logs the operation into a custom logging framework you’ve integrated into the isolated process.

Benefits of Isolated Process:

Flexibility: Greater control over the runtime environment and dependencies.
Customization: You can run different versions of the .NET runtime and integrate custom middleware.
Isolation: Your function’s dependencies are isolated from the Azure Functions runtime, reducing the risk of conflicts.

Drawbacks of Isolated Process:

Complexity: Requires more setup and configuration, especially for middleware and dependency injection.
Performance Overhead: There may be a slight overhead due to inter-process communication.

Additional Feature: Middleware in Isolated Process

In the isolated process model, you could implement custom middleware to add headers, manage authentication, or log additional details across all HTTP functions.

Choosing Between In-Process and Isolated Process

In-Process is typically easier to get started with and offers tighter integration with ASP.NET Core features, making it suitable for most common use cases where simplicity and performance are key.
Isolated Process is better suited for scenarios where you need greater flexibility, customization, or isolation from the Azure Functions runtime. It’s particularly useful if you want to avoid version conflicts or need to integrate custom middleware and other ASP.NET Core features more deeply.

Example Code

Here’s a simplified example of an Azure Function in the Isolated Process model:

using Microsoft.Azure.Functions.Worker;
using Microsoft.Azure.Functions.Worker.Http;
using Microsoft.Extensions.Logging;
using System.Threading.Tasks;
public class OrderFunction
{
 private readonly ILogger<OrderFunction> _logger;
public OrderFunction(ILogger<OrderFunction> logger)
 {
 _logger = logger;
 }
[Function("ValidateOrder")]
 public async Task<HttpResponseData> ValidateOrder(
 [HttpTrigger(AuthorizationLevel.Function, "post")] HttpRequestData req)
 {
 _logger.LogInformation("Validating order…");
// Order validation logic here
var response = req.CreateResponse(System.Net.HttpStatusCode.OK);
 await response.WriteStringAsync("Order validated successfully.");
return response;
 }
}

And for In-Process:

using Microsoft.Azure.WebJobs;
using Microsoft.AspNetCore.Mvc;
using Microsoft.Extensions.Logging;
using System.Threading.Tasks;

public static class OrderFunction
{
    [FunctionName("ValidateOrder")]
    public static async Task<IActionResult> ValidateOrder(
        [HttpTrigger(AuthorizationLevel.Function, "post")] HttpRequest req,
        ILogger log)
    {
        log.LogInformation("Validating order...");

        // Order validation logic here

        return new OkObjectResult("Order validated successfully.");
    }
}

Both examples represent simple HTTP-triggered functions, but in real-world applications, you would typically include more complex logic for handling queues, managing state, and integrating with other Azure services.