La création d’applications est relativement difficile : il y a évidemment la phase de développement, le packaging, la configuration, le provisionnement des serveurs et enfin le déploiement des logiciels. L’ensemble de ces étapes est coûteuse en temps, nécessite des compétences variées et le provisionnement de serveurs coûte cher.
Les architectures sans serveurs (serverless) bouleversent ses différentes étapes en permettant aux équipes de développement de se concentrer sur le code à écrire, de consommer les différents services offerts par le fournisseur Cloud (stockage, bus, Api Gateway,…) et de s’appuyer sur une infrastructure qui va pouvoir s’adapter à la charge. Nous passons donc d’un modèle statique à coûts fixes à un modèle de facturation dynamique qui adapte le prix à l’usage.
Le FaaS (Function As a Service) est un type de service cloud permettant de déployer une fonction unique en serverless. Il permet une configuration très fine et hautement dynamique. Sur le FaaS, le modèle de facturation est basé sur le nombre d’appels de fonctions, la mémoire consommée et sur le temps d’exécution. Les développeurs sont donc incités à créer des fonctions plus petites et de minimiser à la fois leur temps d’exécution et leur consommation mémoire.
Ce type de service cloud divise les microservices traditionnels en parties logicielles plus petites pouvant être exécutées très rapidement. Là où auparavant les microservices étaient composés d’un ensemble de fonctions s’appelant entres elles, ces microservices se retrouvent désormais éclatés en un ensemble de fonctions indépendantes. Utiliser au mieux ces architectures pose également de nouveaux défis sur comment :
- maintenir l’état des applications ?
- composer efficacement des fonctions pour développer des applications complexes ?
- planifier l’exécution des fonctions ?
- surveiller les fonctions et les debugger ?
La nécessité d’un orchestrateur
Ces défis renvoient naturellement vers le choix d’un orchestrateur car plus l’application à réaliser est complexe, plus elle nécessite de fonctions, et donc plus les besoins d’orchestrations se font sentir.
Actuellement, il n’existe ni de standard d’orchestration pour le FasS ni de standard pour les fonctions elles-mêmes.
Les différents fournisseurs de Cloud proposent chacun leur solution d’orchestration (et leur façon d’écrire les fonctions) : les Step Functions pour AWS, les Durable Functions pour Azure et Google Cloud Composer pour GCP. Choisir une solution d’orchestration, c’est donc actuellement faire le choix d’un fournisseur Cloud. On peut citer également un outil de développement haut niveau comme IBM Node-Red qui permet de créer des flux. Cependant, ce type de produit est spécifiquement conçu pour les fonctions IoT. Des outils plus génériques sont nécessaires pour permettre une coordination riche et personnalisée.
Un niveau d’abstraction sophistiqué est nécessaire pour dissimuler la complexité de l’hétérogénéité des processus de développement et de déploiement d’applications. Des outils sont nécessaires non seulement pour simplifier les tâches de découverte et de surveillance des ressources, mais également pour la gestion de bout en bout du cycle de vie.
Pour orchestrer des fonctions plusieurs approches existent. Vous pouvez consulter cette présentation (Serverless-Function-Composition) qui détaille les différentes approches d’orchestrations possibles.
Les modèles d’orchestration XComponent
Chez INVIVOO Software, nous proposons des méthodes d’orchestrations via la création de modèles. Ces modèles présentent notamment l’avantage de découpler fortement le code de la logique d’orchestration. Cela facilite énormément la lisibilité du code et son évolution ainsi que la gestion des erreurs et des « retries ». Nous proposons trois types de modèles :
- Modèles de machines à états
- Ils permettent aux développpeurs de définir la logique métier ou technique de leurs services. La modélisation par machines à états permet d’adresser des problématiques “event driven” avec gestion d’état : par exemple l’état d’avancement d’un ordre sur un marché électronique ou bien le cycle de vie d’une commande sur un site marchand.
- Modèle d’arbres de dépendances
- Ils permettent aux équipes DevOps de déclarer les procédures de redémarrage et de monitoring de leurs applications métiers.
- Modèle de scénarios
- Ils permettent de combiner des services mis à disposition par l’IT. Les scénarios peuvent coordonner des traitements en mode batch ou en streaming tout en incluant des traitements manuels.
Orchestration FaaS via les modèles XComponent
Nous avons souhaité dans un premier temps utiliser les modèles de scénarios pour orchestrer des fonctions FaaS. Ce type de modèle nous a paru approprié pour répondre aux principales problématiques d’orchestration. Les traitements coordonnés par nos solutions peuvent être répartis n’importe où sur le(s) système(s) d’information. En effet, grâce aux modèles de scénarios, nous pouvons, par exemple, orchestrer des Lambdas déployées sur AWS avec des fonctions déployées sur Azure puis exécuter un traitement sur le SI (Système d’Information) interne à l’entreprise (Fig. 3). Notre plateforme XC Koordinator intègre automatiquement à son catalogue des services les fonctions FaaS déployées chez les différents Cloud Providers.
Cette orchestration hautement distribuée est rendue possible via notamment les éléments suivants :
- Un mécanisme de découverte des services intégré à la solution. Ce mécanisme permet une abstraction des services. Ce niveau d’abstraction permet de coordonner tout type de service. C’est ce mécanisme qui permet d’intégrer dynamiquement les lambdas déployées sur AWS. Chaque utilisateur de la solution peut enrichir ce mécanisme.
- Les services intégrés à la plateforme ont les entrées/sorties typées. Cela permet de pouvoir enchainer les traitements facilement tout en pouvant vérifier les compatibilités entre services avant exécution.
Le monitoring et le debugging des exécutions sont aussi facilités par XC Koordinator. Un écran permet de suivre l’exécution des scénarios à chacune des étapes. On peut ainsi :
- Visualiser les entrées/sorties du scénario
- Connaître l’état d’avancement du scénario
- Visualiser les entrées/sorties d’un traitement en particulier
Si certains traitements échouent, les traitements peuvent être redémarrés automatiquement ou bien stoppés au bout d’un certains nombres d’essais.
XC Koordinator propose également des mécanismes de reprises. On peut ainsi redémarrer un scénario en entier ou ne redémarrer que certains traitements.
Toute la complexité de l’infrastructure, de enchaînement des traitements et de la gestion des erreurs est masquée aux utilisateurs de la solution. Nous travaillons également sur l’utilisation de nos modèles de machines à états afin d’orchestrer des fonctions FaaS.
Cette approche est intéressante car le modèle de machines à états est plus riche pour les développeurs que les scénarios: les fonctions peuvent déclencher des transitions depuis le code, il existe des transitions Timeout (qui s’exécutent toutes seules au bout d’un certain temps), des transitions permettant l’allocation de nouvelles machines à états… Le niveau d’abstraction est à la fois très élevé et très riche.
Conclusion
Nous pensons que les modèles sont indispensables pour orchestrer des fonctions de manière optimale. En effet, gérer l’ensemble des appels entre fonctions depuis le code ne nous semble pas viable. On perd en partie certains avantages inhérents au FaaS : comme la scalabilité des fonctions ou bien la facilité de déploiement.
Enfin, un autre intérêt majeur est d’écrire du code « simple ». Pour garder cette simplicité d’écriture du code, il nous semble indispensable de créer des modèles exprimant toute la logique métier et masquant les problématiques inhérentes à l’orchestration.
