Archives par mot-clé : FaaS

Le serverless pour les nuls

Dans cet article, je vais donc vous expliquer les concepts les plus importants à retenir de l’architecture serverless

L’architecture serverless est un modèle de cloud computing dans lequel le client peut créer et exécuter ses applications sans devoir gérer la partie infrastructures et notamment les serveurs, d’où le terme “serverless”, ou “sans serveur” en français.

Evidemment, l’application, et notamment son code, s’exécute toujours sur des serveurs. Parce que oui, on a toujours besoin des infrastructures IT pour faire tourner les applications.

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

Le modèle “serverless” va donc faire abstraction de la partie infrastructures IT  pour le développeur. Ce qui veut dire que Le développeur s’affranchit ainsi des contraintes de l’infrastructure et peut se concentrer sur son travail : le développement.

Evidemment, il y a des règles à respecter pour rentrer dans le modèle serverless

Premièrement, le développeur va devoir repenser la conception de son code.  En effet, le code d’exécution n’est plus celui de toute l’application, le code d’exécution doit être décomposée en fonctions. Chaque fonction a un seul et unique but. Et l’ensemble de ces fonctions forme l’application. 

D’où le terme « Function as a Service » (FaaS) souvent associé au “serverless”. Le développeur a la responsabilité de coder sa ou ses fonctions. Et Le reste, c’est à la charge du fournisseur de services cloud.

En gros, pour le développeur, ça veut dire :

  • Plus besoin de définir le nombre de serveurs, leur puissance, plus besoin de mettre en service, de mettre à l’échelle, d’entretenir, de superviser, de les mettre à jour, et toutes autres actions concernant la gestion des serveurs.
  • Mais aussi et c’est important : plus besoin de gérer le déploiement de son application  sur les différents serveurs. 
  • Finis aussi les problématiques de stockage, de load balancing ou d’autres problématiques réseau, etc

Pour le développeur, il faut juste déposer son code et le reste c’est le fournisseur de services cloud qui s’en occupe!

Passons au fonctionnement de cette « fonction »

Cette fonction va être déclenchée par des é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. Et ici, la requête va déclencher la fonction qui va interroger une base de données (donc une action sur un autre service)

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 BDD

Ensuite, l’hébergeur cloud garantit le scaling automatique de la fonction selon les pics de trafic. Imaginons que la fonction B est beaucoup plus sollicitée que les autres, dans ce cas là, la fonction B sera exécutée plusieurs fois, cad que plusieurs « unités de travail » de la fonction B tourneront en parallèle pour répondre à la charge de travail en hausse. Ici B1, B2 et B3 sont la même instance de la fonction B mais tournant en en même temps pour répondre au pic de charge.

Et a contrario lors de faible charge, seules les unités nécessaires sont éxécutées. Ici la fonction A ne nécessite qu’une seule unité de travail pour traiter la demande.

Et s’il n’y a pas de sollicitation de la fonction alors elle n’est pas exécutée. Comme la fonction C ici que vous ne voyez pas car elle n’est pas lancée car non sollicitée.

Pour aller plus loin sur ce modèle d’architecture par fonctions, je vous invite fortement à regarder sur les microservices où j’explique plus longuement les spécificités de ce type d’architecture.

Autre point structurant du modèle serverless : la facturation

La facturation est basée sur les ressources consommées ou le temps réel d’exécution du code, avec quand même la milliseconde comme unité de paiement. 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 entretiens, etc. surtout quand ceux ci sont sous utilisés

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

Exemple concret : AWS Lambda

Maintenant que vous avez compris le principe, voyons quelques services serverless, le plus connu est AWS Lambda. AWS Lambda est un service d’Amazon Web Services (AWS) et il va suivre les principes que l’on a vu :

  • Il exécute le code seulement quand c’est nécessaire.
  • AWS lambda s’adapte automatiquement à la charge de travail
  • Et le client ne paye que le temps de calcul utilisé.

Le prérequis est d’avoir un code dans un langage compatible avec AWS Lambda comme Node.js, Java, C#  et Python et respecter le temps limite d’exécution de la fonction

Là je parle d’AWS parce que c’est l’offre que je connais le mieux. Mais c’est la même logique derrière Azure Functions de Microsoft et Google Cloud Functions de Google Cloud.

Allez maintenant, on va voir à quoi ressemble une architecture serverless sur AWS

Architecture serverless AWS

L’architecture serverless est la plupart du temps une conception en fonctions qui vont déclencher des actions sur d’autres services.

Dans notre exemple, les 2 fonctions sont développées en utilisant AWS Lambda et sont exposés via une API avec le service AWS API Gateway. Ces API sont le point d’entrée qui déclenche la fonction Lambda voulu.  Ici, on est sur un site web proposant la vente de cookies. Ici le client va demander la liste des cookies vegan. Dans ce cas, la fonction Lambda « Liste » extraire la liste des cookies avec que des ingrédients vegans. Ce qui déclenche le traitement du service dans le service de base de données DynamoDB. Ensuite, Lorsque le client fait un achat de cookies, il déclenche une fonction lambda « Achat » qui enregistre cette entrée dans AWS DynamoDB  

Ensuite, l’architecture serverless est adaptée pour la construction de workflows automatisés basées sur les fonctions Lambdas qui vont servir de liens entre les différents services AWS.

Dans cet exemple : Un nouveau fichier est déposé sur un bucket S3 (bucket S3 étantun service d’espace de stockage dans le cloud). Cette action déclenche une fonction qui va le décompresser et l’insérer dans DynamoDB. Cette écriture dans Dynamo DB va lui même déclencher une autre fonction Lambda qui va lancer le service SNS pour envoyer un SMS de notification

Les limites du modèle

Le serverless n’est pas adaptés à tous les cas d’usage. Les contraintes de temps d’exécution du serverless ne sont pas adaptées pour l’exécution de tâches lourdes et complexes (comme le traitement vidéo par exemple). et plus généralement les applications qui ont un trafic constant. Il y a donc une nécessité de bien concevoir l’architecture d’une application en amont : cela permet de décider si une architecture serverless convient pour l’application.

Enfin, dernière contrainte de ce modèle : c’est la forte dépendance au fournisseur de services cloud et plus particulièrement à son framework : chaque fournisseur de service cloud impose des règles différentes (timeouts, langages supportés, etc.). Ce qui veut dire que pour migrer après ça va être très compliqué. Vous êtes souvent donc prisonnier des règles du fournisseur de services cloud qui peuvent changer.