Je me suis replongé dans mes souvenirs de l’époque où je ne comprenais rien au serverless et j’ai posé toutes les questions qui me venaient.

Le serveur a disparu ? L’identité du magicien

🧙‍♂️ (le professeur) «🐣, aujourd’hui nous allons parler de serverless. Rien qu’au nom, on dirait un sortilège pour faire disparaître les serveurs, mais la réalité est plus terre à terre — et bien plus profonde.»

🐣 (l’étudiant) «Il n’y a vraiment pas de serveurs ? Vous avez récité “Serveur, disparais !” comme Harry Potter et pouf, plus rien ?»

🧙‍♂️ (le professeur) «Ha ha, c’est exactement ce que neuf personnes sur dix s’imaginent au début ! Mais en vérité les serveurs n’ont pas disparu. Ils bossent à fond dans les coulisses du cloud. Simplement, l’utilisateur n’a plus besoin d’y penser.»

🐣 (l’étudiant) «Donc c’est de l’arnaque ? Comme des légumes “sans pesticides” alors que, caché des yeux du client, on arrose les champs de produits chimiques.»

🧙‍♂️ (le professeur) «La comparaison est complètement inattendue, mais tu n’as pas tort. Le “less” de serverless signifie “sans gestion”. Autrefois on adoptait un serveur, on installait l’OS, on gérait les pannes… exactement comme si on s’occupait d’un hamster. En serverless, le fournisseur cloud prend tout en charge.»

🐣 (l’étudiant) «Un hamster mort, ça fait pleurer, mais un serveur en panne, ce sont les clients qui hurlent. C’est pire.»

🧙‍♂️ (le professeur) «Et contrairement au hamster, il t’appelle à trois heures du matin : “La base de données ne répond plus.”»

📌 Note : les bases du serverless Le serverless ne signifie pas « sans serveur », mais que « la gestion du serveur est déléguée au fournisseur cloud ».

  • Modèle traditionnel : acheter, installer et administrer soi-même les serveurs.
  • Serverless : le fournisseur gère toute l’infrastructure et l’utilisateur se concentre sur le code.

Comment fonctionne le serverless : un ninja qui n’apparaît que lorsqu’on l’appelle

🐣 (l’étudiant) «Ça a l’air compliqué à utiliser. Qu’est-ce qui change vraiment par rapport à un serveur classique ?»

🧙‍♂️ (le professeur) «C’est vrai que c’est différent. En serverless, tout démarre d’un coup quand on l’appelle, traite la requête, puis disparaît aussitôt. L’application doit donc être pensée comme un sprinter. Les marathoniens ne sont pas les bienvenus.»

🐣 (l’étudiant) «Donc on dit “Fais ce calcul tout de suite !”, il surgit, et quand on répond “Terminé”, il repart ?»

🧙‍♂️ (le professeur) «Exactement ! C’est un ninja qui n’apparaît que lorsqu’on l’invoque. Tant qu’il est caché dans les nuages, tu ne payes pas de loyer pour le temps passé à ne rien faire.»

🐣 (l’étudiant) «Mais les ninjas n’apparaissent jamais au même endroit. Et l’adresse IP, dans tout ça ?»

🧙‍♂️ (le professeur) «Bien vu ! Il n’a pas d’adresse fixe. À chaque exécution, le serveur change. C’est pour ça que l’API Gateway du cloud joue le rôle du gardien du village ninja, qui distribue les requêtes au bon guerrier.»

🐣 (l’étudiant) «Je vois. Mais si le ninja change à chaque fois, il ne se souvient pas de la mission précédente ?»

🧙‍♂️ (le professeur) «Exact. D’où la nécessité d’une conception stateless. Pas de “Ah, on reprend là où on s’est arrêtés hier”. C’est un poisson rouge qui recommence chaque conversation par “Enchanté”.»

🐣 (l’étudiant) «Ce n’est pas pratique. Et l’authentification, les sessions ?»

🧙‍♂️ (le professeur) «On confie l’état à une base de données ou à Redis. Le ninja lui-même n’a pas de mémoire. Les informations importantes restent dans un “entrepôt de parchemins”.»

