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.