Developper et deployer des applications Serverless

Transcript

Bonjour à tous, à nouveau. Je vous propose d'enchaîner sur le deuxième webinaire serverless de l'après-midi. Après l'introduction au serverless et à Lambda, on va maintenant voir comment développer pour de vrai sur Lambda avec des outils open source et comment automatiser le déploiement. Je vais profiter de l'occasion, comme reInvent est encore relativement frais, pour parler de quelques nouveautés importantes qui sont sorties autour de Lambda. Ensuite, on va parler d'outils qui vont simplifier le développement d'applications serverless. On va enchaîner une série de démos avec trois frameworks open source. Un qui s'appelle le Serverless Framework, un deuxième qui s'appelle Gordon, et un troisième qui s'appelle Chalice, qui est un projet open source AWS. Je mentionnerai également d'autres outils, il en existe un certain nombre et ça continue à sortir, il y a un écosystème de développement relativement riche autour de Lambda. Je vous donnerai toutes ces infos. Ensuite, on verra comment simplifier le déploiement d'applications serverless. On a vu tout à l'heure comment le faire avec la ligne de commande, mais de manière, admettons-le, sans doute un peu primitive. AWS a annoncé une évolution de CloudFormation qui s'appelle le Serverless Application Model qui permet de grandement simplifier le déploiement d'applications serverless contenant des fonctions Lambda et d'autres ressources. Allons-y pour les quelques nouveautés un peu en vrac, mais je pense que ça peut vous intéresser si vous n'avez pas eu le temps de suivre tout ce qui a été annoncé à reInvent. Le premier point qui est sans doute le feature le plus réclamé sur Lambda dès le premier jour, enfin je me souviens des premières sessions que j'ai faites autour de Lambda, et les gens hurlaient sur le fait qu'on ne pouvait pas définir de variable d'environnement dans Lambda. Voilà, ça y est, on vous a entendu, on peut avoir des variables d'environnement dans Lambda. Pourquoi c'est important ? Imaginez que vous ayez envie de déployer la même fonction Lambda et de la tester dans des environnements différents, en dev avec un bucket et une table DynamoDB de dev, et puis vous voulez ensuite tester avec de la pré-prod et de la prod, etc. C'était compliqué d'arriver à passer un paramètre à une fonction Lambda. Tout le monde rajoutait un document, une variable dans le document JSON, c'était quand même une façon assez sale de le faire. Et voilà, avec les variables d'environnement, on peut passer des informations, des secrets, plein de choses aux fonctions Lambda. Un autre point, j'ai vu des questions tout à l'heure sur le sujet, je n'y ai volontairement pas répondu, puisque je savais que j'avais ce slide qui arrivait. Maintenant, vous avez également la possibilité de faire de l'intégration et du déploiement continu autour de vos applications serverless. Ça s'appuie sur deux choses : CodeBuild, qui est un service de build manager lancé à reInvent et qui supporte notamment les applications serverless. Vous pouvez builder tout ce que vous voulez, du Java, du Docker, toutes les technos qu'on supporte, et vous pouvez aussi packager des applications serverless. Et puis vous pouvez les déployer avec CloudFormation, en particulier en utilisant le Serverless Application Model dont je vais parler tout à l'heure. Donc, vous pouvez développer de manière assez industrielle et automatique et faire du déploiement continu comme vous le faisiez sur des instances EC2 par exemple. Le troisième point, c'est une feature de plus bas niveau, mais qui est elle aussi très utile, qui s'appelle les dead letter queues. Auparavant, lorsqu'une fonction Lambda échouait, que ce soit pour une erreur technique ou pour un timeout, elle était réessayée automatiquement deux fois. Et si au bout de trois exécutions, l'appel n'avait toujours pas réussi, on abandonnait et on perdait finalement cet événement. Maintenant, vous avez la possibilité de définir ce qu'on appelle une dead letter queue et de l'associer à votre fonction Lambda. Cette fois, au troisième essai infructueux, au lieu de jeter l'événement, celui-ci va être écrit dans la dead letter queue. Donc, il peut être soit une queue SQS, soit un topic SNS. Et donc, vous ne perdez plus d'événements, même en cas d'erreur d'exécution, même en cas de timeout sur votre Lambda, vous empilez soit dans SQS, soit dans SNS, tous les échecs, et vous pouvez aller les inspecter après, pourquoi pas avec une autre fonction Lambda, pour faire du monitoring, du debug pour aller voir pourquoi ces fonctions ont échoué. Donc, un mécanisme très intéressant pour avoir la certitude de ne pas perdre d'événements même en cas d'erreur. Et puis Step Functions, que j'ai très rapidement évoqué tout à l'heure. Step Functions, c'est la capacité à orchestrer des fonctions Lambda. On parlera certainement dans un webinaire plus en détail un peu plus tard. Auparavant, certes, vous pouviez chaîner vos fonctions Lambda en les faisant s'invoquer explicitement, ou vous pouviez les interfacer par Kinesis, ou par une base de données DynamoDB, avoir des trieurs comme je l'ai montré tout à l'heure, mais ce n'est pas forcément un modèle très clair. Si on a vraiment des données à s'échanger, très bien, on peut se les échanger par Kinesis ou par Dynamo. Mais si c'est juste pour synchroniser l'exécution des Lambda, c'est un peu inélégant. Et donc, c'est le problème que résout Step Functions. Il va vous permettre de définir des ordres d'exécution, des ordres en série, des ordres en parallèle. Vous allez définir ce workflow, cette majeure, finalement vous allez la définir graphiquement dans la console AWS. Donc, si vous avez une application complexe avec des workflows qui implique plusieurs Lambda et que vous étiez un peu en peine de les synchroniser efficacement, je vous conseille de regarder Step Functions, ça va certainement résoudre pas mal de problèmes de votre côté. Voilà, il y a d'autres features et je voulais juste citer ces trois ou quatre là qui sont vraiment importants à mes yeux, qui étaient très attendus et qui méritent d'être intégrés tout de suite dans vos applications Lambda. Alors attaquons la partie framework à proprement parler. On commence par le développement, donc comment se simplifier le développement. Tous les exemples de codes que je vous montre sont disponibles sur GitHub si vous voulez reproduire tout ça ensuite. Alors juste, on l'a vu il y a peu de temps, mais au cas où de nouvelles personnes nous aient rejointes, voilà le workflow classique de développement. Vous allez développer votre fonction. La plupart du temps, vous allez mettre une API devant. Vous allez connecter l'API à la fonction, vous allez l'invoquer et puis vous allez tester, débugger et recommencer jusqu'à ce que ça marche. Ce qu'on a vu dans le premier webinaire, c'est que certes on peut faire ça dans la console, on peut faire ça avec la ligne de commande AWS, mais je dirais pour un développeur, ce n'est pas une expérience forcément très simple, ça impose de comprendre comment marche la ligne de commande AWS. On n'a pas la capacité, comme plusieurs d'entre vous l'ont dit, à tester les fonctions localement. Bref, ce n'est pas une expérience extrêmement sympathique pour un développeur. C'est plutôt orienté Ops et automatisation. Donc ce qu'on va voir maintenant, c'est finalement quelques frameworks qui vous permettent de faire ça de manière plus sympa. Le premier dont je voudrais parler, c'est un framework qui s'appelle The Serverless Framework, dont le nom prête un peu à confusion maintenant. Quand il a été lancé, il s'appelait JAPL, comme les dents de la mer, ce qui voulait dire Just AWS Without Servers. C'est un projet open source qui a été lancé à reInvent en 2015 et initialement qui était basé sur Node.js uniquement, puis le support Python et Java a été rajouté ensuite. Ce qui peut expliquer parfois des petits décalages fonctionnels entre Node et les autres langages. On sent que c'est un framework qui met un peu plus l'accent sur Node, et il est arrivé de tomber sur des options ou des fonctionnalités qui n'étaient pas complètement disponibles en Python et en Java, rien de très grave, je tenais à le préciser. L'objectif de ce framework, c'est de déployer automatiquement et d'exécuter automatiquement vos fonctions Lambda, que ce soit localement ou dans un site. C'est aussi la capacité à déployer automatiquement les sources d'événements qui vont invoquer vos fonctions Lambda, que ce soit des API, des tables Dynamo, etc. Et le tout se fait avec CloudFormation. La bonne nouvelle, c'est que c'est caché, évidemment. Vous n'aurez pas à écrire le template CloudFormation. Vous allez interagir avec une ligne de commande qui est plutôt sympa, plutôt simple. Un petit fichier de configuration YAML pour décrire votre projet, et donc le framework Serverless va se charger de créer un template CloudFormation qui va provisionner toutes les ressources nécessaires. Alors juste pour info, le lien Vimeo qui est sur le slide, c'est la vidéo de lancement de Jaws à reInvent, et je crois que c'est une des meilleures vidéos de lancement de produits que j'ai jamais vue, je vous en dis pas plus. Elle n'est pas très longue, je vous conseille de la regarder. Voilà le Hello World de Serverless. Vous allez créer le projet. On va le faire ensuite. Vous allez le déployer. Vous pouvez d'abord l'invoquer localement pour vérifier que la fonction marche. Le déployer. Vous pouvez le déployer sur différents stages afin de le déployer en test, en dev, etc., en prod, etc. Et puis, c'est tout. Donc, c'est vraiment, c'est à peu près tout ce que vous devez savoir. Si vous retenez `serverless deploy` et `serverless invoke`, vous pouvez travailler avec Serverless. Voilà. Donc, je vous propose de faire un exemple tout de suite. C'est ce qui parlera le plus. Alors, j'ai réussi à augmenter la taille, c'est magnifique, j'espère que c'est un peu plus visible. Donc, en avant pour Serverless. Le projet est déjà créé, donc qu'est-ce que j'ai là dedans ? J'ai une petite fonction en Node qui affiche un message qui fait rien de bien intelligent, mais un petit exemple simple ça fait jamais de mal. Voilà ma fonction Lambda écrite en Node, qui affiche un petit document JSON "Hello World". Et puis j'ai mon fichier de configuration YAML, qui a l'air très long comme ça, mais en fait c'est parce que tout est commentaire. On définit un provider, donc ici AWS et l'environnement Node. Pour info, sur Serverless, avec le Serverless Remover, vous pouvez déployer sur d'autres plateformes qu'AWS. Ça peut être intéressant dans certains cas. Donc mon provider, et puis ma fonction qui s'appelle Hello avec son handler, et un event, une source d'événements qui va être une API sur laquelle je vais faire GET. Tout le reste, c'est juste du commentaire. Vous voyez, je définis très simplement le fait que j'ai une fonction et devant, je vais pouvoir faire un GET HTTP. Tout simplement. Et c'est tout. Ok ? Donc, on va essayer de l'invoquer peut-être localement déjà. Alors le nom de la fonction, donc `--local`. `--function`. `--function`... Il ne reconnaît pas l'invocation locale. On va vérifier que je n'ai pas fait une bêtise. Bon, très bien, ça ne marche pas. On va la déployer. C'est moi, je peux faire des outils mais... Non, bon écoutez, magnifique, c'est pas grave, on va la déployer, on pourra tout ça... Donc là c'est une application locale, vous avez vu, j'ai pas déployé la fonction, je l'exécute localement. Elle est toute simple, elle est toute basique, elle n'utilise pas de service. La limite de ça, c'est évidemment si vous utilisez S3, Dynamo, etc. Soit vous avez des API de mock pour exécuter en local, soit vous appelez des ressources AWS de test. Bien évidemment, vous pouvez pas faire tourner tout AWS sur votre poste. Donc on va la déployer. Voilà, ça va nous suffire. Et donc là, il va packager l'ensemble, et si j'arrive à aller suffisamment vite dans CloudFormation et que j'arrive à recharger, voilà, je vois que j'ai un stack qui est en train de s'exécuter et qui va créer la fonction et l'API. On va juste attendre deux minutes. Qu'est-ce qu'il me raconte ? Il est en train d'uploader, il va faire ce qu'on a fait à la main tout à l'heure, c'est-à-dire créer un fichier zip avec la fonction. La différence ici, c'est qu'au lieu d'appeler juste la ligne de commande, il va exécuter un template CloudFormation. On voit toutes les ressources qui sont créées ici, un bucket pour l'upload, un role pour la fonction, l'API. Voilà, Create Complete, le rôle, ça va être assez bon. Allez, encore un petit effort, et on y arrive. Voilà, c'est le premier appel. Le premier appel est plus long parce qu'il crée tout ça. Quand on met la fonction à jour ensuite, c'est plus rapide. Les permissions pour la fonction Lambda. Et donc, évidemment, si je vais dans la console Lambda, je dois voir ma fonction ici. On doit pouvoir voir son code. Voilà, on voit son code. OK, donc le déploiement est fini. On voit que CloudFormation a terminé, et donc Serverless me dit voilà, j'ai fini, et voilà l'API qui a été déployée. Si on l'invoque maintenant, si on fait tout simplement HTTP GET, voilà, je récupère la réponse de l'API. Alors là, j'ai tous les headers, mais surtout, j'ai mon message. Donc vous voyez, de mon point de vue, c'est quand même un peu plus sympa que de se battre avec la ligne de commande AWS. Finalement, qu'est-ce qu'on a exécuté ? On a fait `serverless invoke local` pour tester localement, `serverless deploy` pour déployer, et puis ensuite on invoque l'API comme on invoquerait n'importe quel endpoint HTTP. Et puis si on veut la supprimer, on fait simplement `serverless remove` et on fait l'inverse, donc là si je regarde ce qui se passe dans CloudFormation, je vois qu'il est en train d'effacer toutes les ressources qu'il a créées. C'est aussi un truc sympa, d'être capable d'automatiser la création, mais aussi l'effacement, parce que si vous êtes comme moi, vous cliquez bien dans la console un peu partout, on se retrouve avec des rôles IAM dans tous les coins, des fonctionnalités partout, et on sait plus trop ce qui correspond à quoi. L'utilisation de CloudFormation permet de faire le ménage de manière un peu plus efficace. Voilà, on va laisser finir d'effacer ça. Donc, Serverless, premier framework potentiellement intéressant pour déployer facilement vos API et vos fonctions Lambda avec deux commandes. Deuxième framework, un framework qui s'appelle Gordon, qui est lui aussi un framework open source, qui est sorti à peu près au même moment que Serverless. Il supporte les trois langages canoniques, donc Python, JavaScript, Node, et Java, et il ajoute effectivement comme quelqu'un l'a dit tout à l'heure d'autres langages comme Go, Golang, puis Scala et Kotlin qui sont finalement les autres langages de la JVM. L'intérêt de Gordon, c'est que vous pouvez les mélanger au sein du même projet, donc vous pourriez avoir des fonctions écrites en Python et en Java dans le même projet si ça vous chante. Une fois qu'on a dit ça, finalement Gordon marche à peu près de la même façon que Serverless, il fait la même chose, il va auto-déployer les fonctions, il va auto-déployer les sources d'événements, il va faire tout ça avec CloudFormation et il va se configurer lui aussi en YAML. Donc, c'est juste un autre choix. Alors vous allez me dire quelle différence ? Bon, bah si vous voulez faire du Go, Gordon est là pour vous. Si vous voulez faire du Node ou du Python, mon conseil est d'essayer les deux, et généralement il y en a toujours un qui vous plaira un peu plus que l'autre. On va faire le Hello World de Gordon comme ça vous verrez que c'est très proche, et puis vous vous ferez votre propre avis. Voilà, Serverless a fini de nettoyer. Allons voir Gordon. C'est vraiment hyper comparable. Voilà les settings. Ici, une fonction Lambda et une API qui est un POST ici qui va être devant la fonction, mais voyez que c'est du YAML et c'est vraiment très similaire. La fonction est en Python, histoire de changer. Donc en avant. On va faire dans un premier temps `gordon build`. Il va construire le projet. On va pouvoir tester localement. Alors là, cette fois, ça se passe de manière un peu différente. Je vais essayer de ne pas faire de coquilles. Donc on lui passe un petit document JSON. Voilà. Voilà. Je vais invoquer la fonction localement en lui passant ce document. On peut tester localement les fonctions avant même de les avoir déployées. On peut les déployer. Et comme tout à l'heure, voilà, je vois dans CloudFormation ma stack qui s'exécute. C'est vraiment similaire. Et si je vais dans Lambda, c'est peut-être un peu tôt pour voir déjà la fonction. Vous voyez que l'autre a été effacée. Et donc là aussi, comme tout à l'heure, il va créer les ressources et il va faire tout le boulot à notre place. Donc moi j'aime bien cette vision des choses, j'aime bien le fait que ça s'appuie sur CloudFormation, parce qu'effectivement c'est une garantie de reproductibilité dans différentes régions, c'est une garantie d'effacer proprement toutes les ressources, mais en même temps j'aime bien le fait de ne pas avoir à écrire le template et que tout soit généré à la place. Donc là, ici, il y a un template pour la fonction, et un template pour l'environnement, et puis un template pour la fonction et l'API qu'il est en train de créer. Donc on va le laisser finir ça, ça ne devrait pas être trop long, et puis ensuite on va l'invoquer. Je vous demande une petite seconde de patience. Allez, m'en donne, voilà, ça devrait se terminer. Et donc ce qui est alors juste pour faire le lien avec ce dont je parlerai tout à l'heure, là en fait on décrit tout ça, on décrit tout ça, donc la formation, mais vous voyez on utilise les ressources finalement habituelles, on utilise l'AWS Lambda Function, l'AWS API Gateway, et c'est donc on utilise des concepts existants, donc la formation, mais on les rassemble sous un même chapeau, on n'a pas la notion d'application serverless, c'est ça que ça ne va résoudre tout à l'heure. Voilà, donc la stack est terminée, et donc on doit pouvoir maintenant faire un POST sur cette URL en n'oubliant pas de donner le nom `name=gordon`. Voilà, ok, donc là, comme tout à l'heure, on appuie, on déploie, on peut l'invoquer, on peut la tester, etc. Ok, donc après, lequel des deux, lequel vous préférez, c'est votre libre choix. Testez les deux, il y a peut-être des nuances entre les sources d'événements qui sont supportées, il est possible qu'il y ait des petites différences entre Gordon et Serverless. Et puis pareil, comme tout à l'heure, on délette, on fait le ménage proprement et on supprime toutes les ressources qu'on a créées. Donc voilà Gordon. Alors là, je vous le montre avec juste une source API, mais il y a plein d'autres sources possibles, Dynamo, S3, je vous laisserai explorer tout ça. Alors le troisième, le dernier dont je voudrais parler en termes de dev, c'est donc ce framework qui s'appelle Chalice, qui est un projet open source AWS, qui est encore assez récent, qui est toujours en bêta et dont la première version est sortie au mois de juillet. Il est relativement différent des précédents. Les précédents étaient d'une part multilangage, et d'autre part généraliste dans le sens où rien ne vous obligeait à créer des API. Vous pouviez juste déployer des fonctions et c'est tout. L'objectif de Chalice, c'est d'être l'équivalent de ce qui est Flask pour les applis web en Python. C'est-à-dire un framework très léger, très simple à utiliser, avec le minimum de configuration, et vous allez le voir, il y a zéro config lorsque vous voulez déployer un service avec Chalice. Il ne fait qu'une seule chose, c'est ça. Il fait des web services en Python, mais il le fait bien et il le fait de manière super simple. Certes, le projet est encore en bêta, mais il est intéressant, j'espère qu'il évoluera dans la bonne direction. Il va tout créer automatiquement. Il va créer l'API devant la fonction. Il va autogénérer la policy IAM en fonction des appels de SDK que vous faites dans la fonction. Ça, c'est une fonctionnalité que je trouve super. Bien sûr, vous aurez peut-être envie de customiser la policy ensuite, mais au moins, vous avez un bon point de départ autogénéré. Il est capable d'exécuter les fonctions localement sur le port 8000, un peu comme Flask pour ceux qui l'ont pratiqué, on va le tester. Donc il est rapide, il est très léger, il n'utilise pas CloudFormation, donc il fait uniquement des appels de SDK. Donc moralité, il va vite, il n'y a pas cette petite latence liée à CloudFormation. L'inconvénient, c'est que d'abord il ne peut pas créer les event sources, donc si vous avez besoin d'une table de DynamoDB, ou d'un bucket, etc. Vous devez les créer en dehors. Et ils ne supportent pas la suppression des ressources. Donc vous allez me dire, c'est quand même embêtant, oui. Bon, ça n'est qu'une version bêta, je ne doute pas que ça arrive. Mais une fois de plus, je pense que Chalice devrait intégrer le framework SAM, donc je vais parler tout à l'heure. Donc voilà, gardez un œil. Je ne sais pas si je m'en servirais pour faire de la prod sans doute pas, mais en tout cas je garderai un œil dessus, je pense que c'est quelque chose qui pourrait évoluer vraiment dans la bonne direction. Alors on va le tester. Alors j'ai un Hello World, on va peut-être pas faire un troisième Hello World, je vous laisserai le tester. J'ai un autre exemple qui est un peu plus significatif où je déploie un web service qui me permet de faire PUT et GET dans un bucket S3. Je vous propose de faire cet exemple-là. Allons-y. Rejetons un œil au code. En Python. Donc qu'est-ce qu'on fait ? On crée un client S3 qui va lire et écrire dans un bucket public. Et puis, là, on déploie exclusivement les web services. Donc ceux qui ont fait du Flask en Python ou du Sinatra en Ruby devraient vite comprendre de quoi il s'agit. Donc on définit une route, une URL qui va être scellée, slash la clé de l'objet dans S3. On accepte GET et PUT sur cette route. Et puis que fait cette API ? Sans surprise, si on fait un HTTP PUT, on va écrire l'objet dans S3. Si on fait GET, on va faire... Si on fait HTTP GET, on fera GET dans S3 tout simplement. Voilà la fonction, voilà le service plus exactement. On va déployer. Le requirements, c'est le fichier Python qui dit quelles sont les dépendances de l'application. Ici, j'ai uniquement besoin de Boto3, donc du SDK AWS. Très bien. Donc, jetons un œil à la ligne de commande. Pour l'instant, assez peu de choses. C'est un service qui est plutôt simple et encore en bêta, comme je l'ai dit tout à l'heure. Donc, on va déjà le démarrer en local. Voilà. Donc là, il y a... est démarré en local sur mon instance. Je vais le mettre en tâche de fond. Et donc là, je peux faire si je fais HTTP, on pourrait stocker un objet. Qu'est-ce qu'on a comme exemple ici ? On va faire ça. Donc HTTP PUT donc là en local sur le port 8000. Et on a un préfixe qui s'appelle Object. C'est bien ça si je n'ai pas de bêtises. Oui, on va donner un document. Document1 en JSON. Et puis on va écrire dedans n'importe quoi. Value1 égale 1, 2, 3, value2 égale 4, 5, 6. Voilà, donc là, j'ai fait un appel en local sur mon API. Elle a stocké dans S3 ce document. D'ailleurs, si j'allais voir dans S3... On devrait voir ce document. Dépêche-toi S3. Donc J-Cimon Public, le voilà. Voilà, document1.json, c'est celui que je viens de créer là. Bon, je pourrais évidemment faire un GET. Voilà, cette fois juste ça, et je récupère le document qui en reste. Donc ça c'est déployé localement. On va tuer ce déploiement local et puis on va le déployer maintenant en vrai. Ah, qu'est-ce que j'ai oublié de faire ? Ah oui, je sais ce que c'est. C'est pas grave, on va faire un nouveau projet. Comme ça, vous verrez ça. Donc c'est `new-project`. Voilà. Ok. Je vais récupérer juste mon code. Ok, c'est reparti. Donc, `chalice deploy`. C'est très bien. Comme ça, on voit le... ce que je vous disais tout à l'heure. Donc là, il regarde, il évalue, il analyse ce que fait mon code et en fonction des appels de SDK qui sont faits, il va générer une policy IAM. Et donc on voit ici qu'il me propose une policy où j'ai le droit de faire GET et PUT sur S3. Et puis bon, il y a les actions sur les logs pour que la fonction Lambda ait le droit de créer son log dans CloudWatch, etc. Alors c'est un bon point de départ, vous voyez ce que je disais tout à l'heure, là il a le droit de faire GET et PUT sur tous les buckets S3, bon c'est sans doute pas souhaitable de garder ça dans un environnement réel, mais en tout cas pour commencer, pour tester, c'est pas mal. Ensuite, vous pouvez spécialiser la stratégie IAM pour qu'elle soit plus restrictive. Voilà, donc là, il va pas faire de CloudFormation, si je regarde ce qui se passe dans CloudFormation, voilà, vous voyez bien qu'il n'y a pas de CloudFormation là, il fait des appels SDK directement. Ok, et donc du coup, il est plus rapide, il a cette fonctionnalité l'issue URL qui est sympa, qui manque aux autres frameworks, de récupérer simplement quel est l'endpoint de l'API tout simplement. Donc on va maintenant faire ça. Ok, il n'y a pas d'espace en trop, parfait. On va faire document2 pour le sport. Voilà, on va vérifier dans S3 qu'on a récupéré notre document. On va faire GET en attendant. Voilà, ça a l'air pas mal. Et si je vais voir dans J-Cimon Public, je dois voir mon document2. Voilà, qui est là. OK. Bon, donc voilà, vous voyez, moi j'aime bien la ligne de commande de Chalice, elle est simple, elle est sympa, j'aime bien faire du Python, j'aime bien faire du Flask, donc vraiment je suis assez fan de ce projet. Néanmoins, il est encore jeune, il est encore en bêta, et c'est compliqué de le recommander pour de la prod. Gardez l'œil dessus, je pense qu'il va continuer à s'améliorer. Donc en résumé, on a vu trois frameworks de développement. Serverless, qui est sans doute le plus populaire, qui marche bien, qui a été conçu pour Node.js, qui supporte Python et Java, mais your mileage may vary, moi il m'est arrivé d'avoir des soucis, c'est peut-être réglé dans les dernières versions. Beaucoup de features, beaucoup de sources d'événements, mais si votre truc, c'est de faire uniquement du développement web, bon, Serverless n'est pas un framework web, c'est vraiment un framework de déploiement de Lambda et de sources d'événements. Gordon est à mon avis un très bon challenger, il supporte des langages en plus. J'ai oublié Kotlin qui n'est pas là. Il me paraît comparable en termes de features, bon, je n'ai pas fait une matrice précise de toutes les sources d'événements, mais j'ai l'impression qu'il y a à peu près autant de choses sur Gordon. Les deux sont basés sur CloudFormation. Voilà, à vous de les tester, à vous d'utiliser celui que vous préférez. Et puis donc Chalice, le projet AWS, un peu jeune, encore en bêta, qui ne fait qu'une seule chose, mais à mon avis, il a fait vraiment très très bien et de la manière la plus simple possible, c'est-à-dire déployer des applis Python, des web services Python avec une philosophie comme de type Flask, et vous voyez que vraiment sans aucune config, sans fichier YAML, sans policy IAM, sans rien du tout, on arrive à déployer en un appel son web service Python. Je suis assez preneur de ce framework, j'espère qu'il va bien évoluer. Il y en a plein d'autres, je suis obligé de les mentionner. Il y a initialement le premier, c'était Kappa, Kappa qui était intéressant parce qu'il était développé par l'auteur de Boto et de la ligne de commande AWS. J'ai l'impression que le projet est plus très actif. Je ne sais pas s'il est vraiment encore maintenu. Il était 100% Python. J'ai l'impression que c'est un projet un peu en stand-by. Ensuite, il y a un autre framework qui s'appelle Apex, qui est intéressant, qui est comparable à Gordon et Serverless, qui supporte aussi Golang. Et lui qui a fait le choix de Terraform pour la gestion de l'automatisation, donc il n'utilise pas CloudFormation, il utilise Terraform, qui est un framework de HashiCorp pour l'automatisation. Voilà, puis il est très intéressant aussi. Donc si vous êtes plutôt Terraform, eh bien pourquoi pas utiliser Apex ? Alors il y a Zappa, qui est un framework Python, qui a la même approche que Chalice. Alors l'auteur de Zappa dirait que c'est Chalice qui a la même approche que Zappa. Je ne vais pas rentrer dans cette discussion. Mais en tout cas, c'est la même approche, c'est-à-dire on ne fait qu'une chose, on déploie du Python en webapps. On fait des choses simples, mais on le fait de manière très efficace. Donc si vous avez besoin de faire de la production sur des web services Python, Zappa, qui est plus abouti que Chalice à l'instant T, peut être une option. Je vous incite à le regarder. Et puis le dernier, c'est un projet qui s'appelle Docker Lambda, qui est un petit peu différent, qui fournit des images Docker qui permettent de répliquer, et je mets des guillemets autour de ça, l'environnement d'exécution Lambda. Donc ça vous permet d'exécuter localement sur votre machine un container Lambda dans lequel vous allez charger votre code Lambda, et vous allez l'exécuter de la manière la plus proche possible de l'environnement de production. Voilà, c'est un projet intéressant qui peut résoudre pas mal de soucis pour tester localement et justement éviter le maximum d'avoir un décalage entre le test en local et le test en vrai dans la prod en Lambda. Donc, plein d'outils à essayer. Quelques autres, j'ai parlé du plugin Eclipse tout à l'heure, le plugin Eclipse permet de déployer facilement vos applications Java dans AWS. Et puis un autre qui s'appelle le serverless-java-container qui lui vise à encapsuler du code Java legacy et à l'exécuter tel quel. Donc il y a une implémentation de HTTP servlet qui vous permet de prendre votre code Java servlet existant, de le passer à ce framework et de l'exécuter à l'intérieur de Lambda. Alors, je n'ai pas eu le temps de l'essayer encore, c'est un projet assez jeune, mais c'est un projet qui me paraît intéressant pour commencer à migrer vos applications Java anciennes vers, pourquoi pas, vers Lambda, API Gateway, etc. Donc, voilà pour le développement. Pour résoudre ce problème, on a réalisé en novembre une spécification qui s'appelle le Serverless Application Model. Vous l'avez peut-être connu sous le nom de Project Flourish, on a communiqué dans différentes conférences avec ce nom pendant un moment. Ce projet est une extension de CloudFormation qui permet de regrouper sous une même définition de CloudFormation les fonctions Lambda, les API et les events. Ça permet d'avoir des définitions beaucoup plus simples, propres et moins verbeuses qu'auparavant. On introduit trois nouveaux types de ressources : serverless function, serverless API et serverless simple table. Simple table est une table DynamoDB avec un seul index. Deux commandes CloudFormation supplémentaires pour packager et déployer. Comme je l'ai dit tout à l'heure, ce modèle est maintenant intégré avec CodeBuild et CodePipeline. Vous pouvez faire de l'intégration et du déploiement continu sur vos applis serverless avec SAM et CodeBuild et CodePipeline. Je m'attends, c'est juste mon avis, à ce que SAM soit intégré dans les frameworks open source. Ça paraîtrait assez logique de profiter de cette spec et d'avoir un moyen unifié de déployer. Donc, concrètement, ça va ressembler à ça. On va faire un petit exemple ensuite, mais on va regrouper de manière assez compacte une fonction, son API, sa table DynamoDB, et d'autres ressources arriveront au fur et à mesure de l'évolution de la spec. Ça remplace ce qu'on voulait faire avant en CloudFormation avec les ressources antérieures, et on passe de 15 à 10 lignes à des dizaines de lignes plus ou moins compliquées en référençant les ressources les unes les autres. Vous voyez, il y a une amélioration de l'expérience de développement qui est assez nette. L'aspect est sur GitHub, sous licence Apache, donc vous pouvez contribuer, n'hésitez pas, s'il vous manque des choses, à envoyer des idées de features et des modifications sur le projet GitHub. On veut faire vivre ce projet dans la communauté des développeurs Lambda. On va faire une petite démo. On va sortir de là. Ah oui, puisqu'on était dans un container. C'était une surprise. On va aller voir ça. On a une fonction Lambda. On va jeter un œil. Qui fait quoi ? Qui va recevoir un événement, faire une somme de value 1 et value 2, rajouter le résultat dans l'événement, rajouter un timestamp dans l'événement, et écrire dans une table DynamoDB. Qui écrit l'ensemble dans cette table. Vous voyez que je récupère le nom de la table avec une variable d'environnement qui s'appelle tableName et que j'accède via le package OS de Python. Donc, on a les variables d'environnement, et tout ce que j'implique là fait soit partie de la librairie standard de Python, soit du SDK, donc je ne vais pas l'uploader en même temps que ma fonction. Je vais me contenter d'envoyer juste ce petit bout de code, et tout ça est préinstallé dans l'environnement Lambda. Donc, une Lambda qui prend un événement avec deux valeurs, fait la somme, rajoute un timestamp, écrit le résultat dans l'événement, et écrit tout dans DynamoDB. Mon fichier YAML, mon petit bout de CloudFormation en YAML, qui définit quoi ? Qui définit ma fonction avec les propriétés qu'on s'attendrait à trouver. Une policy IAM Amazon DynamoDB Full Access. Vous allez me dire que ce n'est pas très restrictif, c'est vrai, mais c'est un petit exemple. La variable d'environnement tableName qui va contenir le nom de ma table DynamoDB qui va être créée en dessous, et un event qui va être une API. Je vais simplement faire un POST sur mon API et déclencher le traitement. Voilà, puis là je crée ma table DynamoDB avec une primary key qui est l'identifiant, qui est le timestamp, et la capacité provisionnée. Rien de bien méchant. Un petit bout de CloudFormation SAM. Mon script de déploiement. Comme d'habitude, je vais zipper ma fonction, la copier dans le bucket S3 parce que le déploiement va se faire à partir de là, et puis j'appelle les deux nouvelles commandes dont je vous ai parlé tout à l'heure : cloudformation package qui va créer le template complet pour le déploiement de cette fonction avec le nom du bucket, etc., et puis deploy qui va faire le déploiement à proprement parler. On va se préparer la console CloudFormation, l'API Gateway qui est là aussi, Dynamo qui est là, ok, on a tout ce qu'il nous faut. En avant. Voilà, donc j'ai fait le packaging et ensuite voilà, là j'ai lancé la création de l'application. Si je recharge là, je ne devrais pas tarder à voir ma stack qui s'exécute. Ah, je l'ai peut-être lancé dans l'autre région, ce n'est pas grave. Est-ce que je l'ai lancé en Irlande ? Oui, je l'ai lancé en Irlande, ce n'est pas grave. Et donc là, je vois... Je vois les différents événements, je vois le rôle de la fonction Lambda, je vois la table DynamoDB. Voilà, est-ce qu'on va passer en Irlande ici aussi ? Voilà, je vois ma table qui a été créée automatiquement, avec un nom autogénéré. Pour l'instant, évidemment, elle est vide. Tout ça est prêt. L'API ne devrait pas être loin. Voilà, ok, donc mon API est en cours de création, elle n'est pas encore déployée. Voilà, ça a l'air d'être terminé. Ok, je devrais voir mon API. Hop, voilà. Et je devrais avoir mon stage. Prod. Ah, mais lui, il déploie en prod par défaut. Pourquoi pas. Ok, donc vous voyez, c'est terminé. Et donc là, j'ai créé automatiquement, grâce à SAM, ma fonction, son rôle, la table DynamoDB et l'API. Donc, on va l'inviter. En avant, je vais HTTP host. Le endpoint. Alors... 4, 5, 6. Alors, il y a une erreur d'exécution, mais c'est normal. C'est parce que je n'ai pas géré proprement le code de retour de l'API. Mais normalement, si je vais voir dans Dynamo et que je recharge... Voilà, magnifique ! Je vois, donc ça, c'est mon timestamp que j'ai ajouté dans l'événement, et puis là je vois tout mon document de JSON, et puis je vois le résultat de mon calcul. 1, 2, 3, plus 4, 5, 6, ça a l'air de faire 579. Donc, vous voyez, une façon assez sympathique de faire du déploiement, en le packagant, en ayant CloudFormation qui gère toute la communication pour vous, et puis en ayant évidemment la capacité à effacer, à faire le ménage proprement. Donc, si je lance le script de défacement, je vais voir CloudFormation faire le chemin inverse et virer proprement toutes les ressources de cette application. Si vous n'avez pas encore commencé à automatiser le déploiement de vos fonctions, vraiment je vous conseille de le faire avec SAM. Vous avez vu, c'est une syntaxe vraiment concise, bien moins verbeuse et bien plus simple que ce qu'on pouvait faire avant avec les ressources traditionnelles de CloudFormation. Une fois de plus, n'hésitez pas à contribuer à l'évolution de la spec sur le projet GitHub. Les quelques ressources, bon, je les ai déjà mentionnées tout à l'heure, mais si les personnes nous rejoignent, je me permets de leur parler. Mon collègue Danilo qui a écrit un excellent bouquin sur Lambda qui est tout neuf, qui est sorti en décembre. Je veux vraiment, une fois de plus, si vous cherchez à bien débuter sur Lambda, je vous conseille fortement son livre. Et je dis pas ça parce que c'est mon collègue, je dis ça parce que c'est vraiment un bon livre. Tout un tas de vidéos Lambda de re:Invent avec les nouveautés et Step Functions beaucoup plus en détail que ce que j'ai mentionné, et puis des informations sur les nouveaux services autour de Lambda comme Greengrass. Nos user groups partout en France, bientôt sur la côte d'Azur. Si vous êtes dans une ville et que vous n'avez pas de user group et que vous avez envie d'en démarrer un, je serais ravi de discuter avec vous. N'hésitez pas à me contacter par mail ou sur Twitter. Voilà, j'en ai terminé. Je vous remercie d'avoir été encore nombreux à nous écouter. Hugo, tu m'as affiché le sondage ? Alors, le sondage de satisfaction, attention, de 1 à 5, 5 vous êtes très contents, 1 vous êtes très mécontents, ne vous trompez pas, la meilleure note est 5, la plus mauvaise est 1. Voilà, je vous laisse quelques instants pour voter, et puis ensuite on répondra à vos questions. Et on aura encore un gagnant de la meilleure question, alors en avant. Et pendant que vous votez, je voulais juste attirer votre attention sur deux ou trois choses. Sur notre page événements que vous connaissez sans doute, vous retrouverez la liste de tous les événements à venir, les prochains webinars, le premier au Sunday de l'année qui aura lieu à Paris le 24 février, le salon du Big Data où seront présents les 6 et 7 mars, et vous pouvez déjà noter sur vos tablettes le Summit 2017 qui aura lieu le 27 juin. Et en complément, dans le cadre du salon du Big Data, j'anime demain après-midi à 15h30 un webinar sur vos services d'intelligence artificielle, donc Lex, Poly Recognition, avec des démos assez sympas. Vous pouvez participer gratuitement à ces webinars, allez sur l'URL qui est là, donc bigdataparis.com slash webinar.html, connectez-vous à 15h30 et vous verrez ces démos. Si vous vous intéressez au sujet d'intelligence artificielle et que vous voulez voir un peu ce qu'AWS a annoncé récemment sur le sujet, c'est une bonne façon de commencer. Les démos sont assez rigolotes. Voilà, je pense que tout le monde a eu le temps de voter, Hugo. Et on peut commencer à... On peut commencer... Alors, je vais mettre ça parce que j'anticipe plein de questions sur ça. Ok. Allez, il me faut plus de questions, il y en a quelques-unes là, mais il y a des serial questionnaires. Est-ce qu'il y a un prix du participant qui pose le plus de questions ? Je ne sais pas, mais c'est bien, posez toutes vos questions, on est là pour ça. Alors, en vrac, question de Gauthier, quelle est ton opinion sur le framework Zappa ? Zappa, c'est, en deux secondes, c'est microservices Python en serverless. Je pense que c'est un bon framework. Il est plus complet que ce que Calice est aujourd'hui. Donc, si je devais choisir là un framework pour faire de la prod, là aujourd'hui je prendrais sans doute Zappa, avec la petite inquiétude que sans doute à terme j'aurais quand même envie, si Calice devient un truc complet, j'aurais sans doute envie de migrer sur ça. Je pense que l'attraction finira par être plus forte sur Calice que sur Zappa. Néanmoins, Zappa fait beaucoup de choses aujourd'hui que Calice ne sait pas faire. J'ai une bonne opinion de Zappa, je vous encourage à le tester. Alors, à quand le langage PHP dans Lambda ? J'étais étonné de ne pas la voir tout à l'heure celle-là. C'est ce que j'ai dit en rigolant, enfin en rigolant, oui, c'est pas drôle, mais c'est ce que j'ai dit en rigolant quand il y a eu l'annonce de C-Sharp à re:Invent, j'ai dit que je sentais une grande perturbation dans la force PHP et Ruby. Bon, je sais que vous attendez tous vos langages respectifs dans Lambda. Je pense qu'il y aura des nouveaux langages en 2017. Je ne sais pas lesquels arriveront en premier. On a une liste de langages relativement longue dans nos SDK. Il ne serait pas illogique qu'à terme, on ait la même liste de langages supportés dans Lambda. Bon, voilà. C'est un langage moi, mais j'ai espoir pour 2017. Est-ce que l'API Gateway est gratuit avec Lambda ? Non, est-ce qu'il y a un niveau d'usage gratuit sur l'API Gateway ? Oui, donc pour mémoire sur Lambda, c'est un million d'appels par mois. Sur l'API Gateway, c'est pareil, donc on a 1 million d'appels d'API gratuits par mois. Donc, le niveau gratuit, c'est 1 million d'appels API et 1 million d'appels Lambda. Quid des tests unitaires pour les fonctions Lambda ? C'est une bonne question. Si vous faites du Java, dans Eclipse, que je vous ai montré tout à l'heure, il y a le plugin Eclipse, et donc vous pouvez faire du JUnit sur vos Lambda. Si vous avez un serveur d'intégration continue avec du JUnit, vous installez un des frameworks que j'ai montré qui fait de l'invocation locale et il n'y a pas de soucis. La limite, c'est ce que je disais tout à l'heure, c'est que vous n'avez pas tous les services managés à disposition. DynamoDB est un mauvais exemple parce qu'il y a une version locale de DynamoDB, qui est restreinte mais qui permet quand même de faire des tests. Mais si vous avez besoin de Kinesis ou d'autres services, évidemment vous ne les avez pas localement. Mon conseil c'est d'avoir un guide d'infra AWS qui vous sert à faire ces tests ou alors d'avoir des mocks avec l'API AWS et des adapteurs locaux en dessous. Il n'y a pas d'habitude de tests unitaires dans ces frameworks, mais à partir du moment où on lit des commandes, vous pouvez invoquer les Lambdas localement en leur passant des éléments de JSON, etc. Je pense que vous pouvez réussir à faire des trucs. Pour le déploiement, il y a CodeBuild et CloudFormation qui vous permettent de faire du déploiement aussi. Comment on mesure le temps d'exécution d'une fonction ? Le temps d'exécution de la fonction vous le voyez dans CloudWatch Logs que je vous ai montré tout à l'heure. À chaque appel de fonction, vous voyez le temps d'exécution de la fonction elle-même et le temps d'exécution de votre code, donc l'arrondi aux 100 millisecondes supérieures. C'est vraiment entre le point d'entrée de votre handler et la fin de votre handler qui est mesuré. C'est l'AWS Lambda qui mesure ça. Les trois frameworks présentés ici sont-ils les plus aboutis à ce jour ? Alors, je vais dire oui, et puis demain quelqu'un va m'envoyer un tweet en disant ah t'as pas parlé de... Alors, ceux-là c'est ce que je connais, je ne fais pas mal de nouvelles sur le sujet, je pense que oui, en tout cas Serverless et Gordon sont clairement les plus aboutis. Si je devais en rajouter un troisième, je pense que Apex, j'ai moins joué avec Apex, mais Apex est également assez abouti. Clairement, Calice, comme je disais tout à l'heure, est encore en bêta et mérite encore beaucoup de boulot. Allez voir les repos sur GitHub, vous verrez le nombre de fork et de star sur Serverless et Gordon, c'est des milliers et des milliers. Il y a une bonne adoption sur ces deux-là, et si vous voulez commencer à bosser avec ces deux-là, je pense que vous ne prenez pas en avant. Apex doit être à peu près au même niveau de popularité. Ces trois-là me paraissent les plus aboutis. Est-ce que créer une stack éphémère est une bonne pratique ? Question d'Antoine. Moi j'ai envie de dire oui. Je pense que si vous faites du AWS et que vous n'utilisez pas CloudFormation, je pense que vous manquez, vous passez à côté de 50% du truc. Pourquoi ? Parce que CloudFormation c'est vraiment un des fondements d'AWS, c'est la capacité à déployer de manière prévisible, réplicable dans n'importe quelle région et d'effacer proprement toute votre infrastructure. Donc, je pense qu'il faut vraiment, si vous ne faites pas du CloudFormation aujourd'hui, je pense que vous passez à côté d'une grande partie de la flexibilité d'AWS. Je sais que ce n'est pas facile d'apprendre CloudFormation, c'est un peu mieux maintenant qu'il y a YAML et qu'on n'a pas de JSON, mais vraiment il faut faire cet effort. Je pense qu'il faut, dans des pipelines de déploiement continu, automatiser avec CloudFormation. Je ne peux pas imaginer qu'on le fasse autrement. Ça vous garantit que vous créez un environnement propre, ça vous garantit qu'il est détruit après utilisation. S'il faut le recréer, pas de problème, vous le recréez à l'identique. Vraiment, tout ça me paraît important pour avoir des environnements déterministes à un état connu et dont la qualité peut être vraiment mesurée. Plutôt que des environnements de tests qui durent des jours et des semaines, qui ont été bricolés par tout le monde et qui sont dans un état parfois déplorable. Alors, un exemple, alors c'est un peu à peu près la même question, je vais faire d'une pierre deux coups, sur des références clients autour d'Archi Serverless. J'en ai mentionné tout à l'heure, on pourrait aller voir le site serverless.com. Je ne sais pas s'il y a des références clients. Voilà, section Enterprise. C'est un projet qui a énormément de traction. Il y a vraiment des exemples. Il y a peut-être des use cases à regarder là. Mais c'est un projet qui a énormément de traction. J'ai des noms de clients qui utilisent les architectures serverless, Lambda, API Gateway. J'en ai mentionné quelques-unes tout à l'heure. Adroll, qui est dans la pub aux US et qui a une dizaine de milliards d'appels par jour, c'est sans doute un des plus gros. Il y en a plein d'autres, je pourrais vous les citer, mais je préfère que vous alliez les lire tranquillement sur notre site. Tout ça, ce n'est pas du gadget, ce n'est pas du... On va aller voir le nombre d'étoiles sur GitHub. Ce n'est pas du tout de la R&D fumeuse. Vous voyez donc à la serverless, c'est 1200 forks qui est 14 000 stars sur GitHub. Donc, c'est très très très utilisé. Il faudrait chercher, il y a énormément de posts de blogs sur ces sujets qui ne sont pas forcément des blogs AWS. Mais voilà, si vous fouillez un peu, vous allez trouver plein de boîtes qui ont des archi-serverless basées sur l'un ou l'autre de ces frameworks ou basées simplement sur les services AWS. Vraiment, tous les jours, j'en ai encore retweeté, je ne sais pas, deux ou trois hier, comment intégrer Lambda et HipChat, comment faire des crons en Lambda. Tous les jours, tous les jours, si vous allez voir Hacker News, à peu près tous les jours, il y a un article important sur l'ambiance. Vraiment, ça n'arrête pas. Je vois Hugo faire les gros yeux, on n'a plus le temps. Alors, il faut choisir un gagnant ? Vous êtes terrible. Je vais faire gagner Antoine, parce qu'il a posé la bonne question sur est-ce qu'il faut faire des stacks éphémères pendant les tests d'intégration. Ça m'a permis de répondre longuement là-dessus et de vous inciter à faire du CloudFormation. Donc, voilà, Antoine, on va vous envoyer un petit quelque chose. Pour tous les autres, ne soyez pas déçus, il y a encore plein de webinaires et vous aurez encore plein d'opportunités de gagner. Voilà, je vous remercie, on est complètement à court de temps. Merci beaucoup, vous avez été encore hyper nombreux. Ça fait vraiment plaisir. Merci à Hugo pour toute son aide et toute sa logistique impeccable. Je pense que tu pourras partager les PDF, c'est déjà fait, bravo, et on postera les vidéos prochainement. Donc, on vous donne rendez-vous le mois prochain pour deux autres webinaires. Je vous remontre rapidement où les trouver sur notre site. Et donc le mois prochain, on parlera de quoi, Hugo ? On parle DevOps ? C'est ça. OK, donc le mois prochain, on fera deux sessions DevOps. Donc, on risque de bien s'amuser. Voilà, merci beaucoup. Merci pour toutes vos questions. On va les garder. N'hésitez pas, pour les gens auxquels je n'ai pas répondu, n'hésitez pas à m'envoyer un petit mail. J'essaie de répondre à tout le monde, ça prend parfois un peu de temps, j'essaie au moins. Et en tout cas, je vous donne rendez-vous le 28 février à 15h30 pour un Deep Dive DevOps qui promet d'être assez rigolo. Merci beaucoup, bonne soirée, et à bientôt.