Développer en Serverless : Comment construire un proxy d’API avec AWS Lambda

Exécuter du code et des processus en réponse à des événements en provenance d’un service Amazon sans avoir à gérer de serveurs et d’infrastructure, c’est la promesse d’AWS Lambda. Si le principe des fonctions Lambda permet de répondre à de très nombreux cas d’usage, Lambda bouleverse cependant les habitudes des développeurs : quand le code s’exécute sur un serveur dont il n’a pas la maîtrise, il est compliqué pour le développeur de savoir quels sont les outils utilisables localement pour vérifier l’exécution du code sur sa machine. Dans l’optique de répondre à certains de ces besoins des développeurs, et de pallier l’absence de l’environnement d’exécution en local, nous avons donc développé une démo de proxy d’API basé sur Lambda.

L’objectif de ce module disponible sur GitHub est de pouvoir consommer une API d’origine à travers le service API Gateway d’Amazon en mode proxy : toute requête faite sur API Gateway est ainsi « proxyfiée » sur l’API d’origine. Le module agit comme un tampon et stocke les réponses temporairement, permettant notamment d’exploiter l’ensemble des possibilités offertes par API Gateway.

Côté développement en plus de cet exercice, le projet vise à fournir tous les outils utiles pour déployer une application, et notamment jouer des tests unitaires, de montée en charge, et tous les tests effectués habituellement dans le développement d’une application classique dans une logique d’intégration et de déploiement continu afin de :

  • Rendre le dépôt auto-testant
  • Automatiser la création des paquets (releases)
  • Maintenir des cycles courts
  • Tester différents environnements
  • Rendre disponible la dernière release
  • Automatiser le déploiement
  • Permettre le retour en arrière (Rollback)

Le projet apporte un ensemble d’outils pour tester localement ou en remote une lambda, déployer une lambda, la versionner, la packager et de gérer les éléments d’infrastructure nécessaires à l’exécution de la lambda, en s’appuyant sur les composants suivants :

  • API Gateway pour exposer des endpoints et récupérer les requêtes de type HTTP
  • DynamoDB, afin de stocker les réponses de l’API source quelque soit leur format
  • Le framework APEX pour distribuer et gérer les Lambdas. APEX présente l’avantage d’être un outil sans aucune dépendance et de s’exécuter sur toute plateforme, et de permettre le versioning et les rollbacks de version de code. Il permet également de gérer différents environnements, et d’écrire ses lambdas avec des langages plus modernes comme Go ou Rust. De tous les outils autour de Lambda, c’est clairement celui qui nous a paru le plus adapté pour une chaîne CI/CD.
  • Terraform pour la construction des ressources nécessaires au projet (base de données NoSQL DynamoDB, gestion des autorisations, construction de l’API sur API gateway, et les endpoints nécessaires)
  • Python comme langage d’exécution
  • Docker afin de packager des outils et d’exécuter la Lambda sur un système d’exploitation équivalent à celui d’ AWS Lambda.

Cet exercice permet d’avoir une image de l’état des derniers outils et des meilleures techniques autour d’AWS Lambda pour un cas particulier d’API REST proxifiée. Déployer sur le Cloud est de prime abord plus complexe que de déployer sur un datacenter spécifique. Mais l’exercice permet d’avoir une idée précise de comment effectuer la gestion des dépendances, la gestion des releases et de répondre aux nombreuses interrogations qu’un développeur peut avoir face cette approche nouvelle et orientée événement qu’apporte Lambda. Notre premier constat est qu’il existe des outils mais que ceux-ci ne permettent pas de totalement répondre aux exigences de certains type de projets. Il y a donc encore de la place pour outiller le développeur serverless.

En revanche les réels avantages de Lambda sont de permettre scaler naturellement, d’assurer une qualité de service et d’avoir une excellente disponibilité sans devoir gérer un datacenter et cela avec des temps de déploiements ultra-rapide qui sont de l’ordre de la seconde.

Enfin, pour poursuivre cet exercice vous pouvez participer sous forme de pull request sur Github et/ou imaginer de déclencher une exécution de Lambda lors de l’insertion dans la table DynamoDB sur vos propres projets. Vous pouvez aussi utiliser cette base afin de consommer une API payante afin de réduire les appels redondants et ainsi réduire vos coûts de consommation… Libre à vous d’imaginer le reste ! Le projet est disponible sur Github à cette adresse.

Keynote, techshare, bootcamp… venez faire le point avec nous sur Serverless lors du TIAD Camp le 27 avril :

 

Commentaires :

A lire également sur le sujet :