Fonctions en tant que Service (FaaS) fait partie du paradigme X-en-tant-que-service, qui couvre la délégation de la gestion des plateformes (PaaS), des infrastructures (IaaS) ou des logiciels (SaaS) à un fournisseur cloud. Cela permet aux entreprises de se concentrer sur leur logique métier et de réduire les coûts généraux.

L'idée derrière FaaS est que vous écrivez du code pour accomplir des tâches simples, et le fournisseur cloud s'occupe du reste. Bien sûr, ce que signifie « simple » dans ce contexte est subjectif, et le fournisseur imposera certaines limites à ce que votre code peut réellement faire. Fondamentalement, il ne doit pas consommer beaucoup de mémoire et ne peut pas fonctionner pendant des temps arbitrairement longs.

Les avantages d'utiliser FaaS plutôt que d'exécuter le code dans une machine virtuelle sont :

• Vous n'avez pas à gérer l'infrastructure, ce qui est déjà un grand avantage.

• Les événements déclenchent le code, simplifiant le développement logiciel.

• En cas de pic d'activité, la mise à l'échelle du code est automatique, avec des fonctions s'exécutant en parallèle selon les besoins.

• Le fournisseur cloud vous facture pour ce que vous utilisez. Le prix comporte deux composantes : le temps pendant lequel votre fonction s'exécute, et la quantité de mémoire que vous allouez pour que votre code fonctionne. Il n'y a pas de coûts supplémentaires pour les licences, la gestion des systèmes, la maintenance, le support.

Ces caractéristiques font de FaaS un excellent outil pour les tâches où la demande de travail n'est pas constante dans le temps, par exemple, des travaux « en pointe » nécessitant beaucoup de ressources pendant une courte période. Si vous avez besoin que votre code fonctionne 24/7, ou avec des temps d'inactivité courts, FaaS ne devrait pas être votre choix. Cependant, pour des tâches simples qui ne doivent être exécutées qu'occasionnellement, FaaS est la solution idéale. En utilisant les services d'informatique sans serveur, vous allégerez vos maux de tête et de portefeuille en vous dispensant de la maintenance et du paiement d'infrastructures sous-utilisées.

Le cas d'utilisation avec AWS

Chez Agilytic, nous avons récemment eu l'opportunité de travailler sur un projet où nous avons construit une architecture sans serveur en utilisant les Lambda Functions d'Amazon Web Services (AWS) (FaaS dans la nomenclature AWS), parmi d'autres services cloud. L'objectif du projet était la collecte et la classification de documents, selon leur contenu, en exploitant différentes techniques : de la reconnaissance optique de caractères à la synthèse de texte. Récemment, nous avons également publié un article sur l'utilisation de l'Application Fonction avec Azure pour construire des solutions de charge de travail intensive.

Nous avons décidé d'utiliser des fonctions Lambda spécialisées dans différentes sous-tâches de ce processus et d'interagir avec le stockage S3 et une base de données pour notre preuve de concept. AWS connecte ces Lambdas séquentiellement, chacune prenant la sortie de la précédente pour accomplir sa tâche. Dans cet article, nous souhaitons partager notre expertise sur l'orchestration des fonctions Lambda.

Nous supposons que vous savez déjà comment créer des fonctions Lambda et gérer les rôles et politiques IAM. Pour être concret, nous simplifierons l'architecture que nous utilisons et connecterons certaines fonctions Lambda, où chacune dépend de la sortie de la précédente pour pouvoir accomplir sa tâche spécialisée.

Nous utilisons la console AWS pour illustrer les différents thèmes de l'article, tandis que, pour le client, nous avons déployé toute l'architecture en tant qu'infrastructure en tant que code, en utilisant terraform. L'utilisation de la console prend en charge automatiquement la création de rôles et, dans une certaine mesure, accorde des permissions. C'est bon pour un déploiement rapide mais mauvais pour la sécurité, ce que nous abordons dans la partie 2 de cet article.

Orchestration de fonctions avec AWS

Figure 1 : Vue d'ensemble de la fonction Lambda

