Qu'est-ce que le serverless? L'informatique sans serveur expliquée simplement

Le serverless est une façon d'exécuter du code sans avoir à configurer ni à gérer soi-même de serveurs. Vous confiez votre code à un fournisseur d'infonuagique, qui ne l'exécute que lorsqu'un élément le déclenche (une requête web, un fichier téléversé, une notification de paiement), puis s'arrête. Vous payez généralement le temps pendant lequel votre code tourne réellement, et non une machine inactive.

Pourquoi le serverless compte quand on crée avec l'IA

Lorsque vous créez une application avec l'IA et que vous examinez les options d'hébergement ou le code, vous rencontrerez les « fonctions serverless », les « fonctions de périphérie » ou les « fonctions infonuagiques ». De nombreuses plateformes d'hébergement les proposent, et certains générateurs par IA déploient leurs backends de cette façon. Comprendre ce modèle vous aide à répondre à trois questions pratiques :

• Le coût. Votre application coûtera-t-elle de l'argent alors que personne ne l'utilise?
• La vitesse. Pourquoi la première requête après une période calme est-elle plus lente?
• Les limites. Pourquoi une tâche longue, comme la production d'un gros rapport ou le traitement d'une vidéo, a-t-elle expiré?

Il est aussi utile de savoir ce que le serverless n'est pas : ce n'est pas l'absence de backend. Vous avez toujours du code côté serveur; quelqu'un d'autre fait simplement tourner les machines. Pour les bases, voir qu'est-ce qu'un serveur.

Une analogie du quotidien

Un serveur traditionnel, c'est comme posséder une voiture. Elle est toujours là, prête à partir instantanément, mais vous la payez, qu'elle roule ou non : assurance, stationnement, entretien.

Le serverless, c'est comme appeler un taxi. Vous ne payez que les trajets effectués, et si cent personnes ont besoin d'une course en même temps, cent taxis arrivent. Mais il peut y avoir une courte attente pour que la voiture arrive (un démarrage à froid), chaque trajet a une durée maximale, et le chauffeur ne se souvient pas de vous après la course précédente (les fonctions sont sans état).

Fonctionnement des fonctions serverless

Dans sa forme la plus courante, appelée fonctions en tant que service :

1. Vous écrivez une fonction : un petit morceau de code qui traite un type d'événement, par exemple « traiter un POST vers /api/bookings ».
2. Vous la déployez. Le fournisseur la conserve et la relie à un déclencheur : une adresse URL, un horaire, un nouveau fichier dans le stockage, un message dans une file d'attente.
3. Un événement arrive. Le fournisseur démarre une copie de votre fonction (ou réutilise une copie déjà active), l'exécute et renvoie le résultat.
4. Elle s'adapte seule. Si mille requêtes arrivent en même temps, le fournisseur exécute plusieurs copies en parallèle, dans les limites de votre compte.
5. Elle devient inactive. Lorsque le trafic cesse, les copies sont arrêtées. Sans rien en cours d'exécution, vous ne payez aucun calcul.

Une toute petite fonction serverless en JavaScript pourrait ressembler à ceci :

export default async function handler(request) {
  const { name } = await request.json();
  return Response.json({ message: `Hello, ${name}` });
}

Il n'y a aucun code pour démarrer un serveur, ouvrir un port ou garder un processus en marche. La plateforme s'occupe de tout cela.

Le terme « serverless » est aussi employé, de façon plus lâche, pour désigner d'autres services gérés qui s'adaptent automatiquement et se facturent à l'usage, comme les bases de données serverless, qui se mettent en pause lorsqu'elles sont inactives.

Termes clés

Exemple concret : un petit site de réservation

Le site de réservation d'un studio de yoga reçoit une vague de visites chaque dimanche soir, lorsque le nouvel horaire est publié, et très peu le reste de la semaine.

• Sur un serveur allumé en permanence, le studio paie une machine 24 h sur 24, dimensionnée pour la pointe du dimanche soir, et largement inactive le reste du temps.
• Avec des fonctions serverless, GET /api/classes et POST /api/bookings sont des fonctions. La ruée du dimanche lance automatiquement de nombreuses copies; un mardi matin calme, presque rien ne tourne et la facture est proche de zéro.

Les compromis apparaissent aussi. La première personne qui ouvre le site le mardi matin peut attendre un instant de plus à cause d'un démarrage à froid. La base de données doit gérer de nombreuses connexions de courte durée provenant de nombreuses copies de fonctions, ce qui peut nécessiter un regroupeur de connexions. Et si le studio veut plus tard une tâche « générer le PDF annuel de présence de tout le monde », elle risque de dépasser la limite de temps de la fonction et devoir s'exécuter ailleurs.

Quand le serverless convient, et quand il ne convient pas

Idées fausses courantes

• « Serverless veut dire pas de backend. » Cela signifie pas de serveurs à gérer. Vous écrivez et sécurisez toujours le code du backend.
• « Le serverless est toujours moins cher. » Il est bon marché pour un faible volume, mais la tarification à la requête peut s'accumuler avec un volume élevé et constant.
• « Le serverless s'adapte à l'infini. » Les plateformes ont des limites de concurrence, et votre base de données peut devenir le goulot d'étranglement bien avant les fonctions.
• « Les fichiers enregistrés dans une fonction seront encore là la prochaine fois. » Le stockage local est temporaire. Utilisez une base de données ou un stockage de fichiers.
• « La mise à l'échelle à zéro, c'est la même chose que le serverless. » Apparentés, mais non identiques. Certaines plateformes exécutent votre application comme un serveur ordinaire qui se met en veille lorsqu'il est inactif et se réveille à la requête suivante : les économies sont similaires, et le délai de la première requête aussi, mais sans les limites de temps propres aux fonctions par requête.

Quoi demander à votre générateur d'applications

• « Ce backend fonctionnera-t-il comme des fonctions serverless, ou comme un serveur toujours allumé ou en veille? Qu'est-ce que cela change pour le coût? »
• « Certaines tâches risquent-elles de dépasser la limite de temps de la plateforme? Si oui, comment devons-nous les gérer? »
• « Enregistre tout ce qui doit persister dans la base de données ou le stockage de fichiers, et non en mémoire ni dans des fichiers locaux. »
• « Comment gérer les connexions à la base de données si de nombreuses copies tournent en même temps? »
• « Quel est le délai de la première requête après une période d'inactivité de l'application? »

Comment Mythex héberge les applications

Mythex ne décrit pas son hébergement comme des fonctions serverless. Lorsque vous publiez, votre application s'exécute comme une application web normale ou un conteneur que Mythex gère pour vous : il n'y a aucun hébergement à configurer. C'est une mise à l'échelle à zéro : les applications publiées et leurs bases de données se mettent en veille lorsqu'elles sont inactives et se réveillent à la visite suivante; une application en veille ne consomme aucun calcul, et des machines supplémentaires ne démarrent que lorsque le trafic est élevé (Pro en permet jusqu'à 3 par service). La base de données Postgres associée se met aussi en veille après 5 minutes d'inactivité et est facturée pour le temps pendant lequel elle a été éveillée. Vous bénéficiez donc en grande partie du principe « payer ce que vous utilisez », avec le même genre de délai pour la première requête après une période calme. Voir les limites d'hébergement dans la documentation, ainsi que nos guides sur l'hébergement web et réduire les coûts d'hébergement.

Questions