Accueil Nos publications Blog Function as a Service (FaaS), obtenez le meilleur du Cloud

Function as a Service (FaaS), obtenez le meilleur du Cloud

Vignette-article-Function-as-a-Service

Function as a Service (FaaS), est une fonctionnalité de Cloud computing fournie par les Cloud providers. Elle permet l’exécution de code, sans se soucier de la prise en charge de l’infrastructure sous-jacente. Définition, fonctionnement et exemples concrets, on décrypte :


Function as a Service : qu’est-ce que c’est ?

Le concept de FaaS, Function as a Service, est une fonctionnalité de Cloud computing fournie par les Cloud providers. Elle permet l’exécution de code, sans se soucier de la prise en charge de l’infrastructure sous-jacente.

Cette fonctionnalité est exploitée dans de nombreux cas d’usage. Elle est particulièrement adaptée lorsque l’on souhaite customiser et enrichir une feature Cloud pour un usage spécifique. Elle répond également aux exigences des applications EDA (Event Driven Applications).

Concrètement, il s’agit de déclencher des actions, courtes, décrites par du code, à des moments particuliers et choisis pour répondre à un besoin très spécifique.

Les Cloud providers (AWS Lambda, Azure Functions, GCP Cloud Functions pour les trois principaux), proposent sensiblement le même service avec des nuances de limitations et de configurations.

Fonctionnement d’une FaaS

Lorsque vous configurez une Function as a Service, il faut toutefois faire quelques choix :

  • Sélectionner le runtime dans lequel vous allez exécuter le code que vous avez développé 
  • Spécifier les événements déclencheurs des fonctions
  • Choisir des quotas de ressources
  • Appliquer des droits d’exécution

Vous pouvez ajouter une connectivité réseau si besoin, mais c’est optionnel, selon la nécessité d’accéder à d’autres ressources ou non. Il est aussi possible d’interfacer les FaaS avec des outils de gestion de secrets. Ces choix peuvent cependant impacter le coût global de son exécution.

Les déclencheurs sont très variés, il est donc possible de déclencher une FaaS sur à peu près n’importe quel évènement. Vous pouvez presque considérer que vous pouvez déclencher une FaaS avec n’importe quel appel API cloud généré : c’est une sorte de hook sur un évènement Cloud. Il est possible de faire tourner le code en simultané.

Les runtimes diffèrent d’un Cloud provider à l’autre, certains sont plus riches que d’autres :

Lorsque le trigger est déclenché, le code est exécuté et le Cloud provider soumet au paiement les ressources pendant le temps d’usage du FaaS. C’est un moyen très économique de disposer de ressources de computing dans un contexte très précis.
Vous n’avez pas à vous soucier de la réservation des ressources, de la maintenance de l’OS, ni même des mises à jour des runtimes : le Cloud provider le fait à votre place.
Une Function as a Service possède ses métriques et ses logs, vous pouvez donc les intégrer à une supervision comme n’importe quel service.

Pour mieux comprendre le déploiement d’un modèle FaaS, prenons 3 exemples concrets :

Exemple 1 : L’accidentologie de votre SI transmise aux équipes build directement dans Slack ? C’est possible.

Dans ce premier exemple, nous avons mis en place un outil de génération de rapports d’incidents par connexion API Rest.

Le contexte :

L’application Pager Duty permet de réaliser des reports d’alertes vers des équipes d’astreinte intervenant en run en 24/7. L’équipe build, qui n’a pas accès à Pager Duty, souhaite recevoir – dans un channel Slack, tous les matins – un résumé des alertes survenues pendant la nuit.

Slack permet d’intégrer les alertes Pager Duty, seulement ici, il s’agit de réaliser un résumé customisé pour les besoins de l’équipe. AWS Lambda permet de remplir cette fonction. 

La solution :

Un code Python déclenché chaque matin, se connecte via l’interface API Rest de Pager Duty en utilisant le couple API Key/Secret Key stocké dans AWS Secret Manager. Les données collectées, sous format Json, sont agrégées, transformées et synthétisées dans un bloc de texte transcrit en Json au format correspondant aux spécifidactions des Webhook Slack. Tous les matins, les builders accèdent désormais au résumé de la nuit d’astreinte.

Les avantages :

Le coût lié à cette fonctionnalité est marginal (un appel Lambda par jour !). Cependant, la valeur ajoutée pour la réalisation de KPI est particulièrement intéressante. 

Le retour sur investissement est très avantageux dès lors que l’on souhaite disposer d’un mécanisme de facturation à la demande, qui possède un temps de boot très faible et qui puisse répondre facilement à un besoin de scalabilité variable.

Exemple 2 : Votre site e-leaning en mode serverless ? Payez à la requête… ou presque !

Le contexte :

Un site web de e-learning propose de consulter des cours vidéo. Ces ressources, statiques, sont stockées sur un bucket AWS S3. Un utilisateur doit cependant pouvoir créer un compte, se connecter, interagir avec ses données, répondre à des quizz et obtenir un certificat d’achèvement d’un cours, ou visualiser sa progression d’apprentissage.

Une partie du site est statique : les cours en vidéo. Une autre qui est dynamique : la gestion des comptes, la facturation et l’évaluation des connaissances.

