Article écrit en collaboration avec Lionel Boyomo-Keedi

Le 2 avril dernier s’est déroulé l’AWS Summit de Paris ; on y a parlé serverless, sécurité sur le cloud, micro-services et bien sûr intelligence artificielle avec DeepRacer. Une conférence a particulièrement retenu notre attention : “AWS Lambda en 2019, faciliter le développement”, animée par Alexandre Pinhel et Radek Nevrtal. Voici donc un condensé de ce qui a été évoqué.

Lambda, c’est quoi ?

AWS Lambda existe depuis 2014, et c’est l’un des services qui a le plus évolué ces dernières années. Quand on parle de Serverless sur AWS, on pense tout de suite aux fonctions Lambda qui permettent de développer un modèle d’architecture FaaS (Function as a Service).

AWS Lambda est un service managé, et donc il dispense des inconvénients liés à la gestion des serveurs : toute l’allocation de ressources est gérée par AWS (avec toutefois une limite de RAM que l’on définira à la création de notre fonction), nous n’avons qu’à optimiser notre fonction afin de diminuer le temps d’exécution. Ce qui fait l’intérêt de ce service, c’est son modèle de paiement à l’usage, en effet, on paie en fonction du nombre de requêtes effectuées par les fonctions et pour le temps nécessaire à l’exécution du code.

A noter que le premier million de requêtes est gratuit, ainsi que 400 000 Go-secondes de temps de calcul chaque mois, si il vous en faut plus, le million de requêtes supplémentaire vous coûtera 20 centimes de dollars et 0,00001667 dollars par Go-secondes.

Les fonctions lambdas sont principalement utilisées avec un ou plusieurs déclencheurs, des cas d’usage fréquents sont par exemple :

• Une requête http via API Gateway à besoin d’une réponse
• Un nouveau fichier vient d’être créer dans un bucket s3 et à besoin d’être traité
• Un état de step functions à été changé et l’on a besoin d’exécuter une tache

Extension de la durée maximale d’execution

Depuis octobre 2018, la durée maximale d’exécution d’une lambda est passée de 5 à 15 minutes, permettant ainsi l’élaboration de fonctions plus complexes.

On pourrait penser que c’est une durée courte, mais Radek Nevrtal, architecte chez Transdev, venu partager son retour d’expérience sur l’utilisation de Lambda et des technologies serverless d’AWS, n’est pas de cet avis. Bien que ce changement soit utile pour des cas précis (on pourrait notamment penser à un traitement sur une grosse quantité de données où 5 minutes ne suffisent pas), il nous rappelle qu’il ne faut pas oublier que les fonctions lambda sont faites pour être exécutées le plus rapidement possible pour profiter pleinement de leur faible coût, avec un code le plus optimisé et léger en mémoire possible, et en évitant des fonctions lambda trop monolithiques pour au contraire préférer des fonctions courtes qui ne servent qu’à une seule tache unique.

Lambda layers

Pour permettre aux fonctions de partager du code, une nouvelle fonctionnalité viens d’être annoncée pour lambda: les lambda layers

Une lambda layer permet à partir d’une archive zip de contenir les dépendances de votre code, un custom runtime, des fichiers pour entraîner un modèle de machine learning, en bref, n’importe quel fichier nécessaire à votre lambda, ce qui augmente considérablement les possibilitées du service.

Cependant, quelques limites à garder en tête s’appliquent à cette nouvelle fonctionnalité:

• On peut référencer un maximum de 5 layers pour une fonction lambda.
• La taille de votre layer peut augmenter la durée nécessaire au démarrage de votre lambda, vous devrez donc limiter au minimum vos dépendances

Custom runtimes

Comme nous l’avons rapidement évoqué plus tôt, les lambda layers peuvent également être des custom runtimes.

Un custom runtime, va vous permettre de créer votre propre environnement d’execution pour votre lambda, permettant donc faire des lambdas dans d’autres langages que ceux actuellement officiellement supportés par AWS

De manière officielle, Lambda nous donne le choix entre plusieurs langages de programmation :

• Node.js
• Python
• Java
• C#
• Go
• Ruby

Si vous avez envie de développer votre dernière application serverless dernier cri dans un language tel que cobol, ou bien optimiser vos lambdas au maximum avec du C, les custom runtimes sont ce qu’il vous faut.

Tout ce que vous aurez à faire sera de créer un fichier exécutable nommé bootstrap, qui sera notamment responsable de:

• Lire le handler de la lambda à exécuter depuis une variable d’environnement
• Passer la donnée de l’événement responsable de l’invocation de la lambda au handler
• Transmettre la réponse du handler au service lambda

Si les custom runtimes vous intéressent, vous trouverez un exemple avec C++ d’aws ici, et plus de détails sur la documentation officielle

Il faut cependant garder en tête que notre custom runtime constituera l’une des cinq layers possibles par fonction.

Step Functions

AWS Step Functions va nous permettre d’orchestrer un workflow à l’extérieur des fonctions lambda, pour aller plus loin dans l’esprit qu’une lambda ne doit faire qu’une seule tâche et avoir une exécution le plus rapide possible.

Ce service va donc suivre l’état de chaque lambda du workflow, et agir en conséquences.

Depuis novembre 2018, on peut maintenant appeler d’autres services depuis Step Functions, et donc nous permettre de coordonner rapidement les composants de notre workflow avec l’intégration des services suivants:

• Amazon ECS
• AWS Fargate
• Amazon DynamoDB
• Amazon SNS
• Amazon SQS
• AWS Batch
• AWS Glue
• Amazon Sagemaker

Pour ceux ayant déjà essayé de coordonner des tâches en batch avant décembre 2018, cette nouvelle est une petite révolution.

Avant, pour gérer un batch, il nous fallait des Lambda pour soumettre les jobs, faire du polling pour vérifier l’état du job, et envoyer un message, à SNS par exemple, si le job était terminé.

Maintenant, utiliser l’intégration batch suffira pour récupérer le statut du job et envoyer des notifications, pas de fonctions lambdas nécessaires !

AWS Step Functions Local

Depuis février 2019, Amazon offre la possibilité de développer et tester son environnement Step functions en local, et ce à travers une version téléchargeable disponible sous 2 formes :

• Package JAR
• Image Docker

Il faut au préalable configurer Step functions local à travers un fichier de configuration aws-stepfunctions-local-credentials.txt de manière à pouvoir interagir avec AWS Lambda ou d’autres services utilisés.

Step Function Local est d’autant plus intéressant que cette version nous permet d’économiser les coûts liés aux transitions d’états, on peut ainsi effectuer nos tests dans notre propre environnement de développement sans se soucier de la facture pour tout ce qui est exécuté en local.

A noter que l’on peut également coupler Step functions local à Localstack pour simuler d’autres services AWS.

Conclusion

En bref, il faut retenir que:

• Les fonctions lambdas ont une durée de vie maximale de 15 minutes
• On peut partager du code avec ses lambdas via les lambda layers
• Une layer peut être un custom runtime
• On peut utiliser Step Functions pour orchestrer ses lambdas et interagir avec d’autres services d’AWS
• On peut faciliter le développement et les tests d’un workflow Step Functions avec Step Functions Local & Localstack

Si vous démarrez sur AWS Lambda, nous vous conseillons la lecture de notre article détaillant les bonnes pratiques à mettre en oeuvre.