Aujourd’hui je vais vous présenter la stratégie d’architecture serverless à travers le service d’AWS lambda function. Ce type d’architecture s’associe parfaitement avec les techniques de développement logiciel en « Micro-Services ». 

Qu’est-ce que l’architecture serverless ?

L’architecture Serverless est un modèle de cloud computing dans lequel les développeurs peuvent créer et exécuter les applications sans devoir à gérer la partie infrastructure, d’où le terme “serverless”, ou “sans serveur” en français.

Bien évidemment vous allez dire que, tout comme le cloud, une application doit forcément être hébergée quelque part. Et vous avez raison ! Car oui, on a toujours besoin des infrastructures IT pour faire tourner les applications.

 La particularité du modèle serverless est qu’elle est plus simple : le développeur a juste besoin de fournir son code. Tout le reste est pris en charge par le fournisseur de services cloud.

Le modèle “serverless” fait abstraction de la partie infrastructures IT. Ce qui veut dire que les équipes techniques s’affranchissent des contraintes de l’infrastructure et peuvent se concentrer sur le plus important : le développement du produit. Le développeur a la responsabilité de développer sa ou ses fonctions. Et Le reste, c’est à la charge du fournisseur de services cloud.

Evidemment, il y a des règles à respecter pour pouvoir héberger une application dans une architecture serverless. Et cela commence dès la conception du code.

Dans cet article, nous allons voir comment penser son code serverless et comment AWS permets de l’implémenter au travers de son service AWS Lambda.

Comment penser son code serverless?

Le principe premier d’une fonction serverless est qu’elle est destinée de par sa nature à une seule et unique tâche. En conséquence, une fonction ne pourra contenir qu’un point d’entrée et une réponse. Ainsi, vous devrez découper votre application en une suite de fonctions. 

On associe souvent “serverless” à la méthodologie « Function as a Service » (FaaS).

Pour chaque fonction, vous pourrez lui associer un type d’événements. Par exemple si la fonction est sollicitée par une requête HTTP. La requête déclenche l’exécution du code et donc la fonction.

A noter que les événements déclencheurs peuvent être divers : que ce soit l’ajout d’un fichier sur un espace de stockage ou alors une nouvelle entrée dans une base de données.

Le modèle serverless est compatible avec plusieurs design de développement logiciel tel que le pattern MVC. Vous pouvez dans une seule lambda avoir toute une application contenant plusieurs couches, modèles et services !

Seulement, rappelez vous une fonction ne peut avoir qu’un point d’entrée et un seul type de réponse.

Implémenter une architecture Serverless avec Lambda Function

Une « lambda function », vous l’aurez compris, c’est la fonctionnalité d’Amazon Web Services qui vous offre un service de calcul sans serveur. Une lambda fonction a pour but de répondre à un besoin précis dans un temps de vie limité (entre 1 et 15 minutes max).

 Lambda exécute le code de vos applications sur une infrastructure de calcul à haute disponibilité et effectue toute l’administration des ressources de calcul, y compris la maintenance du serveur et du système d’exploitation, le dimensionnement des capacités et la mise à l’échelle automatique, le déploiement du code et des correctifs de sécurité, ainsi que la surveillance et la journalisation du code.

Les équipes techniques n’ont plus besoin de définir le nombre de serveurs, leur puissance, de mettre à l’échelle, d’entretenir, de superviser, ni de les mettre à jour.

Dans quel cas puis-je utiliser lambda ?

Le service lambda prend une place de plus en plus importante dans les services AWS et cela se ressent dans le nombre d’évènements dans lequel lambda peut s’abonner :

• HTTP avec Api Gateway : Vous allez pouvoir déclencher le code de votre lambda lors d’un appel HTTP GET, POST, PUT…
•  Tâche automatisée avec CloudWatch : Vous pouvez déclencher votre lambda suivant un job ou cron dans la période que vous aurez définie. Par exemple envoyer une newsletter à vos utilisateurs chaque début de mois.
• Worker avec SQS : Attaché à une file d’attente SQS, vous allez pouvoir consommer les messages d’une file d’attente pour pouvoir lancer des tâches asynchrones
• Bucket S3 : Vous allez pouvoir connecter une lambda function au bucket S3 (service de stockage d’amazon) et déclencher votre lambda après une modification d’objets. Par exemple, redimensionner une image dès qu’un utilisateur la dépose sur votre site…

D’autres évènements sont disponibles ! Je vous invite à les retrouver dans la documentation AWS de lambda ici

Comment créer et configurer une lambda function

Vous pouvez créer une lambda function depuis votre terminal avec le client AWS, depuis des fichiers d’Infra As Code (CloudFormation), ou bien simplement depuis la console web AWS.

Quelque soit la solution choisie,  vous disposerez ensuite d’une suite de paramètres que vous pouvez configurer :

