Editions ENI Livres | Vidéos | e-Formations
AWS Lambda - Développement en Java
Introduction
Lors du chapitre précédent, nous avons mis en place notre environnement de développement articulé autour des principaux outils : la JVM (Java Virtual Machine) appelée aussi JDK (Java Development Kit), maven, IntelliJ IDEA, SAM (Serverless Application Model), AWS CLI, etc. Nous avons déployé une première fonction Lambda sur l’infrastructure AWS, histoire de nous familiariser avec ce processus de déploiement qui, comme on vient de voir, n’est pas si simple.
Dans ce chapitre, nous allons nous plonger dans l’étude des concepts de base de AWS Lambda, leur typologie et leurs classifications, leur structure, leur configuration, leur environnement d’exécution, les paramètres, les entrées et les sorties, les timeouts, la consommation CPU, la gestion de la mémoire, etc.
Concepts de base
Lorsque nous venions de déployer notre première fonction AWS Lambda, nous avions été surpris par le degré d’abstraction de ce processus. En effet, nous n’avions pas eu besoin de nous inquiéter des détails comme le système d’exploitation cible, les procédures de démarrage, la configuration de la JVM, etc. Nous avons juste déployé notre code Java avec le service AWS Lambda, quelque part dans une nébuleuse appelée cloud et, comme par magie, nous avions pu le tester et l’exécuter.
Pour comprendre en détail les étapes de ce déploiement et de cette exécution, examinons le schéma suivant :
L’environnement d’exécution Lambda
Cette figure montre schématiquement le processus de création et d’exécution d’une fonction Lambda. Tout d’abord, il faut souligner que tout se passe par l’intermédiaire de l’API AWS Lambda. L’API create-function est utilisée pour créer une fonction Lambda et, pour l’exécuter ou l’invoquer, c’est l’API invoke qui est utilisée. Cette invocation (ou appel) se passe dans les cas suivants :
-
lorsque la fonction est déclenchée par la réception d’un événement,
-
lorsque la fonction est testée dans la console AWS Lambda et le bouton associé de l’interface graphique est actionné,
-
lorsqu’on appelle explicitement l’API invoke, typiquement depuis d’autres applications Java ou des scripts.
Lors de l’appel d’une fonction pour la première fois, un environnement Linux est créé automatiquement par AWS Lambda. Mais ce détail est juste informatif, car, comme nous l’avons vu, nous n’avons à aucun moment à nous inquiéter quant à la nature exacte de cet environnement Linux (par exemple le niveau du noyau, la distribution, etc). Et même si ces informations sont disponibles, car Amazon les publie ouvertement, il serait risqué de baser notre architecture ou notre développement sur l’hypothèse qu’il s’agisse de tel niveau du noyau ou de telle distribution Linux, car Amazon n’offre aucune garantie de la pérennité de ces détails...
Le projet Java pour AWS Lambda
Notre première fonction AWS Lambda, celle qui nous a servi d’exemple précédemment, a été générée avec IDE IntelliJ IDEA. Cependant, ce n’est pas de cette manière-là que du code professionnel est implémenté.
Lors de la création de notre premier projet, lorsque nous avions sélectionné AWS Serverless Application en tant que type de projet dans l’écran intitulé New Project dans l’IDE, nous avions dû renseigner de nombreuses informations, parmi lesquelles le type de template SAM. Là, nous avions sélectionné le template prédéfini intitulé AWS Hello World (Maven).
Dans un cas plus concret, il serait préférable d’utiliser un autre template SAM que HelloWorld, et qui serait plus proche de nos besoins spécifiques. Notre IDE nous propose d’autres templates mais, lorsqu’aucun ne correspond réellement à nos besoins, la solution est de créer un template personnalisé, adapté à la situation.
1. Création d’un template SAM personnalisé
Dans le cadre de cette section, nous allons créer un template SAM personnalisé qui nous permettra de démarrer plus facilement avec AWS Lambda from scratch, sans avoir à générer du code qui manque de rigueur, de type HelloWorld, pour le modifier manuellement ensuite, ainsi que tous les autres éléments associés comme le nom de package, les répertoires, le nom des classes, etc. Pour ce faire jetons un œil au projet Cookie Cutter.
Cookie Cutter est un projet open source (https://cookiecutter.readthedocs.io) qui permet la génération automatique des projets à partir de templates. Il est très utilisé dans le monde Python, mais nous allons l’utiliser dans le monde Java.
L’idée est d’avoir une hiérarchie de répertoires et de fichiers utilisée comme un template et à partir de laquelle générer des projets Java, avec des packages, classes, etc. Le processus de génération est hautement personnalisable et permet de remplacer des occurrences de chaînes de caractères signalées par des place-holders exprimés dans...
