Gestion d’événements, gestion d’API, conteneurs… avec le Cloud sont arrivés une foule de micro-services, qui révolutionnent la conception d’applications et leur déploiement. Aujourd’hui nous nous intéressons en particulier à trois nouveaux services que sont Lambda, API Gateway et Serverless.

Lambda permet de déposer son code (Node.js, Python et Java 8 à date) dans le Cloud AWS, pour ensuite l’exécuter de manière contrôlée. Le service est entièrement managé par Amazon Web Service. Contrairement à une VM qui fonctionne tout le temps, Lambda est un service à la demande, ce qui induit une consommation différente. La particularité de Lambda est que le service permet de réagir à des événements. Déposer un fichier sur S3, enregistrer une donnée sur DynamoDB, recevoir un message dans un flux Kinesis… autant d’événements qui peuvent générer d’appels à une lambda.

Ce service AWS présente l’avantage d’une tarification à l’usage, basée sur le temps d’exécution. Du fait de ce modèle de consommation, il est nécessaire de faire attention au code déployé et à la manière dont il est pensé et développé, pour prendre en compte exceptions, appels distants et latences réseau. Des éléments qui bloquent l’exécution ou allongent le temps d’exécution, et par conséquent, la facturation.

API Gateway

API Gateway est un service managé de proxy d’API, qui permet de créer, gérer et monitorer des API, qui agissent ensuite comme porte d’entrée vers des services AWS tels que EC2, Lambda, Kinesis, etc. API Gateway aide les développeurs à gérer les tâches liées aux API comme la gestion du trafic entrant, la restriction du nombre d’appels à une ressource donnée, le contrôle des autorisations et accès, la surveillance, versionning de l’API, etc. Chaque appel repose sur le concept HTTP « REST », en appelant des resources créées par un développeur par l’intermédiaire de méthodes HTTP (i.e GET, POST, PUT, DELETE, OPTIONS).

Par la suite, le développeur est à-même de monitorer les données (quelle ressource est la plus appelée, quel est le temps de réponse moyen, la mémoire consommée à chaque appel, etc.), de déployer ses APIs, etc.

API Gateway apporte également la particularité de pouvoir intercepter et transformer les données selon ses besoins, afin par exemple de réceptionner du XML en entrée et de le transformer en JSON pour les besoins de l’API, et inversement.

Serverless, ou les applications sans serveur

On en vient enfin à Serverless (anciennement JAWS), un outil présenté lors du dernier AWS Summit, et qui tire parti de API Gateway et de lambda. Serverless est un framework open-source écrit en NodeJS permettant de construire des applications « sans serveurs » avec Lambda et API Gateway en fournissant un ensemble de commandes en CLI.

Serverless repose sur un concept de modules. Chaque module décrit un micro service, qu’il suffit ensuite de personnaliser afin d’indiquer la route à appeler pour la lambda. Parmi les cas d’usage, on peut penser à des applications Web, mobiles, IoT…. Serveless peut s’adapter à de nombreux contextes.

Serverless est basé sur sur l’architecture “event driven”, où chaque requête API déclenche une lambda. L’ensemble est sauvegardé sur S3 et synchronisé au travers de CloudFormation. L’utilité est bien là, il est par ailleurs assez complexe de déployer des lambdas en nombre, et de façon automatisée.

Cas pratique

Dans le cas que nous avons testé, nous avons utilisé API Gateway comme point de terminaison d’une Lambda et construit une autorité d’identification Web. Il était question d’envoyer un token oAuth2 à cette Lambda afin que celle-ci valide ou non la provenance ainsi que la véracité de ce token, et donc de l’identité de la personne, afin de fournir des accès à des resources AWS.

Egalement, nous avons pu mettre en place un système de validation post-upload d’un fichier sur AWS S3, et déterminer si celui-ci respectait des règles de validation telles que le nommage et de taille maximale par exemple. Lorsque le fichier ne correspondait pas, la Lambda déplaçait ce fichier en quarantaine, et un e-mail était envoyé par SES.