Construire un microservice serverless & le déployer sur AWS (part 1)

Bienvenue dans le premier article d’une série consacrée au Cloud serverless. Nous allons voir ensemble comment créer et déployer un microservice serverless sur AWS.

Je partagerai ici mes retours d’expérience, quelques bonnes pratiques à l’usage des développeurs et bien sûr… du code !

Ce que j’ai pu vivre sur le terrain, chez mes clients, fera sans doute écho à vos propres enjeux. N’hésitez pas à réagir en commentaires, je suis preneur de ces échanges.

A l’issue de la série, vous maîtrisez ces 8 étapes :

• Concevoir le socle d'un microservice Serverless;
• Créer et isoler vos lambdas AWS;
• Insérer/récupérer les données de vos tables DynamoDB ;
• Lancer et débugger en local le microservice serverless;
• Sécuriser et récupérer vos variables d'environnements ;
• Lancer un déploiement avec Gitlab CI/CD ;
• Faire un déploiement avec la suite DEVOPS - AWS CI/CD.

Nous allons répondre ensemble à toutes les questions portant sur la modélisation et sur le choix à faire entre une seule Lambda ou plusieurs Lambdas par projet.

Mais avant cela, jetons un coup d’œil dans le rétroviseur

Si l’on compare le développement logiciel à l’architecture, on peut en référer aux “monolithes” des années 1990 et 2000 : à l’époque, on construisait des ensembles avec des briques interdépendantes. Tout était connecté.

On s’est rendu compte par la suite que cela rendait les choses très compliquées pour la maintenance d’une application et pour n’importe quel développement ultérieur. Ainsi, pour modifier une seule partie du système, on était obligé de toucher à l’ensemble des autres couches.

Alors, on a découpé les briques, de plus en plus finement, pour parvenir à une forme “micro” du service et s’affranchir de la dépendance au reste du système, comme résumé sur ce schéma :

Chacun de ces microservices remplit une seule mission, travaille dans son propre environnement et stocke ses propres données.

Les microservices apportent quatre avantages majeurs :

• Rapidité des mises en place;
• Faible coût;
• Evolutivité;
• Performance.

Attention, malgré le terme “micro”, les micro-services ne sont pas forcément… petits ! On les qualifie de “micro” parce qu’ils sont une partie autonome d’un ensemble plus vaste.

Pour l’utilisateur, tout cela est invisible : on a séparé le “front end” (ce que le client voit) du “back end”. Aujourd’hui, quand on touche au front end, on ne touche plus aux microservices qui sont logés dans le back end, sous forme d’APIs agnostiques.

En termes d’organisation, cela permet d’avoir différentes équipes travaillant simultanément sur “leur” microservice, avec des langages informatiques différents.

Et en termes logistiques, pour faire tourner ces microservices, on a créé des serveurs capables de résister à des sollicitations importantes. On a ainsi établi une double scalabilité : verticale (pour tenir la charge, augmentation CPU, RAM...) et horizontale (on duplique l’API sur différents serveurs).

Vous l’avez compris : on réduit les coûts d’infrastructure puisqu’on peut allouer à chaque microservice la juste quantité de ressources.

Même chose en cas de panne : on identifie le microservice défaillant et on le corrige rapidement.

Et pour finir... on est passé du serveur robuste à un monde Serverless (sans serveur) ! C’est là qu’interviennent les fournisseurs du Cloud. On peut désormais confier au prestataire Cloud la gestion des ressources nécessaires au fonctionnement de ces microservices utilisés à la demande, pour se libérer des contraintes de gestion de l’infrastructure, laissant les équipes se focaliser sur la valeur métier, le développement des fonctionnalités et les livraisons.

En résumé, Serverless nous permet d'exécuter du code à la demande suivant des déclencheurs prédéfinis (Appel HTTP, Dépôt d'un fichier, Alarme déclenchée...), de gérer du stockage et d'évoluer “scale Out” (scalabilité horizontale). Le tout sans aucune administration ou maintenance de l'infrastructure !

Dans cette série, AWS est le Cloud Provider - et notre microservice serverless se composera de 3 AWS Lambda desservies par une Amazon API Gateway de type REST API et les données seront stockées dans une table Serverless Amazon DynamoDB, le tout déployé via l'outil AWS SAM. Pour mémoire :

AWS Lambda est un service Serverless de calcul qui nous permet d'exécuter du code sans nécessiter le provisionnement ni la gestion de serveurs. Le code est exécuté à la demande et seulement lorsque cela est nécessaire sans oublier qu'il se met à l'échelle de façon automatique.

Amazon DynamoDB est un service Serverless de base de données NoSQL qui nous permet de créer des items dans des tables ( clé, valeur) , offrant des performances rapides et prévisibles tout en offrant une évolutivité transparente suivant le trafic et le nombre de Read/Write demandé.

Amazon API Gateway est un service Serverless agissant comme une « porte d'entrée » qui permet de créer, publier, gérer, surveiller et de sécuriser les API REST, HTTP et WebSocket à n'importe quelle échelle, et de gérer aussi les autorisations, contrôle des accès des appels effectués aux APIs ainsi que la gestion de leur version (Stages).

AWS SAM Serverless Application Model est un alias de CloudFormation qui nous permettra de gérer et de déployer des ressources Serverless dans un template Yaml (identique aux templates CloudFormation) et aussi de pouvoir lancer et tester nos Lambdas en local via un docker container.

Une vue d'ensemble du résultat :

Les pré-requis pour commencer : 4 installations avant de vous lancer

• Créer un compte AWS
• Installation de node.js (incluant le NPM package management tool)
• Installation Docker C.E
• Installation de AWS CLI
• Installation de AWS SAM CLI

Une fois les installations terminées, validez-les avec les commandes suivantes :

• Docker

$ docker --version 

Docker version 20.10.3, build 48d30b5

• NPM

$ npm --version

6.14.4

• AWS

Pour AWS, afin d'utiliser la CLI, vous auriez besoin de créer des identifiants :

Pour cela, accédez au service IAM, cliquez sur l'onglet Security credentials de votre utilisateur IAM :

Pour générer de nouveaux identifiants CLI (access key), cliquez sur le bouton "Create access key" :

AWS va générer de nouveaux comptes CLI que vous pouvez télécharger ou récupérer depuis la console , /!\ ces comptes sont à usage unique, en cas de fermeture de la fenêtre vous devez recommencer cette étape :

Accédez à votre terminal, et tapez la commande suivante en renseignant les valeurs précédentes :

$ aws configure

AWS Access Key ID [None]: <AWS_ACCESS_KEY_ID>
AWS Secret Access Key [None]: <AWS_SECRET_ACCESS_KEY>
Default region name [None]: <REGION> 
Default output format [None]: 

Testez avec la commande suivante, si tout est ok vous obtiendrez ce résultat :

$ aws sts get-caller-identity


{
    "UserId": "************",
    "Account": "***********",
    "Arn": "arn:aws:iam::***********:user/************"

}

• SAM

$ sam --version

SAM CLI, version 1.18.2

Parfait ! Dans le prochain article, nous allons mettre la main à la pâte et commencer à créer notre socle technique Serverless...

A suivre Organisation et mise en place du socle de mon microservice serverless (part 2)

Open a réuni ses communautés de talents autour du programme Squads. Positionnées sur les technologies émergentes, les Squads favorisent le développement des expertises technologiques et offrent à ses membres un parcours professionnel hors normes. Pour en savoir plus sur les Squads 👉 LinkedIn