Cos’è l’isolated worker model

In Azure Functions, il codice .NET può essere ospitato in due modi. Con il modello in-process la funzione girava caricata come libreria all’interno dello stesso processo dell’host (il Functions host runtime, basato su Azure WebJobs). Con l’isolated worker model la tua funzione viene eseguita in un processo .NET separato dall’host: l’host resta il coordinatore del runtime, mentre il tuo codice vive in un worker console app autonomo che comunica con l’host tramite un canale RPC.

Questa separazione è la ragione architetturale di tutti i vantaggi del modello:

  • Disaccoppiamento delle versioni .NET: il worker può usare una versione di .NET diversa da quella dell’host. Puoi girare su .NET 8/9 LTS o su versioni non-LTS senza attendere l’allineamento del runtime host. È l’unico modo per usare release che l’host non supporta nativamente.
  • Controllo completo dello startup: hai un tuo Program.cs con Main, quindi decidi tu la configurazione dell’app, il logging e la dependency injection.
  • Middleware pipeline: puoi registrare middleware personalizzati che intercettano l’esecuzione (auth, logging, exception handling, arricchimento del contesto).
  • Meno conflitti di assembly: non condividendo il processo con l’host, si riducono i conflitti sulle dipendenze (es. versioni diverse della stessa libreria).

Program.cs: come cambia

Nel modello isolated l’entry point è esplicito. Si costruisce l’host con il builder dedicato e si registrano i servizi:

var builder = FunctionsApplication.CreateBuilder(args);
builder.ConfigureFunctionsWebApplication(); // integrazione ASP.NET Core per HTTP
builder.Services.AddSingleton<IMyService, MyService>();
builder.Build().Run();

Il metodo ConfigureFunctionsWebApplication() abilita l’integrazione con ASP.NET Core, permettendo ai trigger HTTP di usare i tipi nativi HttpRequest/IActionResult invece dei tipi custom HttpRequestData/HttpResponseData. È una scelta architetturale: ASP.NET Core integration per un’esperienza più familiare e middleware ASP.NET, oppure il modello a HttpRequestData più leggero e portabile. Nel modello in-process, invece, non esisteva un Program.cs di questo tipo: la DI si configurava con una classe Startup marcata da FunctionsStartup.

Cosa cambia nei binding e nei tipi restituiti

Qui sta il cuore delle differenze pratiche. I due modelli non condividono gli stessi tipi:

  • Trigger HTTP: in-process usava HttpRequest + IActionResult. Isolated usa HttpRequestData + HttpResponseData (oppure i tipi ASP.NET Core se abiliti l’integrazione).
  • Output binding multipli: nel modello isolated, per restituire sia un valore HTTP sia scrivere su un output binding (es. una queue), si usano i multiple output bindings tramite una classe POCO con proprietà attributate, non più i parametri out o IAsyncCollector tipici dell’in-process.
  • Namespace degli attributi: gli attributi di trigger/binding vivono in package e namespace diversi (Microsoft.Azure.Functions.Worker.* per isolated vs Microsoft.Azure.WebJobs.* per in-process).
  • Logging: si inietta ILogger<T> via costruttore anziché riceverlo come parametro del metodo.

In-process vs isolated: quale scegliere

Per qualsiasi nuovo sviluppo la risposta d’esame è sempre isolated worker model. Il modello in-process è deprecato: il supporto termina a novembre 2026, e Microsoft raccomanda la migrazione. L’isolated è l’unico modello con roadmap futura e l’unico che disaccoppia la versione .NET dall’host.

La scelta tra ASP.NET Core integration e i tipi HttpRequestData dipende dallo scenario: la prima se vuoi middleware ASP.NET e modelli familiari; la seconda per un footprint minimo o massima portabilità.

Trappole tipiche d’esame

  • Scenario: devi usare una versione di .NET che l’host Functions non supporta ancora → risposta giusta: isolated worker model (disaccoppia la versione .NET del worker da quella dell’host); l’in-process ti vincola alla versione dell’host.
  • Scenario: nuovo progetto Functions in .NET nel 2026 e ti viene proposto l’in-process → risposta giusta: scartalo, è deprecato con fine supporto a novembre 2026; scegli isolated.
  • Scenario: migri una function app da in-process a isolated e riusi HttpRequest/IActionResult e i parametri out tal quali → risposta giusta: sbagliato, i tipi di binding differiscono (HttpRequestData/HttpResponseData o ASP.NET Core integration, output multipli via POCO); vanno riscritti, non copiati.
  • Scenario: ti serve registrare un middleware custom o configurare la DI con pieno controllo dello startup → risposta giusta: isolated worker model con Program.cs; l’in-process non offre una pipeline di middleware.
  • Scenario: vuoi restituire una risposta HTTP e contemporaneamente scrivere su una queue in isolated → risposta giusta: usa i multiple output bindings con una classe POCO attributata, non IAsyncCollector o parametri out.