Il est possible d’héberger facilement un site statique chez un Cloud provider, sans pour autant déployer de ressources nécessitant du run (par exemple AWS CloudFront + AWS S3). Cependant, la prise en charge de la partie dynamique n’est pas mise en œuvre de cette façon.

La solution :

Tout ce qui n’est pas statique peut être réalisé par une fonction Lambda, codée en Pyhton, qui exécute à la demande les actions nécessaires (connexion à la base de données, réalisation de calculs, présentation d’une page dynamique, envoi d’un mail avec un fichier personnalisé…).

AWS CloudFront permet de répartir les requêtes en fonction de leur contenu, vers des destinations de traitement différentes. Par exemple, le trafic statique (toutes les pages /video/*) sont hébergées sur S3. Le reste du trafic est redirigé vers un AWS API Gateway, qui invoque des FaaS en fonction de la page dynamique à adresser. La Lambda function peut ainsi se connecter à une base de données ou à des ressources de calcul.

Les avantages :

Chaque requête dynamique est facturée au temps d’exécution. Aucune infrastructure particulière n’est requise pour héberger les frontends, gérer le scaling etc. Tout est réalisé via la Lambda pour la partie site dynamique.

Cela peut s’avérer très intéressant, notamment pour un site web dont la partie dynamique ne nécessite pas de traitements colossaux, mais qui répond à de nombreuses requêtes simultanées. Particulièrement, lorsque le site a un ramp up du nombre d’utilisateurs peu prévisible.

Exemple 3 : Serveur de batchs Java non optimisés ? Devenez serverless addict.

Notre dernier exemple traite de l’utilisation d’une FaaS dans le cadre d’une migration vers le Cloud et de la transformation d’un serveur de batchs Java.

Le contexte :

Une entreprise de vente en ligne a besoin de mettre à jour son catalogue d’articles et présenter un état des stocks pour des familles de produits. Ces collectes sont faites historiquement par des des batch jobs Java. Ces-derniers, extraient périodiquement, une partie des données de la base de production contenant les commandes en cours et passées, afin de présenter des résultats de vente et mettre à jour le site web. Le but est de décorréler au maximum la connexion aux bases de production et les informations présentées sur le site : pas d’appel direct en base depuis le site web. Il n’y a pas besoin de connaître les informations en temps réel, mais simplement de présenter des données journalièrement.

  • Le serveur de batch réalise des traitements, limités dans le temps et produit des résultats au format Json, exportés via une requête HTTP ou un stockage distant.
  • Les batchs concernés peuvent exécuter des requêtes (SQL ou pas) sur une ou plusieurs bases de données présentes dans l’infra.
  • La fin d’un batch peut en déclencher un autre. Les batchs peuvent être concurrentiels.

La solution :

Les batchs n’occupent pas le serveur en permanence. Plutôt que de migrer ce serveur de batch en mode lift & shift, une solution de transformation consiste à porter les batchs vers des Lambda Functions AWS. C’est possible, dès lors qu’ils remplissent certains prérequis en termes de durée d’exécution, de consommation de ressources et qu’ils prennent en charge un runtime mis à disposition par le Cloud provider.

Les avantages :

Le gain du coût d’exécution est immédiat. La maintenance du serveur de batch n’est plus nécessaire, tout est pris en charge par les Lambdas. De multiples déclencheurs étant disponibles, une multitude de combinaisons d’ordonnancement des batchs est possible.

À noter cependant, pour le traitement en masse de batchs, qu’un autre service existe chez AWS : AWS Batch. Privilégier son utilisation, plutôt que AWS Lambda, dépend de l’usage et des déclencheurs que vous souhaitez utiliser.

Les inconvénients et les avantages du FaaS :

Les inconvénients :

  • Les ressources sont limitées (mémoire, durée),
  • Les runtimes ne prennent en charge que les langages les plus courants. Ils ne sont pas les mêmes d’un Cloud provider à l’autre,
  • Les versions de runtime évoluent. Il peut être nécessaire de mettre en conformité son code en fonction de la dépréciation de versions de runtimes (par exemple, Python 2.7 n’est plus supporté).
  • FaaS = stateless, c’est-à-dire qu’il n’y a pas de solution directe de stockage de données. Cet inconvénient se contourne en réalisant des requêtes de lecture/écriture en base de données ou encore des écritures sur un stockage de fichier partagé.

Les avantages :

  • Une mise en œuvre simple,
  • Un accès aux ressources de computing permettant de se focaliser sur le code, et non sur les ressources sous-jacentes,
  • Une gestion déléguée : le Cloud Provider se charge de mettre à disposition ces fonctionnalités pendant le temps nécessaire et d’en assurer la disponibilité, la maintenance et la sécurité,
  • Une solution peu coûteuse au regard de l’effort à réaliser pour déployer et maintenir une infrastructure complète pour des besoins très ponctuels,
  • Une fonctionnalité qui s’adapte à beaucoup de langages courants de programmation.

Pour résumer, l’utilisation des FaaS répond à de nombreuses problématiques dès lors que le besoin peut se traduire par l’exécution de code à la demande, de façon relativement fréquente, scalable, facturé à l’usage et pour une durée courte. Le use case le plus classique est la réalisation d’une action lorsqu’une ressource Cloud reçoit un événement ou génère un changement d’état d’une autre ressource Cloud.