• La taille de la mémoire vive : 128 mo à 3 Go. Une augmentation de mémoire augmente également la puissance du processeur.
• Le choix du runtime de votre application : AWS supporte nativement Java (8, 11), NodeJs (10, 12), Python (2.7, à 3.8), Ruby (2.5, 2.7), GO, .NET (2.1, 3.1). Dans le cas où votre application n’est pas dans cette liste vous pouvez aussi implémenter votre propre runtime : https://docs.aws.amazon.com/lambda/latest/dg/runtimes-custom.html
• La durée maximum d’exécution de votre lambda : 1 mn à 15 mn maximum.
• Le code de votre application : vous pouvez le déposer depuis votre ordinateur, depuis un bucket S3, ou même si vous êtes sur la console, développer votre code directement depuis l’interface.

Une fois ces paramètres renseignés, vous pouvez tester votre lambda function directement depuis la console web en renseignant les paramètres d’entrée que vous souhaitez envoyer.

Et la scalabilité ?

Lorsque votre fonction est appelée, Lambda alloue une instance pour traiter l’événement.

Lorsque le code de la fonction a fini de s’exécuter, il peut gérer une autre demande. Si la fonction est appelée à nouveau alors qu’une demande est toujours en cours de traitement, une autre instance est allouée, ce qui augmente la simultanéité de la fonction.

La simultanéité est soumise à une limite régionale partagée par toutes les fonctions figurant dans une région. Pour vous assurer qu’une fonction peut toujours atteindre un certain niveau de simultanéité, vous pouvez la configurer avec la simultanéité réservée.

Par défaut, sur la zone de disponibilité Paris, le nombre de lambda est limité à 1 000 exécutions simultanées.

Cela signifie, que sans configuration supplémentaire, vous profiterez de 1 000 exécutions simultanées maximum sur l’ensemble des lambdas de votre compte.

Ainsi, si une lambda traite 1000 demandes simultanément, les autres lambdas ne pourront plus être provisionnées correctement et rejetteront une erreur.

Vous pouvez demander une augmentation auprès d’AWS si votre besoin le demande ou réserver un nombre maximum d’exécutions par lambda.

A savoir : la réservation d’un nombre d’exécution d’une lambda réduira par conséquent le nombre total de lambda simultanées.

Tarification

L’avantage de l’architecture sans serveur est aussi financier puisque vous payez seulement le temps de traitement que vous utilisez ! Plutôt que d’acheter un serveur qui tournera toute la journée, vous ne paierez que le temps d’utilisation réellement consommé.

 En effet, la facturation est basée uniquement sur les ressources consommées, c’est à dire pour la lambda le temps réel d’exécution du code, avec une unité de paiement la consommation du service à la milliseconde près. Ce qui veut aussi dire qu’en l’absence de trafic, l’utilisateur ne paie rien.

C’est là tout l’intérêt économique du modèle “serverless”. Fini le coût des serveurs : leur achats, leur gestion, leur entretien…

Et en plus, ce modèle de paiement à l’usage incite à l’optimisation de la performance du code. Réduire le temps d’exécution d’une application serverless permet de diminuer le coût du service, et donc la facture à la fin du mois

AWS mets en avant son service Lambda en proposant des tarifs très avantageux pour tout développeur ou entreprise qui se lance dans ce type d’architecture. 

Exemple de scénario de facturation : 

• Type d’évènement : HTTP
• Nombre de requêtes mensuel : 30 000
• Durée : 100ms
• Localisation : Paris (eu-west-3)
• Mémoire utilisée : 128MB
•  Tarif lambda pour ce type de configuration (100 ms) : 0,000000208 USD

Pour calculer le coût mensuel, on applique le calcul suivant :

Nb Requêtes * temps Exécution * tarif Lambda

Temps d’exécution total = 30 000 * 100 = 3 000 000 ms

Temps d’Exécution Total * Tarification

Coût Mensuel = 3 000 000 * 0,000000208 = 0,624 USD

Ainsi on constate que 30 000 requêtes coûtera moins d’un dollar. Et c’est sans compter que AWS offre le 1er million d’exécution.

Donc dans ce cas précis, cela ne vous coûtera rien ☺

Vous pouvez estimer directement le coût depuis le pricing calculator d’amazon ici

Conclusion

J’espère que cet article a éveillé votre curiosité ! Restez à jour, j’initierai prochainement une Konf’ afin vous montrer en live l’implémentation d’un projet sur une architecture serverless avec le framework SAM (Serverless Application Model) qui accélère encore le déploiement et le développement.

 En attendant, si vous souhaiter d’ores et déjà développer un premier projet sur lambda, je vous invite à la suivre le tutoriel officiel d’AWS hello world dans le langage de votre choix :  https://aws.amazon.com/fr/getting-started/tutorials/run-serverless-code

Sofiane AZIRI, Ingénieur Full Stack à Kaibee. Certifié Solution Architect Associate et Developer Associate par AWS.