Le calcul serverless

Le spectre ne pouvait pas tout vous montrer

La leçon sur les services de calcul a placé les fonctions serverless tout à droite du spectre contrôle-confort : le fournisseur gère tout sauf votre code, et une fonction démarre en millisecondes. Ce diagramme a sa place, il montre où le serverless se situe par rapport aux machines virtuelles et aux conteneurs, mais il ne montre pas ce que "le fournisseur gère tout" signifie concrètement, ni où s'arrêtent les limites de ce confort. Les 2 comptent dès que c'est vous qui décidez si une charge de travail a sa place sur une fonction serverless.

Sans serveur, c'est le nom marketing, pas le mécanisme

"Serverless" est le nom que l'industrie donne à ce modèle, pas une description littérale. AWS exécute votre fonction dans une micro machine virtuelle isolée, sur sa propre flotte de serveurs physiques, grâce à une technologie de virtualisation appelée Firecracker ; Azure et Google Cloud font l'équivalent sur leur propre matériel. Ce que "serverless" retire, ce n'est pas le serveur, c'est votre travail de choisir, dimensionner, corriger et mettre à l'échelle ce serveur. Comparez cela à IaaS, où vous choisissez vous-même le type d'instance, ou même à PaaS, où vous choisissez au moins un runtime et une politique de mise à l'échelle. Une fonction serverless ne vous laisse aucun de ces 2 leviers : vous fournissez une fonction, vous attachez un déclencheur, et le fournisseur décide combien de copies faire tourner, où, et pendant combien de temps chacune vit.

Le cycle événementiel : inactif, invocation, exécution, inactif à nouveau

Une fonction serverless ne reste pas allumée à attendre du travail comme le ferait une machine virtuelle. Imaginez une fonction qui génère une miniature chaque fois qu'un client dépose une photo dans un bucket de stockage. La majeure partie de la journée, zéro copie de cette fonction ne tourne nulle part, et cela ne coûte rien. Dès qu'une photo arrive dans le bucket, l'événement déclenche une invocation : la plateforme trouve ou crée un environnement d'exécution, exécute votre code contre l'événement, et renvoie un résultat. Une fois le flux de dépôts arrêté un moment, la plateforme récupère cet environnement, et la fonction revient à zéro.

Démarrage à froid, démarrage à chaud

Cette distinction "trouve ou crée" porte un nom. Si un environnement d'une invocation récente existe encore, la plateforme le réutilise, un démarrage à chaud, qui exécute votre code presque immédiatement. Sinon, après une période d'inactivité ou une pointe de nouveau trafic, la plateforme doit d'abord initialiser un environnement neuf, charger votre runtime et importer vos dépendances avant même que votre code ne s'exécute, un démarrage à froid. Ce travail d'initialisation n'est gratuit ni en temps ni en argent : la facturation actuelle d'AWS Lambda compte la phase d'initialisation d'un démarrage à froid comme durée facturée, au même titre que le code lui-même. Une fonction invoquée en continu paie rarement cette taxe, ses environnements restent chauds ; une fonction invoquée par rafales occasionnelles la paie à chaque première requête d'une rafale.

Le calcul derrière "vous ne payez que ce qui s'exécute"

La tarification à la demande d'AWS Lambda facture 0,20 $ par million de requêtes plus 0,0000166667 $ par Go-seconde d'exécution, avec un niveau gratuit d'1 million de requêtes et 400 000 Go-secondes chaque mois, pour toujours.

Prenez une fonction configurée avec 512 Mo de mémoire (0,5 Go) qui s'exécute pendant 400 millisecondes (0,4 seconde), invoquée 100 000 fois par mois, la génération de miniatures pour une petite application de partage de photos, disons. Cette charge consomme 100 000 x 0,5 x 0,4 = 20 000 Go-secondes et 100 000 requêtes, les 2 confortablement dans le niveau gratuit. La facture : 0 $.

Faites maintenant grimper cette même fonction à 5 millions d'invocations par mois, une application plus fréquentée, ou la même application devenue grande. Cela fait 5 000 000 x 0,5 x 0,4 = 1 000 000 Go-secondes, dont 600 000 facturables après le niveau gratuit, plus 4 000 000 de requêtes facturables. La durée coûte environ 600 000 x 0,0000166667 $, soit environ 10,00 $, et les requêtes ajoutent encore 4 x 0,20 $ = 0,80 $, pour une facture autour de 10,80 $ par mois. Comparez cela au t3.micro de la leçon sur le calcul, environ 7,59 $ par mois à tourner jour et nuit, qu'il travaille ou non. À faible volume et par pointes, le serverless gagne nettement, c'est gratuit. À volume élevé et constant, une instance toujours allumée peut le battre, et ceci avant même de se demander si un seul t3.micro tiendrait la charge de 5 millions de requêtes sans s'effondrer.

Où une fonction serverless cesse de convenir

2 limites comptent autant que le calcul de coût. D'abord, la durée d'exécution : les fonctions AWS Lambda plafonnent une invocation à 15 minutes ; un travail d'encodage vidéo de 2 heures ne rentre tout simplement pas dans une simple fonction, peu importe à quel point la tarification semble avantageuse. Ensuite, l'état : un environnement d'exécution peut être réutilisé entre 2 invocations, mais rien ne le garantit, donc une fonction ne peut pas compter sur des données conservées en mémoire ou une connexion maintenue ouverte d'une invocation à l'autre. Une charge qui a besoin d'un pool de connexions de base de données de longue durée, d'un traitement par lots de plusieurs heures, ou d'un état en mémoire garanti, a sa place sur un conteneur ou une machine virtuelle à la place.

Repères d'examen : reconnaître le bon choix dans un scénario

Ce qu'il faut retenir

Le serverless ne retire pas les serveurs, il retire votre travail de les gérer, et il ne vous facture que les millisecondes où votre code s'exécute vraiment. Ce compromis paie à faible volume ou par pointes, et peut perdre face à une instance toujours allumée à volume élevé et constant, ce qui explique exactement pourquoi "le serverless coûte toujours moins cher" est un piège, pas une règle. La prochaine leçon laisse de côté la question de qui gère le serveur et en pose une autre : comment l'application elle-même doit être découpée en pièces, et comment ces pièces s'exécutent de la même façon partout. C'est ce que répondent conteneurs et microservices.