📌 Note : l’importance d’une conception stateless Les fonctions serverless démarrent dans un nouveau conteneur à chaque exécution, donc l’état local (variables, fichiers, sessions) n’est pas conservé.

  • Gestion d’état : utiliser une base externe, Redis, S3, etc.
  • Sessions : stocker des jetons JWT ou utiliser un stockage externe.
  • Fichiers : tout ce qui dure doit aller dans un stockage externe.

Par rapport aux serveurs traditionnels : animaux de compagnie vs ninjas

🐣 (l’étudiant) «Concrètement, ça ressemble à quoi ?»

🧙‍♂️ (le professeur) «Imagine un service qui crée une miniature à chaque fois qu’on téléverse une image. Avec un serveur classique, tu as une machine qui tourne 24 h/24 en attendant “Quelqu’un ? Personne ?”. Tu payes l’électricité, et en cas de panne tout s’arrête.»

🐣 (l’étudiant) «Comme un garde planté devant la porte qui attend désespérément un visiteur.»

🧙‍♂️ (le professeur) «Exact ! Et en plus ce garde peut attraper la grippe. Avec le serverless, une cloche sonne quand “Une image vient d’être envoyée !” et le ninja apparaît pour fabriquer la miniature avant de disparaître.»

🐣 (l’étudiant) «Efficace. Mais le ninja ne met-il pas du temps à arriver ?»

🧙‍♂️ (le professeur) «C’est le fameux problème du cold start. S’il dormait profondément, il lui faut quelques secondes pour se réveiller. Avec un langage lourd comme Java, c’est le ninja qui déjeune et déroule son tapis de yoga avant de travailler.»

🐣 (l’étudiant) «Frustrant. Donc pas adapté au temps réel ?»

🧙‍♂️ (le professeur) «Il existe des mécanismes de préchauffage, mais le serverless excelle surtout pour les traitements batch et asynchrones. Les “Réponds-moi maintenant !” l’agacent.»

Un exemple concret : l’application de partage photo

🐣 (l’étudiant) «Donnez-moi un exemple concret. Mettons qu’on crée une application de partage photo ?»

🧙‍♂️ (le professeur) «Bonne idée. En mode classique, ça donnerait :»

Serveur traditionnel :

Serveur web 24 h/24 (5 000 ¥ par mois)
↓
“Photo téléversée”
↓
La miniature est créée sur le serveur
↓
Stockage en base de données

🧙‍♂️ (le professeur) «Là, même si personne n’envoie de photo, tu continues de payer 5 000 ¥ par mois. C’est comme un magasin dont le loyer ne baisse jamais même sans clients.»

🐣 (l’étudiant) «C’est du gâchis.»

🧙‍♂️ (le professeur) «En serverless, ce serait :»

Version serverless :

L'image est envoyée vers S3
↓
L'événement S3 déclenche une fonction Lambda
↓
La fonction Lambda se lance (0,1 s)
↓
Elle crée la miniature et la stocke dans un autre bucket S3
↓
La fonction Lambda s'éteint
↓
Facturation : seulement le temps d'exécution (environ 0,001 ¥ par appel)

🐣 (l’étudiant) «Donc si personne ne l’utilise, c’est gratuit ?»

🧙‍♂️ (le professeur) «Exact ! Tu payes uniquement ce que tu consommes. Mais si la moindre vidéo devient virale, la facture explose aussi. Si une vidéo est partagée et déclenche un million de traitements…»

🐣 (l’étudiant) «La facture grimpe à 1 000 ¥ !»

🧙‍♂️ (le professeur) «Le calcul est bon, mais n’oublie pas les frais de transfert, l’API Gateway, les bases de données… On atteint facilement plusieurs centaines de milliers de yens. C’est la tragédie moderne du “Buzz, gloire et faillite”.»

📌 Note : avantages et risques de la facturation à l’usage

Avantages

  • Coût initial quasi nul.
  • Scalabilité automatique selon l’usage.
  • Pas de gestion d’infrastructure.

Risques

  • Factures imprévues (surtout en cas de buzz).
  • Tarification complexe.
  • Visibilité réduite quand plusieurs services sont combinés.

