Chapitre 8.14Le serverless

Tu veux lancer une application. Le code est écrit, il fonctionne sur ton ordinateur. Maintenant il faut un serveur pour le faire tourner en permanence.

Et là commence le travail ingrat. Choisir la machine, installer le système, appliquer les mises à jour de sécurité, surveiller l'espace disque, redémarrer quand ça plante, prévoir assez de puissance pour absorber le pic du lundi matin sans payer cette puissance le reste de la semaine.

Et si quelqu'un s'occupait de tout ça à ta place, et que tu ne payais que quand ton code s'exécute réellement ? C'est la promesse du serverless.

Le principe

Le nom est trompeur, il y a évidemment des serveurs. Simplement, tu ne les vois plus, tu ne les configures plus et tu ne les surveilles plus.

Tu écris une fonction, souvent quelques dizaines de lignes de code, tu la déposes chez un fournisseur cloud comme AWS, Google Cloud ou Azure, et tu déclares dans quelles circonstances elle doit s'exécuter. Le reste ne te regarde plus.

Pas de trafic ? La fonction dort et ne coûte rien.
Cent requêtes simultanées ? Le fournisseur lance cent exécutions en parallèle sans que tu aies à lever le petit doigt. Tu paies ces cent exécutions, pas une machine allumée vingt-quatre heures sur vingt-quatre au cas où.

Le modèle s'est imposé en 2014 avec le lancement d'AWS Lambda, au point que beaucoup de développeurs disent encore "une lambda" pour parler de n'importe quelle fonction de ce type. On parle aussi de FaaS, Function as a Service, pour distinguer cette approche des offres où l'on loue une machine ou une plateforme.

Une fonction sans mémoire

Il y a une contrainte fondamentale à comprendre, parce qu'elle explique presque tout le reste. Une fonction serverless est sans état, ce qui signifie qu'elle ne garde aucun souvenir entre deux appels. Elle démarre, reçoit ses données d'entrée, produit un résultat, et disparaît.

Tout ce qui doit survivre, panier, session, fichier téléversé, doit donc être rangé ailleurs, dans une base de données ou un service de stockage. C'est une discipline saine, celle-là même qui permet au fournisseur de lancer cent copies de ta fonction sans se soucier de savoir laquelle répondra à qui.

Les cas d'usage

Le serverless brille dans quelques scénarios bien identifiés.

• Les API légères : un point d'entrée qui reçoit une requête, fait un traitement simple, et renvoie une réponse. Mobiliser un serveur entier pour ça n'a pas grand sens.
• Le traitement d'événements : redimensionner une image dès qu'elle est déposée sur le stockage, envoyer un email quand un formulaire est soumis, mettre à jour un index de recherche quand un article est publié.
• Les tâches planifiées : un rapport généré chaque nuit, un nettoyage de base de données chaque semaine. La fonction se réveille, fait son travail, et s'éteint.
• Les webhooks et les chatbots : du code qui ne s'exécute que lorsqu'un service externe envoie une notification ou qu'un utilisateur pose une question.
• Le trafic très irrégulier : une billetterie qui ne vit que trois jours par an, une opération marketing, un service interne utilisé dix minutes par jour. Payer un serveur à l'année pour ça est absurde.

Les avantages

• Pas d'infrastructure à gérer : plus de machine à configurer, plus de correctif de sécurité à appliquer dans l'urgence un vendredi soir. Le fournisseur s'en charge.
• Mise à l'échelle automatique : si dix mille utilisateurs arrivent en même temps, le système suit tout seul, et il redescend aussi vite quand la vague passe.
• Facturation à l'usage : tu paies un montant par exécution, de l'ordre de vingt centimes par million de requêtes chez les grands fournisseurs, auquel s'ajoute le temps de calcul consommé. Les offres gratuites couvrent généralement le premier million d'appels mensuels, ce qui suffit à faire tourner un petit projet pour rien.
• Un déploiement rapide : passer d'une idée à un point d'entrée public prend des minutes, pas des jours. C'est un excellent terrain pour prototyper.

