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.