Introduction aux architectures Serverless

Transcript

Bonjour à tous, très heureux de vous retrouver en 2017 pour une nouvelle série de webinars. J'en profite pour vous présenter tous mes vœux pour cette nouvelle année. Il est encore à peu près temps de le faire. Au programme aujourd'hui, nous avons deux sessions, toutes les deux sur les architectures serverless. Une première session d'introduction qui est vraiment orientée vers les personnes qui découvrent les architectures serverless, et une deuxième session où nous irons un peu plus en profondeur. Nous parlerons des nouvelles fonctionnalités de Lambda qui ont été annoncées à re:Invent, des différents frameworks open source qui vous permettent de développer plus facilement sur AWS Lambda, et bien sûr, de nombreuses démonstrations. Comme d'habitude, je suis accompagné d'Hugo qui s'occupe de la logistique et de noter toutes vos questions au fur et à mesure. N'hésitez pas à lui envoyer vos questions. Il les triera, et nous y répondrons. Pour vous remercier de vos questions, il y aura un gagnant à la fin des deux sessions, celui qui aura posé la meilleure question. Je ne sais pas ce que c'est que la meilleure question, mais commençons. N'hésitez pas à poser vos questions, nous sommes là pour y répondre. Je vous propose de commencer cette première session. Voici l'agenda. Tout d'abord, quelques définitions sur les architectures serverless. Ensuite, nous parlerons de deux produits AWS qui sont au cœur des architectures serverless, à savoir Lambda et API Gateway. Ensuite, nous basculerons sur une démo où je vous montrerai comment écrire votre première fonction Lambda, comment la déployer, comment lui ajouter une API. Nous prendrons notre temps pour être sûrs que tout le monde quitte cette session en ayant parfaitement compris comment tout ça fonctionne. Ensuite, je vous ferai une deuxième démonstration plus élaborée où je construirai un pipeline de données qui, à partir d'une invocation d'API, va transporter des données jusqu'à S3 en utilisant uniquement des services managés et des fonctions Lambda. Et c'est une démo à laquelle vous pourrez participer, donc ça devrait être assez amusant. Bien sûr, quelques ressources supplémentaires et ensuite vos questions. Commençons par l'introduction au serverless. Si on prend un peu de recul sur les besoins des applications à l'échelle Internet aujourd'hui, on tombe systématiquement sur ces cinq besoins. Le premier besoin, c'est la simplicité. Construire des applications à l'échelle Internet est quelque chose de complexe, avec un certain nombre de challenges à relever. L'objectif pour AWS est de vous proposer les services les plus simples possibles, qui masquent le maximum de complexité. Le deuxième point important, c'est la scalabilité. Vous lancez un nouveau service, une nouvelle application, et vous devez être prêt à affronter ce qu'on appelle le "succès catastrophique", c'est-à-dire un succès au-delà de toute mesure. Il serait dommage de ne pas être capable de scaler votre application suffisamment rapidement et de transformer un projet prometteur en échec. Le troisième point très important, c'est la fiabilité. Personne ne peut se permettre de lancer des services ou des applications web ou mobile sans un bon niveau de garantie de fonctionnement. Les utilisateurs fuient les services qui ont tendance à avoir des pannes répétées et ne reviennent généralement pas. Le quatrième point, c'est une latence faible. Nous parlons de services mobiles Internet interactifs avec des interfaces graphiques souvent riches. Il serait inacceptable que l'application soit lente et désagréable à utiliser. C'est un bon moyen de faire fuir ses utilisateurs. Le dernier point, et non des moindres, c'est un coût raisonnable. Un coût raisonnable, c'est un coût qui s'adapte en permanence au business et à l'utilisation réelle du service. La possibilité d'avoir le minimum de coût fixe, voire aucun coût fixe, et uniquement un coût d'utilisation qui s'adaptera au trafic réel et à l'utilisation réelle de votre application. Au fil du temps, AWS a livré un certain nombre de services adaptés à ce type d'application. Le premier est évidemment S3 pour le stockage d'objets. Puis est arrivé DynamoDB, une base de données NoSQL managée, facile à utiliser et très scalable. On a du stockage, on a la capacité de stocker et de traiter des données, mais quid du calcul, quid du traitement des informations ? Bien sûr, on peut travailler avec de l'infrastructure sur site, mais le délai de mise en marche d'un nouveau serveur se compte généralement en semaines, voire en mois. La scalabilité d'une telle infrastructure peut être fortement mise en difficulté si vous devez scaler rapidement. Avec l'arrivée des technologies de virtualisation et du cloud, on est passé aux machines virtuelles, Amazon EC2, où on peut démarrer des instances de toute taille en quelques minutes. Plus récemment, avec l'arrivée des technologies de conteneurs comme Docker et le service ECS d'Amazon, on est passé aux secondes. On est capable de démarrer un grand nombre de conteneurs en quelques secondes et d'adapter le profil de l'application et la taille de l'infrastructure au trafic de manière extrêmement réactive. Mais l'idéal ne serait-il pas de se passer complètement de toute infrastructure ? C'est ce que Werner Vogels, le CTO d'Amazon, a dit lors de notre conférence re:Invent en 2015 : "Le serveur le plus simple à gérer, c'est quand il n'y a pas de serveur." L'idée de l'infrastructure sans serveur, au sens de sans serveur visible ou à manager par le client, est le point clé du serverless. Bien sûr, il y a des serveurs et de l'infrastructure dans nos data centers, mais l'objectif des architectures serverless est d'abstraire complètement la complexité de l'infrastructure, de la masquer aux yeux du client et de lui permettre de se concentrer uniquement sur le développement de son application. Si on regarde un peu plus en détail, voici une vue très simplifiée et haut niveau de ce qu'est le serverless pour des applications web et mobile. Ces applications accèdent via Internet à votre plateforme serverless dans AWS. La plupart du temps, on trouve trois composantes dans votre infrastructure. Des API publiques déclarées dans API Gateway, qui invoquent des fonctions Lambda que vous avez développées. Ces fonctions peuvent interagir avec une palette de services AWS, en particulier les services managés comme S3, DynamoDB, Kinesis, etc. Le serverless, c'est construire des applications sans jamais avoir à se soucier de l'infrastructure sous-jacente, totalement invisible, avec la scalabilité, la sécurité, et la disponibilité prises en charge par le service. Si vous pensez que tout cela est encore de la R&D, sachez qu'il y a de nombreux clients qui adoptent les architectures serverless et qui bâtissent des plateformes de production. Par exemple, Adroll, un grand acteur de la publicité en ligne, traite des dizaines de milliards d'événements publicitaires par jour en utilisant une architecture serverless. Nordstrom, un grand retailer américain, a développé un module de recommandations de produits basé sur les architectures serverless. Ces exemples montrent un fort engouement autour de ces technologies, et j'espère que ces webinaires vous expliqueront pourquoi. Si vous voulez en savoir plus sur ces cas d'utilisation, vous les retrouverez sur notre site web. Commençons donc à explorer les architectures serverless en parlant de Lambda, qui est vraiment une nouvelle façon d'exécuter du code, ce fameux chaînon manquant pour le stockage (S3) et les données (DynamoDB). Lambda vous offre un moyen simple, scalable, efficace, et sans gestion d'infrastructure de déployer votre code dans AWS. Lambda a été annoncé il y a deux ans, à re:Invent 2014. L'objectif de Lambda est de vous permettre de déployer des fonctions de code dans quatre langages : Java, Python, Node.js, et récemment C#. On supporte différentes versions de Python et de Node.js. Au lieu de déployer une application complète, comme avec Elastic Beanstalk ou une instance EC2, vous déployez un ensemble de fonctions, de petits traitements bien définis, séparés les uns des autres, et sans état local. La fonction démarre, reçoit une entrée, la traite, produit un résultat, se termine, et n'a pas d'état local. Elle peut utiliser des services managés comme DynamoDB, S3, etc., mais localement, elle ne stocke aucun état. C'est juste du code, un déploiement de code, sans provisionnement ni gestion d'infrastructure. C'est un service complètement managé, avec la scalabilité et la haute disponibilité intégrées. Si votre fonction Lambda doit être invoquée 100 fois par seconde, 500 fois par seconde, l'environnement Lambda provisionnera suffisamment de ressources pour garantir le bon nombre d'exécutions. La disponibilité est également fournie automatiquement. Lambda est intégré avec un grand nombre de services AWS, ce qui fait sa force. Lambda est en paiement à l'usage, facturé au temps d'exécution et à la mémoire utilisée, avec des slots de 100 millisecondes. Si votre fonction dure 150 millisecondes, vous paierez deux slots. Si vous l'optimisez pour qu'elle prenne 95 millisecondes, elle ne vous coûtera qu'un slot, divisant le coût de ce traitement par deux. Il y a un niveau d'usage gratuit, avec le premier million de requêtes par mois. Qu'est-ce qu'on peut faire avec Lambda ? Le premier point, sans ordre de priorité, est de servir de liaison entre toutes les parties de votre infrastructure AWS. Par exemple, vous pouvez déclencher une fonction Lambda lorsqu'un objet est déposé dans S3. Imaginez que vous déposiez des images dans un bucket S3, vous pourriez automatiquement invoquer une fonction Lambda qui redimensionne l'image, la met en noir et blanc, et la copie dans un autre bucket, déclenchant une deuxième fonction Lambda qui la distribue via CloudFront. Chaque semaine, on trouve de nouvelles façons d'intégrer Lambda dans l'infrastructure, et dans des logiques d'automatisation, DevOps, etc., Lambda se révèle un outil précieux. Vous pouvez concevoir vos applications comme des applications événementielles qui réagissent à des événements dans votre infrastructure. Vous réagissez à des événements, quand ils se produisent, vous exécutez du code, quand il ne se passe rien, vous n'exécutez pas de code, et la plateforme ne vous coûte rien. Le troisième point est la construction d'API en conjonction avec l'API Gateway. Vous pouvez concevoir des API REST, définir des ressources, des méthodes, et publier ces API sur différents stages, en quelques clics, pour des API visibles sur Internet et interfacées avec des fonctions Lambda. Quelques mots sur API Gateway avant de passer à la première démo. API Gateway est un service managé qui vous permet de déclarer vos API et de les coupler à des fonctions Lambda ou d'autres solutions. Il offre une solution unique pour gérer vos API publiques sur AWS. Vous pouvez définir des seuils maximum d'appels (throttling) pour protéger vos back-ends d'un pic de trafic ou d'une attaque par déni de service. Vous pouvez définir le nombre maximum d'appels par seconde, et si ce pic est atteint, les appels excédentaires sont rejetés pour ne pas écrouler votre plateforme. API Gateway offre également la capacité d'authentifier et d'autoriser les requêtes vers le reste de la plateforme avec des URL signées, des tokens, etc. Il y a tout un tas de méthodes d'authentification supportées pour protéger votre plateforme. API Gateway est donc une façon simple et très scalable de définir des API visibles pour vos applications clientes, sans avoir à provisionner et gérer des serveurs d'API. Il y a un point important à mentionner avec API Gateway. Dans la première démonstration, je vais utiliser la console pour découvrir les services, mais en production, on a souvent envie d'automatiser. Vous pouvez utiliser la ligne de commande ou l'un des SDK d'AWS pour créer et publier vos API, mais ce process est relativement compliqué, nécessitant 9 appels successifs à l'API Gateway. C'est très bas niveau et pas très pratique. Une autre solution est d'utiliser un fichier de définition d'API Swagger pour importer vos définitions d'API. Si vous avez déjà des API décrites, vous pouvez les réutiliser. Vous pouvez également utiliser un framework de développement, que nous verrons dans la deuxième session. Pour ce premier webinar, je vais montrer la partie API Gateway dans la console, ce qui me permettra de vous l'expliquer au fur et à mesure, mais je suis conscient que ce n'est pas comme ça qu'on le ferait en production. Il est temps maintenant d'écrire notre première fonction Lambda. Le workflow sera typique : écrire le code, le déployer, créer une API devant cette fonction Lambda avec API Gateway, connecter l'API à la fonction Lambda, invoquer l'API, tester, déboguer, et itérer. Je vous propose de commencer par une fonction très simple en Python, qui additionne deux valeurs passées en JSON. Passons à la console et faisons ça en vrai. N'hésitez pas à envoyer des questions, je vois que ça commence déjà. Très bien, on est au bon endroit. On va commencer par jeter un œil à notre fonction Lambda. C'est bien ce que je vous ai montré tout à l'heure. C'est uniquement ça qu'on va déployer. On a juste un traitement qui reçoit un document JSON avec `value1` et `value2`, fait la somme, et la retourne. Voilà, c'est mon code. Ensuite, je vais déployer cette fonction. Je vais positionner mon numéro de compte AWS, zipper le code de la fonction Lambda, puis utiliser la ligne de commande `aws lambda create-function` pour créer la fonction. Elle prend plusieurs paramètres : le nom de la fonction, le nom du handler, le runtime Python, l'emplacement du fichier zip, la mémoire allouée (128 MB), le rôle (basic execution), et la région. On va exécuter ce script, puis invoquer la fonction avec un payload JSON contenant les valeurs à additionner. Le résultat sera stocké dans un fichier et affiché. Voilà, c'est fait ! Vous voyez le retour de `Create Function`, le retour de `Invoke`, et le contenu du fichier, qui est 12 (5 + 7). Vous avez vu à quelle vitesse tout s'est passé. Le déploiement et l'invocation sont très rapides. Je pourrais réinvoquer ma fonction à l'infini. C'est un exemple simple, mais il illustre bien le concept : j'ai écrit une fonction, je l'ai déployée, et je l'ai invoquée sans créer d'infrastructure. Si on jette un œil à la console, je devrais voir ma fonction Lambda1 qui a été créée. Je vois son code, sa configuration, le rôle, le runtime Python, etc. La mémoire maximale, le timeout (5 minutes maximum), et les triggers (aucun pour l'instant). Dans le monitoring, je peux voir le nombre d'invocations. Dans CloudWatch Logs, chaque fonction Lambda a un groupe de logs automatique. Si vous voulez logger des informations à l'intérieur de la fonction, par exemple avec `print` en Python, ces informations s'afficheront dans CloudWatch. C'est là qu'il faut aller pour déboguer ou comprendre un souci. On va ajouter une petite API. On va le faire manuellement dans la console API Gateway. On crée une API appelée `addIntegers`, une ressource `add`, et une méthode `POST`. On intègre cette méthode à notre fonction Lambda, on la déploie, et on crée un endpoint visible sur Internet. On peut maintenant faire une invocation HTTP POST sur cet endpoint, en passant les valeurs à additionner dans le JSON. Voilà, la réponse est 1789 (1700 + 89). Vous voyez que nous n'avons pas déclaré ni provisionné d'infrastructure. Nous avons uploadé une fonction Lambda, ajouté une API, publié cette API, et invoqué l'API. À aucun moment, nous avons géré de l'infrastructure. Nous nous sommes concentrés sur notre projet. On va faire une petite modification. Dans cette fonction, on va ajouter un `print` pour afficher l'entrée. On sauve la fonction, on la met à jour avec un script, et on réinvoque l'API. Cette fois, on voit le résultat, et dans CloudWatch, on voit le `print` qui a été exécuté. Vous pouvez modifier vos fonctions, les mettre à jour, et logger des informations dans CloudWatch. Enfin, pour terminer, on va effacer la fonction Lambda et l'API. On supprime l'API en console, puis on appelle le script de suppression de la fonction. Voilà, la fonction a disparu. On a vu rapidement tout le cycle de développement sur un exemple très simple. On voit comment uploader une fonction, créer une API, mettre à jour la fonction, et effacer la fonction. Ce n'est pas très compliqué, mais ce n'est pas non plus très user-friendly. Dans le deuxième webinar, nous verrons comment rendre ce process plus efficace. Si vous développez avec Eclipse en Java, nous avons un plugin AWS pour Eclipse qui supporte maintenant les projets Lambda. Histoire de ne pas faire de jaloux, si vous êtes un développeur C# avec Visual Studio, vous avez un outil un peu du même ordre qui est relativement récent, et il déplace n'hésitez pas à aller voir l'URL pour plus de renseignements. Un petit exemple client, j'ai mentionné les exemples tout à l'heure mais rentrons un peu dans les détails de celui-ci. C'est une société qui s'appelle A Cloud Guru que vous connaissez peut-être, qui est une startup qui délivre des trainings vidéo sur les technos AWS et d'autres technos comme Docker. À titre personnel, je les recommande chaudement, c'est vraiment du contenu de très très bonne qualité et à un prix particulièrement compétitif. Vous allez me dire pourquoi dire ça, parce qu'en fait c'est totalement lié à la façon dont leur infrastructure est conçue : 100% de leur plateforme est basée sur des technos serverless. Donc très concrètement, ça veut dire que Cloud Guru n'a pas d'instance EC2, ils n'ont que soit des services SaaS comme Stripe pour le paiement ou Auth0 pour l'authentification, soit des microservices qui ont été développés avec des fonctions Lambda et qui sont exposés sur Internet avec l'API Gateway. Et cette architecture-là a une propriété intéressante qui est de se dire : s'il n'y a pas de trafic sur la plateforme, la plateforme ne coûte quasiment rien. Puisque comme les fonctions Lambda sont facturées au temps d'exécution, contrairement aux instances qui sont facturées à l'heure, qu'elles fassent quelque chose ou pas, quand Cloud Guru n'a pas de trafic, leur facture n'augmente pas ou quasiment pas. Et quand ils ont du trafic, ils le traitent. Mais s'ils ont du trafic, ça veut dire que les gens ont acheté des formations, les visualisent, etc. Et donc, ils peuvent corrélater leur trafic à leur vente et ils corrèlent leur infrastructure à leur trafic. Et donc c'est une façon vraiment très très maligne de bâtir sa plateforme. Plus de détails sur leur blog qui détaille cette infrastructure. Mais vraiment voilà un exemple d'une boîte qui tourne 100% en serverless. Alors pour finir quand même, pour vous montrer un exemple un peu plus compliqué, un peu plus riche, je vous propose de regarder ce fameux pipeline. Il est déjà créé, mais je vais vous l'expliquer. L'idée est la suivante : à partir d'une invocation d'API hébergée dans API Gateway, je vais appeler une fonction Lambda qui va écrire dans un flux Kinesis, donc Kinesis qui est un de nos services managés de messaging extrêmement scalable et vraiment très adapté aux applications temps réel. On va écrire des informations dans ce stream. Une autre Lambda va réagir automatiquement à l'écriture dans le stream. Elle va insérer les informations dans DynamoDB, donc notre base NoSQL managée. Et tout ça va se faire rapidement. Ces données vont être disponibles instantanément en quelques dizaines de millisecondes pour des applications qui auraient besoin d'y avoir accès à d'autres applis web. Et puis il y a un mécanisme qui s'appelle DynamoDB Streams qui est un trigger finalement sur une insertion dans DynamoDB. Je vais appeler une autre fonction Lambda qui va écrire dans Kinesis Firehose qui est une abstraction plus haut niveau au-dessus de Kinesis, pointé vers S3 que vous connaissez, et donc je vais me retrouver avec mes informations dans des fichiers S3 afin par exemple de les traiter avec MapReduce ou avec Redshift. Et donc voilà, l'idée c'est de se dire : je construis un unique pipeline qui est capable de logger des données très vite pour des applications web temps réel, etc., et puis qui est capable, en continuant son chemin, finalement de les logger aussi pour un système qui va faire de l'analytics. Alors je vais vous montrer super vite les fonctions Lambda concernées et puis après on va lancer l'appli et puis on va faire des démos. Alors en avant sur les Lambdas. Donc la première, j'ai mon API Gateway qui est configuré comme je vous montre tout à l'heure, donc la première fonction Lambda va s'appeler "write to Kinesis" et donc elle va être déclenchée automatiquement à chaque fois que mon API est appelée. Cette fonction reçoit donc l'événement, elle va rajouter dans l'événement un petit timestamp et puis elle va accéder à Kinesis et écrire ce record put record dans un stream Kinesis que j'ai configuré. Donc simplement, elle prend ce que l'API lui passe, elle rajoute un timestamp et elle l'écrit dans Kinesis. Vous voyez, ça prend trois lignes. Ensuite, à la sortie de Kinesis, j'ai une deuxième fonction Lambda qui elle aussi va être appelée automatiquement. Vous voyez tout ça quand je parlais d'événementiel et de glue entre les différents services, voilà de quoi je parle. Donc automatiquement, cette deuxième Lambda va être appelée, elle va prendre, elle va demander l'accès à cette table event table dans DynamoDB et puis elle va lire les différents records qui ont été écrits dans Kinesis, elle les décode puisqu'ils sont écrits en base 64, elle les remet en format JSON et elle les écrit dans DynamoDB. Elle fait table.putitem et elle écrit dans DynamoDB. Donc vous voyez, 5-6 lignes de code très très simples. Je dépile ce qui arrive dans Kinesis, je l'écris dans DynamoDB. Troisième fonction, DynamoDB reçoit de nouveaux items et elle déclenche cette troisième fonction qui elle aussi va lire les records qui lui sont passés par DynamoDB et puis qu'est-ce qu'elle fait ? Elle demande accès à Firehose et elle l'écrit dans Firehose, tout simplement. Et Firehose, qu'est-ce qu'il fait ? Firehose, il est configuré ici, vous le voyez, il va écrire dans le bucket jcmon public en zipant les données et sans les chiffrer. Donc vous voyez, si je reviens 5 secondes sur mon slide, vous voyez que tout ça, ça se construit comme du Lego, on emboîte les services les uns avec les autres et on insère juste des petits bouts de fonction, des petites fonctions Lambda pour faire la glue entre les différents services. Et vous voyez, on arrive à construire un truc qui est relativement puissant, qui est relativement efficace. Alors on va démarrer la petite appli de test qui est là, toujours connectée, ok. Alors c'est là qu'on va pouvoir commencer à jouer. Donc vous pouvez préparer votre navigateur, voilà donc si vous voulez invoquer l'API que je viens de créer, on va la tester. Voilà donc quand vous appelez cette API, on va regarder un peu, c'est parti. Et donc évidemment, vous pouvez recharger à chaque fois. Et donc qu'est-ce qui se passe ? Qu'est-ce qui se passe quand on fait ça ? Donc à part afficher un chat rigolo, et bien donc je fais un POST, je génère des données aléatoirement, histoire d'avoir quelque chose à poster. Et donc je... On va garder ça là, comme ça je vois ce qui se passe derrière. Voilà, c'est rigolo. On poste sur l'API. L'API déclenche une fonction Lambda qui est écrite dans Kinesis et puis il retourne. Une autre fonction Lambda est déclenchée, elle prend ce qu'il y avait dans Kinesis et l'écrit dans DynamoDB. DynamoDB déclenche son trigger, invoque la troisième Lambda qui prend les données, les écrit dans Firehose. Et donc Firehose est pointé vers mon bucket S3. Et donc si je regarde ce qui se passe dans S3, alors allons-y, je vois donc là Firehose se vide dans S3 toutes les minutes, donc là on a un premier fichier 16h24, attendre et puis on va avoir on va avoir affiché toutes les minutes qui contiennent toutes les données qui proviennent de ce POST. Ok, donc voilà, on le rechargera après, ok, là on voit tous vos appels très bien. Voilà, deuxième fichier, 16h25, et puis j'en aurai un autre à 16h26, tant qu'il y a des données qui arrivent dans le pipeline. Donc le point qui est important là-dedans, on va laisser ça afficher, c'est que, imaginez là vous êtes un certain nombre à tester, imaginons qu'on ait envie d'avoir 100 000 hits par seconde sur cette infra, qu'est-ce qu'il faudrait changer ? Qu'est-ce qu'il faudrait scaler ? Qu'est-ce qu'il faudrait modifier ? De fait, quasiment rien puisque tous ces services qu'on a utilisés là sont des services managés et donc qui vont scaler automatiquement en fonction du trafic, que ce soit API Gateway, Lambda, Kinesis, etc. Donc il faudra augmenter quelques limites dans votre compte AWS, il y a un tout petit peu de configuration à faire avec le support, mais il y aura en termes de design, il n'y aura rien à changer. Cette infrastructure et donc pour info on a écrit à peu près 16 lignes de code, on a démarré exactement 0 serveurs et on a un niveau de performance et de scalabilité qui est maximum puisque tous ces services scaleront automatiquement en fonction du trafic que vous voudrez bien leur envoyer. Voilà, on va rajouter un fichier comme ça chaque minute et à l'intérieur du fichier, on a l'événement JSON qui a été posté ici. Donc voilà, un exemple finalement d'intégration de Lambda avec des services managés AWS. Alors on va conclure. Vous pouvez continuer à jouer si vous voulez, je le laisse allumer. Petite précision, mon collègue Danilo a publié en décembre un bouquin sur Lambda que je vous conseille très chaudement. Danilo est vraiment un expert du domaine, le bouquin est très didactique, très bien fait. Voilà, vous pouvez vous le procurer partout, pas forcément sur Amazon. Et voilà, si vous cherchez un livre sur Lambda, je vous conseille celui-là, c'est l'information qui vient directement d'un expert. Vous pourrez également vous référer aux différentes vidéos publiées à re:Invent sur Lambda qui couvrent les nouveautés Lambda et également d'autres services autour de Lambda dont je ne parle pas aujourd'hui comme Lambda@Edge ou Greengrass, mais je vous laisse découvrir tout ça, on aura peut-être l'occasion d'en parler lors d'un webinaire ultérieur. Et puis un petit rappel sur nos user groups, si vous voulez participer à nos user groups, vous les trouverez tous sur meetup.com. On est en train d'ouvrir un nouveau groupe sur la Côte d'Azur, d'ici quelques jours j'espère. Et puis si vous êtes en province, dans l'une de ces villes, ou dans une autre ville et qu'il n'y a pas de groupe et que vous avez envie d'en créer un, n'hésitez pas à me contacter. Voilà, merci beaucoup, j'espère que tout ça a été utile et intéressant. Je pense que vous êtes encore en train de jouer avec mon application, elle est toujours pas tombée, vous voyez pas si mal pour une petite application Python et on va passer aux questions. À part, Hugo me dit qu'on a un sondage, pardon, le sondage de satisfaction, comment pouvais-je l'oublier ? Donc n'oubliez pas, alors vous pouvez voter de 1 à 5. 5 est la meilleure note et 1 la plus mauvaise, ne vous trompez pas. Donc 5, vous êtes très content, 1, vous êtes furieux. J'espère que ce n'est pas le cas. Voilà, je vous laisse quelques minutes pour voter et puis ensuite on va répondre à vos questions. N'oubliez pas qu'on choisira un gagnant de la meilleure question. Il y a une tonne de questions, je pense qu'on va avoir un gagnant. Alors c'est bon, tout le monde a voté ? On attaque les questions ? Ouais ? Allez, on commence. Alors, question de Ludovic. J'ai cru comprendre qu'on pouvait utiliser les Lambdas avec d'autres langages, dont Golang. Pouvez-vous nous en dire plus ? Alors vous allez le voir, en fait, on va en parler dans le deuxième webinar. Effectivement, au-delà des quatre langages qui sont supportés, un certain nombre d'outils open source ont été développés qui permettent d'exécuter du Golang et d'autres langages en se basant sur des petits bouts de code Node.js généralement qui sont générés et interposés entre votre langage et Lambda. Donc oui, il est possible de le faire. Restez connectés, on va en toucher de vous. Alors, on a une question de Sadoc. Que se passe-t-il si l'exécution de la fonction Lambda dépasse exceptionnellement les 5 minutes ? Alors si elle dépasse exceptionnellement les 5 minutes, elle est tuée. Le timeout maximum pour une Lambda, c'est 300 secondes. Donc il n'est pas question de dépasser les 5 minutes. Voilà. Comment diagnostiquer ? Vous le voyez dans le monitoring de la Lambda, vous le verrez dans CloudWatch, vous verrez que vous avez des fonctions qui time out. Alors, question sur les logs de Ludovic encore. En cas de suppression de la Lambda, est-ce qu'on perd les logs ? Faut-il les basculer dans S3 avant suppression ? Donc non, si la Lambda est supprimée, les logs restent dans CloudWatch. Donc voilà, vous pouvez aussi les supprimer dans CloudWatch ou les faire expirer dans CloudWatch Logs, comme d'habitude, mais il n'y a pas de corrélation de l'effacement. Alors, question de Jonathan, est-ce qu'on peut tester une Lambda en local ? Alors, pas avec ce que j'ai montré là, mais idem, dans le deuxième webinar, je vais vous montrer comment certains frameworks open source vous permettent de le faire, de faire une exécution locale et évidemment de débugger. Alors encore une question, question de Jacob, comment est-ce qu'on fait pour débugger une fonction Lambda ? Donc ça renvoie un peu à ce que je disais à l'instant, alors on peut tester localement et une fois qu'on déploie, le seul moyen de logger c'est ce que j'ai montré, c'est dans CloudWatch Logs. Généralement, peut-être vous aurez un grand classique, c'est le problème de permission, donc vérifier que le rôle IAM associé à votre Lambda lui donne les permissions suffisantes pour accéder aux différents services, vérifier que le timeout n'est pas trop faible, vérifier que le format de l'événement est correct. Il m'est déjà arrivé de, lorsqu'on fait du test local avec des événements de tests en JSON, c'est une chose et ça marche, et puis après on fait des invocations comme j'ai fait avec HTTP ou curl, etc., ou avec des vraies données et le format de l'événement JSON est différent, il peut y avoir le body de la requête HTTP, il peut y avoir des trucs comme ça, donc ça c'est particulièrement agaçant et le meilleur moyen c'est de vérifier que l'événement que votre Lambda reçoit est bien ce qu'elle attend. Voilà, voilà les problèmes que j'ai moi habituellement, c'est des problèmes de JSON différents entre un environnement de prod et un environnement de test, des problèmes de droits IAM, des timeouts. Et puis une fois de plus, servez-vous de CloudWatch Logs. Alors je continue. Est-ce qu'une Lambda peut appeler une autre Lambda ? Question de François. Oui, tout à fait. Une Lambda peut tout à fait... Elle a accès au SDK... Ici j'ai fait du Python, tout le SDK Python. Donc modulo les bonnes permissions dans son rôle, elle peut appeler toute l'API. Elle pourrait tout à fait appeler une autre Lambda. On a lancé à re:Invent un service qui s'appelle Step Functions, qui permet de faire de l'orchestration sur les Lambdas. J'en toucherai deux mots tout à l'heure. Question de Stéphane. Comment sont gérées les dépendances pour la fonction Lambda ? Qu'est-ce qui se passe si ma fonction a besoin d'un package particulier ? Dans le zip que vous uploadez, vous pouvez ajouter vos dépendances. Si vous avez une librairie particulière que vous voulez avoir, vous pouvez la zipper et vous l'uploader avec la fonction. Ce qui est fourni de base, c'est le zip. Si vous faites du Python, prenons cet exemple-là, c'est l'environnement Python standard, donc les modules de base, je ne sais pas, OS, etc., ils sont là. Et le SDK est là. Donc en Python, si vous voulez Boto3, il est là, ce n'est pas la peine de l'uploader. Par contre, si vous voulez inclure des librairies qui vous sont propres, vous pouvez simplement les embarquer dans le zip. Voilà. Alors, question de Saïd. Peut-on créer des instances, des users à IAM, etc. avec Lambda ? Oui, tout à fait. C'est ce que je disais tout à l'heure. Modulo les bonnes permissions à IAM, vous pouvez appeler toute l'API AWS. Donc, vous voyez la puissance que vous pouvez avoir, le niveau d'automatisation que vous pouvez avoir avec des Lambdas. On peut tout appeler avec les Lambdas. Alors, question sur encore sur les logs. Pour faciliter l'audit des logs, est-ce qu'on voit dans les logs le moment où on change la version de la Lambda ? Alors, je l'ai montré tout à l'heure, je suis passé peut-être un peu vite. À chaque fois qu'il y a une nouvelle version de la Lambda, vous avez un nouveau log dans le groupe, dans le log group de la Lambda. Donc vous avez l'identifiant de version. Vous pouvez tracer facilement le fait que ce log-là provient de telle version. Alors, question, à part la durée d'exécution de Lambda limitée à 5 minutes, quelles sont les autres limites ? Alors, il y a essentiellement deux limites sur Lambda. Alors, disons trois. Il y a le nombre maximum de Lambdas que vous pouvez exécuter en parallèle. Donc ça, c'est ce qu'on appelle une soft limit. Donc si vous avez besoin de l'augmenter, comme d'habitude, vous contactez le support, vous créez un ticket et ils l'augmenteront si c'est pertinent. Ensuite, il y a la limite sur le temps d'exécution maximum, qui est de 300 secondes. Et il y a une troisième limite qui est sur la taille maximum du zip. Et de mémoire, je crois que c'est 50 mégas zippé et 250 mégas dézippé. Bon, 50 mégas zippé pour du Python ou du Node.js ça devrait suffire. Pour du Java, je peux admettre que ça puisse être un problème de temps en temps si vous avez de grosses librairies. Encore deux ou trois questions. Alors, il y a plusieurs personnes qui me demandent quand est-ce qu'on aura Python 3 dans Lambda. Je ne sais pas, je suis désolé, je ne peux pas vous répondre. Moi aussi je l'attends. Voilà, on a ajouté C# par Invent. Je pense qu'on ajoutera d'autres environnements et d'autres langages en 2017. Voilà, malheureusement je n'ai pas d'infos à vous communiquer là-dessus. Idem pour les versions de Node.js, je suis désolé, je n'ai pas d'infos, mais bon, je dirais le bon sens veut qu'on upgrade tout ça au fil de l'eau. Alors, je reviens sur la facturation, j'ai plusieurs questions sur la facturation. Je reprécise bien, la facturation se fait au temps d'exécution et arrondi à la centaine de millisecondes supérieure. Si votre fonction dure 1,53 secondes, vous allez payer pour 1,6. Le timeout, c'est le temps maximum d'exécution de la fonction. Si vous avez mis un timeout à une minute et que votre fonction dure une minute et time out, vous payez pour une minute. Si vous avez mis un timeout à une minute et que la fonction dure trois secondes, vous payez trois secondes. Vous ne payez pas le timeout que vous définissez, vous payez le temps exact d'exécution arrondi à la centaine de millisecondes. Alors peut-être encore une ou deux. Quelle est la latence des Lambdas développées en Java versus Python ou Node.js ? Alors, je vous encourage à faire le test. Vous verrez généralement que la première invocation de votre Lambda est plus lente que la deuxième et la troisième. Néanmoins, c'est toujours difficile de donner des chiffres, mais dans mon expérience, c'est vrai qu'on voit que Python et Node ont tendance à s'exécuter un peu plus vite, en tout cas à démarrer un peu plus vite que Java. Je pense que c'est lié au temps de démarrage et au temps de chauffe de la JVM. Maintenant, ça se sent surtout sur le premier appel. Si vous avez une API ou une Lambda qui est appelée de manière répétée, je pense qu'au bout d'un certain temps, la JVM est suffisamment chaude pour que la différence soit négligeable. Mais c'est vrai que sur le premier appel, il y a une latence qui est un peu supérieure en Java. Donc, si vous avez des APIs qui sont appelées très très rarement, il faut peut-être tester une implémentation dans un autre langage si jamais la latence de l'API est un problème. Alors, quel est le nombre maximum d'exécutions en parallèle ? C'est une soft limit. On va regarder tout de suite. J'ai un chiffre en tête mais je n'ai pas envie de vous dire un riz. Comme ça, on va vérifier la taille du zip file aussi. Voilà, c'est 100. Par défaut, c'est 100 Lambdas en parallèle. Vous pouvez l'augmenter. Ce n'est pas un problème. Vous créez un ticket au support. La taille du zip file, zippé, c'est 50 mégas. Et dézippé, c'est 250. Donc, ça, je réponds aux deux questions. Alors, pourquoi j'utilise Yaus ? Oui, désolé, c'est mon côté rétro. C'est parce qu'il ne vous aura pas échappé que j'utilise un environnement Windows, ce qui surprendra peut-être ceux qui m'ont vu passer tous les autres webinars sur macOS. Mais pour la petite histoire, on a fait ce webinar en utilisant Workspace, qui est la technologie de virtualisation de desktop d'AWS, parce qu'elle nous permet d'avoir une meilleure qualité d'enregistrement audio et vidéo que lorsque je travaille sur mon Mac hébergé au bureau. Donc rassurez-vous, je n'ai pas abandonné mon Mac pour Windows, et il se trouve que je ne sais pas pourquoi Firefox par défaut a l'IAO. Donc rassurez-vous, je vais le corriger. Alors, est-ce qu'on a encore une petite question ? On n'a plus le temps ? On n'a plus le temps ! On a plus de temps, on garde les questions, on va les retrier encore un peu et on garde les questions pour le deuxième webinar. Et puis on aura... On choisit le gagnant maintenant ou on choisit le gagnant maintenant ? Non mais je vais vexer plein de gens. Non, non, non. Il y a un gagnant par webinar ? Ah, avant j'avais mal compris. Non mais c'est terrible. Eh bien, on va faire gagner... On va faire gagner quoi. Oh non, non, mais c'est terrible. C'est terrible, c'est terrible. Je vais décevoir tout le monde. Allez, on va faire gagner Ludovic parce qu'en plus, il a posé plein de questions. Voilà, donc j'ai cru la question sur... On peut utiliser d'autres langages, donc Golang. Pour l'ensemble de son œuvre, Ludovic a gagné pour ce webinar. Qu'est-ce qu'il a gagné, Hugo ? On verra. Il a gagné notre considération, déjà. Il a gagné le droit de rester pour le deuxième webinar. Et puis, je pense qu'on a des goodies, c'est ça ? Ouais, on a des goodies. Donc, voilà. Bravo, Ludovic. Et merci pour toutes les questions. Voilà, on fait une petite pause de 5 minutes et on... Le temps de boire un verre d'eau ? 3 minutes ? C'est intensif. Alors, 3 minutes et puis on attaque sur le deuxième webinar. Merci beaucoup et à tout de suite.