Aller au contenu
Home » Blog » Azure Functions : In-process vs Out-of-process

Azure Functions : In-process vs Out-of-process

Lorsque vous créez des fonctions Azure en utilisant .NET et le langage C#, vous avez le choix entre deux modes pour exécuter vos applications : il s’agit des modes In-process et Out-of-process.

Le choix de l’un ou l’autre de ces modes peut avoir des impacts non négligeables sur la qualité du code de vos fonctions, l’intégration avec d’autres composants, la flexibilité dans la mise en place et sur comment vos fonctions vont s’exécuter dans Azure.

Avant de vous dire quel mode vous devriez prioriser, je vais commencer par vous présenter chaque mode et leurs avantages et inconvénients.

In-process

Le mode In-process existe depuis la première version du runtime Azure Functions (Functions 1.0). Cette version était initialement basée sur .Net Framework 4.8. Donc on n’avait pas de support de .NET Core qui était à sa version 1.x.

Potentiellement à cause des enjeux liés à .NET Framework qui, faut l’avoir, n’était pas bâti sur des principes comme la modularité ou encore l’injection de dépendances, chers à .NET Core, les fonctions Azure étaient développées sous forme de bibliothèque de classes.

Concrètement, lorsque vous créez une application de fonctions en utilisant ce mode, le projet C# créé est une application de type « bibliothèque de classes. Vous avez dans ce projet :

  • Un fichier .csproj qui est le fichier de projet
  • Un fichier host.json  qui stocke les paramètres de configuration de l’environnement d’exécution des fonctions de cette application
  • Un fichier local.settings.json qui stocke les paramètres de l’application et les chaines de connexion utilisés au cours d’une exécution locale.
  • Un ou plusieurs fichiers .cs contenant le code des fonctions. Dans chaque fichier de fonction, on va trouver une méthode statique dont le code sera déclenché selon un certain évènement.

Compte tenu du fait que le projet est une bibliothèque de classes, nous n’avons donc pas de program.cs ou de startup.cs. De ce fait notre fonction est étroitement intégrée avec son environnement d’exécution dans Azure. L’avantage de cette approche est le fait que les fonctions pourront partager des APIs et des types de liaison.  Mais, ce couplage fort fait en sorte que :

  • les fonctions doivent s’exécuter sur la même version .NET que le runtime Azure Functions.
  • Pas de prise en charge native de l’injection de dépendances. Il est toutefois possible de mettre cela en place, mais vous devez passer par un modèle d’injection de dépendances personnalisé qui demande un certain effort de mise en place
  • Aucune prise en charge des intergiciels
  • Pas de contrôle au niveau du processus (démarrage de l’application, configuration d’intergiciel, etc.).
  • Moins de flexibilité : vous devez utiliser les mêmes versions d’assemblys que le processus hôte.

Out-of-process (Isolé)

Le mode hors processus a été introduit avec le runtime Azure Functions 3.x. Cette version du runtime supporte .NET 5.0 et .NET 3.1. Mais le mode hors processus est uniquement disponible à partir de .NET 5.0.

Ce mode permet désormais de créer et exécuter des fonctions C# dans le processus isolé, comme cela est le cas pour JavaScript, PowerShell, etc. Il faut noter que les applications de fonctions créées avec les autres langages supportées par Azure Functions s’exécutent en mode hors processus.

Lorsque vous créez une application de fonctions en utilisant le mode isolé, vous pouvez remarquer la présence du fichier Program.cs dans le projet :

Avec ce mode, nous avons un contrôle total du processus : vous contrôlez le démarrage de l’application, ainsi que les configurations utilisées et l’intergiciel démarré.

La mise en place de l’injection de dépendances est très simplifiée. Étant donné que vous contrôlez totalement le processus, vous pouvez utiliser les comportements .NET actuels pour injecter des dépendances et incorporer l’intergiciel dans votre application de fonctions.

Par ailleurs, ce mode offre moins de conflits : les fonctions s’exécutant dans un processus distinct, les assemblys utilisées dans votre application ne sont pas en conflit avec une version différente des mêmes assemblys utilisées par le processus hôte.

Pourquoi devriez vous créer vos fonctions en utilisant le mode hors processus

Comme vous avez pu le constater, le mode hors processus apporte de nombreux avantages et permet de se conformer à l’approche utilisée dans les autres langages de programmation.

Selon la feuille de route d’Azure Functions, Microsoft compte ne plus offrir le mode In-proccess à partir de la version 7 de .NET qui sortira cette année. Et le mode ne sera plus supporté à la sortie de .NET 8 en 2023. Cette version permettra donc de programmer la fin du support de .NET 6.

Il faut noter toutefois que la création des fonctions durables n’est pas encore possible en mode hors processus. La fonctionnalité sera offerte avec .NET 7.

Étiquettes:

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *