Function as a Service (FaaS)

Le Serverless Computing ou Function as a Service (FaaS) est un modèle établi pour la première fois en 2014 par Amazon Web Services pour la création et l'exécution d'applications dans le cloud. La part croissante des traitements transactionnels dans la communication client des entreprises rend ce modèle particulièrement intéressant à mettre en œuvre. Le Serverless Computing permet en effet d’accompagner une transformation majeure de la communication client ces dernières années. Les tâches de communication standardisées par lot, comme l’envoi de centaines de milliers de documents, relevés de comptes, appels de cotisations, etc… avant une date limite, ne représentent déjà plus la majorité des communications d’entreprise. De plus en plus, ces dernières sont à la fois plus personnalisées dans ce qu’elles contiennent et ce qui les déclenche, et aussi pour ce qui concerne les canaux de communication qu’elles empruntent.

Les infrastructures de communication des entreprises se doivent donc d’être plus flexibles et plus réactives. Elles doivent permettre de prendre en compte les préférences de communication des clients mais aussi les règles métier ou les conventions propres à chaque type de document. Ainsi, un relevé de compte pourra sans doute être présenté sur téléphone mobile ou sur tablette tandis qu’il restera préférable de transformer un contrat en document PDF.

« Small is beautiful », et surtout moins cher …

Durant son cycle de vie, un document fait l’objet d’une grande variété de traitements, qui sont autant de tâches ou fonctionnalités de l’infrastructure de communication. Mais toutes ces tâches ne sont pas exécutées à la même fréquence ou avec la même régularité. Les applications nécessaires à l’exécution de ces tâches ne sont en réalité nécessaires qu’à certains moments et pour une durée souvent limitée. Prenons l’exemple de l’harmonisation et de la migration d’archives à la suite d’une fusion-acquisition ou dans le cadre d’un projet de réduction de l’hétérogénéité des SI. L’opération de regroupement des archives en formats propriétaires et leur conversion vers le format PDF/A ne s’effectuera qu’une seule fois. Et si l’acquisition d’un logiciel spécialisé pour cette tâche paraît la réponse la plus simple, ce n’est certainement pas la plus économique, sachant qu’il faudra assurer la maintenance de ce logiciel jusqu’à ce qu’une éventuelle autre opération de réorganisation nécessite à nouveau son usage.

Cet exemple montre bien comment le Serverless Computing va permettre d’économiser des ressources précieuses pour l’entreprise. Dans un modèle FaaS, ces ressources, qu’elles soient techniques ou humaines, évoluent strictement avec le travail à effectuer grâce à un microservice qui est appelé chaque fois qu’un document est à convertir. Cela signifie que lorsqu’il n’y a rien à convertir, le service est purement et simplement inerte, ne consommant ni capacités de calcul, ni espace de stockage. Tout l’intérêt de cette démarche est que ce qui vaut pour les traitements par lot en backoffice fonctionne tout aussi bien pour les fonctionnalités de front office liés à l’expérience client.

FaaS, microservice et Cloud

Prenons en second exemple un opérateur de télécommunications qui souhaite offrir à ses clients la possibilité de générer une facture détaillée « à la demande ». Sur le papier, l’idée est intéressante car elle évite de « gâcher » des ressources en générant des factures détaillées en sachant que les clients qui en font vraiment la demande ne représentent qu’un faible pourcentage de la clientèle globale. Pour que cela soit possible, il faut pouvoir activer à la demande la fonctionnalité, et cela sans devoir surajouter une couche logicielle spécifique et donc des coûts et de la complexité du système d’information.

C’est précisément ce que permet la plateforme d’automatisation des processus de communication client DocBridge® Gear. Grâce à une architecture d’interfaces ouvertes « API First », DocBridge® Gear facilite l’assemblage via une interface graphique de fonctions unitaires FaaS qui vont constituer les briques élémentaires du service demandé. Ainsi, on trouvera par exemple une fonction pour extraire les coordonnées du client depuis une base de données à partir d’un identifiant, de même pour les données de facturation elles-mêmes, tandis qu’un autre microservice totalement autonome se chargera d’une opération de conservation ou de formatage, ou de la production du document électronique ou de l’imprimé à partir d’un même flux documentaire…