Les limites

Le serverless n'est pas la réponse à tout, et les cas où il se retourne contre toi sont assez bien connus.

• Le cold start : quand une fonction n'a pas été appelée depuis un moment, le fournisseur doit la réveiller, ce qui suppose de préparer un environnement d'exécution. Ce démarrage à froid ajoute de quelques dizaines de millisecondes à plus d'une seconde selon le langage et la taille du code. Pour une interface où l'utilisateur attend, ça se voit.
• La durée d'exécution limitée : les fonctions ont un délai maximal, quinze minutes chez AWS Lambda par exemple. Un encodage vidéo de deux heures ne rentre pas dans cette boîte.
• Le verrouillage fournisseur : ta fonction est écrite pour un environnement précis, avec ses déclencheurs, ses permissions et ses services connexes. Le code métier se transporte, mais tout ce qui l'entoure se réécrit lors d'une migration.
• Le debugging complexe : ton code tourne dans un environnement que tu ne contrôles pas et qui n'existe plus une fois l'exécution terminée. Sans une bonne stratégie de logs et de monitoring, tu enquêtes à l'aveugle.
• Les connexions aux bases de données : une base relationnelle classique supporte un nombre limité de connexions simultanées. Mille fonctions lancées en parallèle qui veulent chacune la leur, et c'est la base qui tombe, pas la fonction.
• Le coût à grande échelle : pour un service au trafic constant et élevé, un serveur dédié revient très souvent moins cher que des dizaines de millions d'invocations. Le serverless est économique quand la charge est creuse ou irrégulière, beaucoup moins quand elle est pleine.

L'écueil le plus fréquent est le découpage à l'excès. Une application entière éclatée en deux cents petites fonctions qui s'appellent les unes les autres devient très difficile à suivre et à déboguer, exactement comme des microservices mal découpés. Le serverless ne dispense pas de réfléchir à l'architecture, il déplace juste la question.

Serverless au-delà des fonctions

Le terme ne désigne plus seulement les fonctions. Il s'est étendu à tout service managé qui ne demande ni dimensionnement ni administration et qui se facture à l'usage.

• Bases de données serverless : DynamoDB chez AWS, Firestore chez Google, ou les variantes serverless des bases relationnelles classiques. Pas de serveur de base à dimensionner, une facturation liée aux lectures, aux écritures et au stockage.
• Stockage serverless : S3 chez AWS et ses équivalents. Tu déposes des fichiers, tu paies au gigaoctet stocké et au nombre d'accès, sans jamais penser en disques durs.
• Files de messages serverless : SQS chez AWS par exemple. Le service gère l'infrastructure de la file, tu ne t'occupes que des messages, comme nous l'avons vu dans le chapitre sur les files de messages.
• Le serverless en périphérie : Cloudflare Workers, ou les fonctions proposées par les plateformes d'hébergement front comme Vercel et Netlify, exécutent ton code dans le point de présence CDN le plus proche du visiteur. Le démarrage à froid y est quasi nul, au prix de contraintes plus fortes sur ce que le code a le droit de faire.

Serverless ou conteneurs ?

La question revient systématiquement, parce que les conteneurs promettent eux aussi de simplifier le déploiement. La différence tient à ce que tu continues de gérer.

Avec un conteneur, tu décris l'environnement complet et tu gardes la main sur le langage, les dépendances, la durée de vie du processus. En échange, quelqu'un doit décider combien d'exemplaires faire tourner, et payer pour qu'ils restent allumés.

Avec une fonction serverless, tu abandonnes ce contrôle et tu récupères l'élasticité et la facturation à zéro quand rien ne se passe. Les deux mondes se rejoignent d'ailleurs, avec des offres qui exécutent un conteneur à la demande et le facturent à la seconde.

Le serverless est le prolongement naturel du cloud. On a d'abord loué des machines, puis des plateformes, puis on a cessé de penser aux machines. Ce n'est pas la fin des serveurs, c'est la fin de leur gestion pour ceux qui n'ont aucune raison de s'en occuper.