Mesures

  • Configurer des alertes de facturation.
  • Mettre en place des limites de taux.
  • Faire des tests de charge et des estimations de coût préalables.

Les différents types de serverless : les spécialités des ninjas

🐣 (l’étudiant) «On m’a dit qu’il existait plusieurs styles de serverless ?»

🧙‍♂️ (le professeur) «Trois écoles principales : FaaS (Function as a Service), BaaS (Backend as a Service) et les conteneurs serverless.»

🐣 (l’étudiant) «C’est quoi FaaS ?»

🧙‍♂️ (le professeur) «Le service du “Je m’occupe uniquement de tes fonctions”. AWS Lambda, Google Cloud Functions, Azure Functions… Tu écris ta fonction, tu la leur confies et ils la servent à la demande, comme un restaurant de sushis où tu ne payes que ce que tu consommes.»

🐣 (l’étudiant) «Et BaaS ?»

🧙‍♂️ (le professeur) «Le forfait “On gère pour toi la base de données, l’authentification, les notifications push”. Firebase, Supabase, AWS Amplify… C’est comme vivre chez ses parents : tout est fait pour toi.»

🐣 (l’étudiant) «Vivre chez ses parents, c’est confortable, mais il faut suivre leurs règles.»

🧙‍♂️ (le professeur) «Exactement ! C’est le risque du vendor lock-in. Tu te réveilles un jour dépendant d’un service dont tu ne peux plus te passer.»

Ce que le serverless fait bien… ou mal

🐣 (l’étudiant) «Alors, pourquoi ne pas rester sur des serveurs classiques ? Pourquoi se compliquer la vie ?»

🧙‍♂️ (le professeur) «Pour la vitesse. Tu peux déployer une idée sur un coup de tête et la mettre en ligne le lendemain. Tant que l’usage est faible, le coût frôle zéro. “J’ai eu une idée cette nuit, je la publie demain matin” : c’est possible.»

🐣 (l’étudiant) «Mais ce n’est pas adapté à tout, si ?»

🧙‍♂️ (le professeur) «Non. Ses forces et faiblesses sont très marquées.»

Ce qu’il fait bien :

  • Traitement d’images (téléversement → miniature).
  • Conversion de données (CSV → JSON).
  • Notifications (emails, push).
  • Tâches planifiées (rapport quotidien).
  • Petites API (recherche d’utilisateurs, récupération de données).

Ce qu’il fait mal :

  • Temps réel (chat, jeu).
  • Longs traitements (encodage vidéo, apprentissage machine).
  • Applications nécessitant beaucoup d’état partagé.
  • Intégration étroite avec des systèmes legacy.

🐣 (l’étudiant) «Donc c’est très explosif mais sans endurance ?»

🧙‍♂️ (le professeur) «Exact. Excellent sur 100 mètres, mauvais sur marathon.»

Le piège de la facturation : des ninjas payés à l’heure

🐣 (l’étudiant) «Il ne faut pas être un bourrin, sinon la facture te tue, mais avec un cerveau ça rapporte ?»

🧙‍♂️ (le professeur) «C’est exactement ça. Le serverless récompense les gens qui réfléchissent et punit ceux qui se relâchent. Si tu ne comprends pas la facturation, c’est l’enfer.»

🐣 (l’étudiant) «Quel genre d’enfer ?»

🧙‍♂️ (le professeur) «Imagine que tu écrives une boucle infinie. Sur un serveur classique, il devient juste lent. En serverless, c’est comme si on invoquait une armée infinie de ninjas.»

🐣 (l’étudiant) «Ils travaillent sans arrêt et envoient leur salaire à l’infini ? C’est un film d’horreur.»

🧙‍♂️ (le professeur) «Et tu t’en rends compte à la facture de fin de mois : “Pourquoi je dois 1 million de yens ?”. Des cas à plusieurs millions chez AWS, il y en a plein.»

🐣 (l’étudiant) «Terrifiant. On peut se protéger ?»