Donc, vous avez le code de votre première fonction Lambda et vous envisagez maintenant de la déclencher, peut-être pour exécuter un test ou commencer votre pipeline. Que faire? Commençons par les bases et supposons que vous exécutez un test. La première option ici pour vous est d'aller sur la console AWS et d'ouvrir la vue d'ensemble de votre fonction Lambda, qui devrait ressembler à quelque chose comme la Figure 1.

Dans cette figure, vous voyez, souligné en jaune, le bouton de test. Cela vous permettra de créer un événement personnalisé pour déclencher votre fonction. Facile. Si votre code nécessite un événement avec une clé ‘file’ et une valeur ‘path’, vous pouvez facilement l'écrire dans l'extrait de test, comme montré dans la Figure 2. Si au contraire, votre code attend un événement d'un autre service dans AWS, ne craignez rien : il existe de nombreux modèles disponibles parmi lesquels vous pouvez choisir.

Figure 2 : Événement de test

Après avoir exécuté le test, vous pourrez lire les journaux avec le résultat de l'invocation de votre fonction Lambda, vous indiquant si elle a réussi ou non. Dans le cas contraire, il indiquera la première erreur rencontrée, débutant ainsi la tâche de débogage.

Cet article ne porte pourtant pas sur le débogage de vos Lambdas, mais sur la façon de les faire communiquer entre elles. Alors, passons en revue ce qui s'est passé ici. En gros, AWS a nourri le JSON que vous avez créé avec votre test dans l'argument event de la fonction lambda_handler dans la Figure 1 (souligné en bleu). C'est ainsi que les événements déclenchent la fonction Lambda.

La leçon est claire : la façon de démarrer une Lambda est de lui fournir l'événement JSON (correctement formaté). Le runtime convertit automatiquement le JSON en un objet que votre code de programmation comprend.

Déclencher automatiquement une fonction Lambda

Ainsi, AWS a fourni cette méthode facile pour démarrer manuellement le travail d'une fonction sans serveur mais soyons honnêtes, combien de cas d'utilisation vous permettent d'aller à la console AWS chaque fois que vous avez besoin que votre pipeline démarre, et de configurer un déclencheur manuel avec la bonne structure ? Vous pourriez avoir besoin d'une méthode pour démarrer automatiquement les travaux, et généralement, dans l'un des deux cas :

1. Déclenchez une Lambda périodiquement.

2. Déclenchez une Lambda en réponse à quelque chose qui s'est produit dans le cloud.

Les ingénieurs d'AWS ont également pensé à cela et ont mis en place un moyen pour que certains services AWS envoient des événements à vos fonctions Lambda. Pour déclencher périodiquement une Lambda dans AWS, vous définissez une règle AWS Cloudwatch sous « événements » (nous savons, ce mot apparaît beaucoup trop souvent dans cet article) dans la console AWS et sélectionnez votre Lambda souhaitée comme cible de cet, encore, événement, comme dans la Figure 3.

Figure 3 : Configuration d'un événement périodique

Pour les autres utilisations, il existe un moyen plus centralisé de le faire. Dans la console AWS, dans la page de configuration de la Lambda (voir Figure 4), vous pouvez sélectionner le service à partir duquel vous souhaitez que votre Lambda soit déclenchée et suivre les instructions pour configurer l'événement (au moment de la rédaction, vous pouvez choisir entre 16 services AWS et de nombreux services partenaires). N'oubliez jamais de vérifier le modèle d'événement pour écrire le code correct ! (Rappel : vous pouvez les trouver dans la partie surlignée en jaune de la Figure 1).

Déclencher une deuxième Lambda depuis la première avec AWS

C'est génial ! Vous avez appris à déclencher périodiquement ou par événement votre fonction Lambda. Maintenant, comment déclenchez-vous une deuxième fonction ? Une Lambda peut-elle déclencher une Lambda ?