L’un des intérêts de la conception de processus documentaires par assemblage de fonctions unitaires autonomes en microservices (FaaS) réside dans le fait que tous les scénarios deviennent alors possibles, et toujours dans un environnement serverless, sans devoir supporter les contraintes techniques et les coûts de multiples serveurs. Il suffit de penser aux opérations classiques comme le formatage (création) et la conversion de documents, à l'intégration sortante (connexion aux interfaces des canaux de communication correspondants comme le courrier, les SMS, la messagerie, le portail client, les archives, le spooler d'impression, etc.) ou à l'intégration de processus techniques au sein de workflows commerciaux (AWS Step Functions, Azure Logic Apps, etc.).

L’approche FaaS s’applique par conséquent autant aux chaînes de fonctionnalités purement métier (business workflows) qu’aux fonctions techniques qui forment les processus documentaires. Dans les deux cas, c’est la possibilité d’assemblage via une interface graphique, offerte par des solutions Cloud comme DocBridge® Gear, qui joue un rôle déterminant pour rendre plus simple et plus accessible l’automatisation des processus, par rapport aux outils traditionnels d’automatisation (BPM, BPA).

Zéro code ou presque

L’important ici est que la construction de cette chaîne logique de fonctions unitaires s’effectue majoritairement sinon totalement sans devoir écrire une ligne de code. Grâce à l’architecture « API First », chaque fonction unitaire peut être représentée graphiquement avec les connecteurs, en entrée et en sortie, qui permettent de l’utiliser. Depuis plusieurs années, Compart a travaillé à la mise à disposition des fonctions unitaires de production documentaire dans les principaux environnements serverless du marché, proposés par les fournisseurs Cloud, y compris Knative. Les clients Compart sont de plus en plus nombreux à se saisir de ces possibilités pour concevoir, avec DocBridge® Gear, de nouveaux processus de communication client ou de production documentaire, sans écrire une ligne de code ou presque.

DocBridge® Gear permet en effet d’assembler graphiquement des fonctions unitaires pour composer un « worklet », une chaîne logique de fonctions, qui peut ensuite entre emballée dans un conteneur et mise à disposition à son tour sur une plateforme serverless comme une fonction de plus haut niveau. L’entreprise dispose ainsi de toute la liberté pour concevoir ses propres processus et sous-processus de traitement à partir de fonctions unitaires, tout cela sans écrire une ligne de code ou presque, et sans devoir héberger et maintenir une application conçue spécifiquement.

L’approche FaaS, pour quels usages ?

Comme toute les avancées technologiques qui concernent l’architecture des systèmes d’information, l’approche FaaS ne s’applique pas dans tous les cas de figure. Cela n’enlève rien au fait que cette approche sera probablement l’une des évolutions majeures, dans un avenir proche, de la communication client omnicanale. Les FaaS sont des fonctions granulaires et dédiées. Elles sont spécialement conçues pour effectuer des tâches métier simples, sur une durée limitée, et majoritairement au fil de l’eau. Plus une entreprise veut proposer des services simples à la demande et personnaliser la communication au travers de tâches simples, plus le modèle FaaS devient attractif. En revanche, il restera vraisemblablement inadapté à l’exécution de processus complexes, de traitements massifs ou d’opérations statiques (stateful).

Une seconde question est celle du dimensionnement. Par rapport au service rendu, l’entreprise peut trouver que le coût d’accès à une fonctionnalité en FaaS est relativement élevé. Pour pondérer cette première impression, il faut toutefois garder à l’esprit que d’une part, l’entreprise ne paiera que pour l’utilisation effective, le fournisseur de service Cloud se chargeant de maintenir en conditions opérationnelle toute l’infrastructure et les ressources nécessaires à cette fonctionnalité. Dans la pratique, il faut comparer ce qui est comparable, c’est-à-dire le coût complet d’accès à la fonctionnalité si celle-ci était développée, maintenue et hébergée en interne et par les équipes SI de l’entreprise.

La troisième objection souvent soulevée concernant le modèle FaaS tient au manque de contrôle ou de visibilité sur l’infrastructure sous-jacente, celle-ci étant effectivement gérée par le fournisseur Cloud. Des optimisations ou des options particulières, quelques fois absolument nécessaires, peuvent se révéler particulièrement coûteuses à mettre en œuvre. Par ailleurs, chaque environnement serverless impose ses propres règles. Ce qui signifie que les fonctions unitaires ou les chaînes logiques de fonctions créés dans un environnement serverless spécifiques ne fonctionneront que dans celui-ci. Les alternatives à cette relation de dépendance (« Cloud Lock-In ») commencent cependant à émerger sous la forme de plateformes neutres, comme Knative. Les plateformes neutres offrent les mêmes avantages qu’un environnement FaaS, mais elles reposent sur une architecture hybride multi-cloud et une orchestration autogérée pour offrir plus d’indépendance.