🧙‍♂️ (le professeur) «Bien sûr. Alertes de facturation, durée maximale d’exécution, limite de concurrence… C’est comme rédiger un contrat d’embauche avec ton ninja.»

Un vrai fiasco : quand le buzz tourne au cauchemar

🐣 (l’étudiant) «Vous avez des exemples de factures monstrueuses ?»

🧙‍♂️ (le professeur) «Une quantité. L’histoire célèbre, c’est l’appli de retouche photo qui a reçu 3 millions de yens en un mois.»

🐣 (l’étudiant) «Aïe. Détails ?»

🧙‍♂️ (le professeur) «Une start-up avait lancé une appli “photo plus belle grâce à l’IA”. Ils pensaient payer 0,1 ¥ par traitement.»

🐣 (l’étudiant) «Et alors ?»

🧙‍♂️ (le professeur) «Elle a explosé sur les réseaux. Un million de photos par jour. Chaque image prenait bien plus de temps que prévu, donc le coût réel est monté à 3 ¥ l’unité.»

🐣 (l’étudiant) «Un million × 3 ¥ = 3 millions…»

🧙‍♂️ (le professeur) «Et ça a duré trente jours. “On a buzzé, on a gagné en notoriété, puis on a coulé.”»

🐣 (l’étudiant) «Ils n’avaient rien prévu ?»

🧙‍♂️ (le professeur) «Pas de limite de facturation. Ils pensaient “Jamais ça n’ira si loin”. Aujourd’hui, limiter le succès est devenu la norme.»

🐣 (l’étudiant) «Mettre une limite au succès, c’est ironique.»

🧙‍♂️ (le professeur) «Le “cri de joie” devient très vite un vrai cri.»

L’expérience développeur : le plaisir magique et la souffrance des contraintes

🐣 (l’étudiant) «Et côté développement, on s’y prend comment ? C’est différent d’un programme classique ?»

🧙‍♂️ (le professeur) «Au début, c’est grisant. Tu écris une fonction, tu cliques, et c’est en ligne. Tu te sens magicien.»

🐣 (l’étudiant) «Ça a l’air fun.»

🧙‍♂️ (le professeur) «Mais en avançant, tu déchantes. Les tests locaux sont difficiles, le debug pénible. Quand ça ne marche pas, le ninja a déjà disparu. Il ne reste que les logs à fouiller.»

🐣 (l’étudiant) «Comme arriver sur une scène de crime avec uniquement des preuves à analyser.»

🧙‍♂️ (le professeur) «Parfaitement dit. Et les logs sont dispersés entre CloudWatch, X-Ray, CloudTrail… Tu te transformes en détective.»

🐣 (l’étudiant) «Ça donne envie de revenir aux serveurs classiques.»

🧙‍♂️ (le professeur) «C’est le piège du serverless. Au début c’est de la magie, ensuite une malédiction. Mais quand tu t’y habitues, tu ne veux plus nourrir de serveurs.»

🐣 (l’étudiant) «Donc ça crée une dépendance ?»

🧙‍♂️ (le professeur) «Oui. Le plaisir de “ne pas gérer de serveurs” est addictif. En échange, tu gagnes du stress : la facturation et les contraintes de conception.»

Serverless vs serveurs classiques : la réalité des coûts

🐣 (l’étudiant) «Au final, c’est lequel le moins cher ?»

🧙‍♂️ (le professeur) «Ça dépend de l’usage et de la prévisibilité. Regarde ce schéma :

Serveur classique

  • Coût fixe : 50 000 ¥/mois.
  • Coût variable : quasi nul.
  • Modèle “restaurant fixe”.

Serverless

  • Coût fixe : quasi nul.
  • Coût variable : selon l’usage.
  • Modèle “sushi à l’assiette”.»

🐣 (l’étudiant) «Donc tout dépend de l’appétit.»

🧙‍♂️ (le professeur) «Exact. Petit mangeur → sushi ; gros mangeur → restaurant fixe. Plus concrètement :

Moins d'1 million de requêtes par mois : le serverless est imbattable. Plus de 10 millions : le serveur classique devient rentable. Entre les deux : ça se discute, surtout en comptant l’exploitation.»