Si vous cliquez à nouveau sur le bouton ‘Add trigger’ de la Figure 4, vous ne verrez pas AWS Lambda écrit nulle part, mais ne désespérez pas ! Les personnes travaillant sur les services cloud comme AWS sont intelligentes. Il n'est pas facile de les prendre dans une situation qu'elles n'ont pas encore imaginée (une autre histoire est de savoir si nous sommes d'accord avec leurs choix de conception, mais c'est l'objet d'un autre article).

Par exemple, si votre première Lambda s'exécute tous les jours à midi, votre deuxième Lambda peut s'exécuter quotidiennement à 12:20.

J'espère que vous avez souri car vous avez alors compris la blague. Sinon, réfléchissons encore une fois au principal problème avec ce que vous venez de lire (il y a plusieurs problèmes avec cette approche, mais ne les passons pas tous en revue). Comment la deuxième Lambda recevrait-elle les informations traitées par la première dans ce scénario ?

Peut-être pouvez-vous stocker ces informations dans une base de données ou un stockage intermédiaire et faire en sorte que la deuxième fonction les récupère automatiquement, mais cela ajoute de la complexité à votre code (et est une grande source d'erreurs et de factures accrues). Une meilleure façon est de passer l'événement directement depuis l'instruction return dans la fonction lambda_handler de la Figure 1 (bien sûr, avec les informations appropriées dans le JSON !). C'est ainsi qu'une Lambda communique avec une autre, après tout.

Invoquer une autre Lambda avec AWS

La première option pour faire communiquer deux Lambdas directement est d'utiliser le SDK (Kit de développement logiciel) AWS. Pour Python, cela s'appelle boto3 et vous permet de gérer et d'interagir avec les ressources AWS depuis votre code. Si vous jetez un œil à la documentation, vous verrez que vous pouvez configurer un client pour gérer les Lambdas et utiliser la méthode invoke pour déclencher une autre Lambda.

import boto3, json

client = boto3.client(‘lambda’)

client.invoke(FunctionName='ListenerLambda', InvocationType='Event', Payload=json.dumps({‘file’: ‘path’}))

(N'oubliez pas de consulter la documentation pour voir ce que signifient les différentes options et quelles autres existent!). Dans cet extrait de code, nous envoyons un événement avec la clé ‘file’ et la valeur ‘path’ à notre fonction de réception, judicieusement nommée ‘ListenerLambda’. Le type d'invocation que nous avons défini (‘Event’) signifie que la fonction Lambda de réception est déclenchée de manière asynchrone : nous n'attendons pas la réponse pour continuer l'évaluation du code.

Cette solution simple fait le job, mais ce n'est pas toujours (ou devrais-je dire rarement) un bon choix. Pour illustrer, imaginez la performance suivante de nos Lambdas :

• La première fonction effectue une tâche simple et peut traiter 1 000 jobs par seconde.

• La deuxième fonction effectue une tâche beaucoup plus difficile et peut traiter 1 job par seconde.

C'est la recette d'un goulot d'étranglement. En cinq secondes, nous pouvons envoyer 5 000 jobs à la deuxième fonction, et elle n'en traite que 5. Pire encore, le nombre maximum de jobs simultanés qu'une seule Lambda peut effectuer (la concurrence) est de 1 000. Alors, qu'est-il arrivé aux presque 4 000 autres jobs ?

Ils ont disparu ! Comme vous pouvez l'imaginer, ce n'est pas bon. En général, vous ne devriez utiliser le SDK pour invoquer de manière asynchrone une fonction Lambda que si vous êtes 100 % certain que la tâche en aval sera toujours plus rapide que celle en amont. Si vous invoquez la Lambda de manière synchrone, ce n'est pas un problème. Votre code se mettra en pause jusqu'à la fin de l'invocation. Cependant, vous serez également facturé pour le temps d'attente.

Conclusion

Nous avons montré les premières étapes dans la construction d'architectures sans serveur efficaces dans le cloud avec les fonctions Lambda d'AWS. Dans la partie 2 de cet article Tech Talk, nous abordons comment le service SQS d'AWS, les fonctions Step et un ensemble restrictif de permissions servent de fondement pour une architecture robuste et sécurisée. De plus, nous discutons de la manière de configurer la solution adéquate pour votre organisation.