🐣 (l’étudiant) «Et si on se trompe de prévision ?»

🧙‍♂️ (le professeur) «C’est là que ça devient un pari. Mauvaise prévision = tu réserves un resto fixe pour une fringale et tu n’as pas faim, ou tu vas au sushi-bar pour un repas léger et tu déclenches un concours de gloutons.»

Le serverless va-t-il triompher ?

🐣 (l’étudiant) «Alors, victoire ou échec ?»

🧙‍♂️ (le professeur) «Ni l’un ni l’autre. Les serveurs classiques, les conteneurs et le serverless vont coexister, chacun dans sa spécialité. Le monde a besoin de ninjas, de chevaliers et de magiciens.»

🐣 (l’étudiant) «Donc aucune technologie ne résout tout.»

🧙‍♂️ (le professeur) «Exact. Pas de balle en argent. Mais bien utilisé, c’est un outil extrêmement puissant.»

🐣 (l’étudiant) «À qui le recommandez-vous ?»

🧙‍♂️ (le professeur) «À ceux qui ressemblent à ceci :

Profil adapté au serverless

  • Veut un prototype opérationnel très vite.
  • Comprend la tarification.
  • Préfère la gestion simplifiée au contrôle total.
  • S’enthousiasme pour les nouvelles technologies.

Profil mal adapté

  • Artisans qui veulent tout contrôler eux-mêmes.
  • Mauvaise gestion budgétaire.
  • Priorité absolue à la stabilité.
  • Pieds collés aux systèmes legacy.»

🐣 (l’étudiant) «Donc il faut aimer l’innovation et compter ses sous.»

🧙‍♂️ (le professeur) «Jolie formule. C’est une technologie pour les innovateurs pingres.»

Conclusion : une manière de vivre serverless

🐣 (l’étudiant) «Au final, vous le recommandez ?»

🧙‍♂️ (le professeur) «Je ne dis pas “Adopte-le” mais “Comprends-le et utilise-le à bon escient”. Le serverless est un sort moderne où l’on pèse la tentation de la commodité face à la réalité du risque.»

🐣 (l’étudiant) «Un sort… et mal prononcé, il te revient en pleine figure.»

🧙‍♂️ (le professeur) «Précisément. D’où l’importance d’apprendre la bonne incantation. Le serverless récompense les cerveaux et fait exploser ceux qui baissent la garde. Les bourrins n’y survivent pas, mais les gens malins en font une arme redoutable.»

🐣 (l’étudiant) «Donc en résumé :

  • Exploiter des serveurs : un entraînement infernal à la force brute.
  • Serverless : une survie calculée à coups de factures. C’est bien ça ?»

🧙‍♂️ (le professeur) «Résumé parfait. Le choix dépend du contexte, mais “ne rien choisir” n’est plus une option. L’ingénieur moderne doit décider s’il sera chevalier, ninja ou magicien.»

🐣 (l’étudiant) «Compris. Je commence par les bases, le ninjutsu viendra après.»

🧙‍♂️ (le professeur) «Avec cet état d’esprit, tu deviendras un grand maître ninja. Mais garde toujours un œil sur la facture.»

🐣 (l’étudiant) «Oui ! Je configurerai les alertes de facturation !»

📌 Note finale : un cadre de décision pour adopter le serverless

Décider d’adopter le serverless suppose d’évaluer ces facteurs :

Facteurs techniques

  • Nature du traitement (batch ou temps réel).
  • Fréquence d’exécution (faible ou élevée).
  • Besoin de gestion d’état.
  • Intégration avec des systèmes legacy.

Facteurs business

  • Budget d’investissement initial.
  • Compétences de l’équipe d’exploitation.
  • Fiabilité des prévisions de croissance.
  • Tolérance au vendor lock-in.

Conclusion : le serverless n’est pas une panacée, mais une technique spécialisée qui brille dans les bons contextes. Avec une compréhension et une préparation adéquates, c’est une arme puissante. Une adoption impulsive, en revanche, peut se traduire par une facture salée.

Pour l’ingénieur d’aujourd’hui, le serverless est un choix à connaître et un outil à employer avec discernement.