Les

services marketing des fournisseurs de cloud nous racontent la même histoire depuis des années : « Oubliez l'infrastructure, concentrez-vous uniquement sur votre code, ne payez que pour ce que vous utilisez. » Ça a l'air génial, n'est-ce pas ? En théorie, oui. Mais dans la pratique, Serverless peut parfois devenir un trou noir financier invisible

.

Soyons honnêtes ; le modèle « pay-as-you-go » évolue très rapidement vers le modèle « Pay-as-you-panic » si vous ne savez pas exactement ce que vous faites. Examinons d'un œil sceptique les coûts cachés de ces superbes présentations et comment survivre à ce chaos

.

1. La « gratuité » n'existe pas : Invisible Killers

Quand il s'agit de Serverless, tout le monde ne pense qu'au temps d'exécution. Vous expliquez « Ma fonction a fonctionné 100 ms, j'ai payé autant de centimes ». Vous vous trompez. Les principaux éléments qui font gonfler la facture sont généralement les suivants

 :
  • Transfert de données (sortie) : Sortir des données du Cloud coûte souvent cher à cause de la fonction elle-même.
  • Passerelle API : Cette « passerelle » qui permet d'ouvrir les portes Lambda ou Azure Functions vers le monde entier génère parfois des coûts supérieurs à la puissance de traitement qui la sous-tend.
  • Journalisation et observabilité : Dès que vous avez dit « enregistrons tout ce dont nous avons besoin », vous êtes épuisée. Les frais d'ingestion de journaux pour CloudWatch ou des services similaires peuvent vous faire dire « J'aurais aimé ne pas en savoir autant » à la fin du mois
.

2. Cold Start : pas seulement des performances, c'est une perte d'argent

Tout le monde parle du problème de latence de Cold Start. Mais un expert sceptique demande : « Combien d'argent est-ce que je perds pendant ce retard ? » Si votre application est destinée aux utilisateurs et qu'elle quitte le panier à cause de ce délai de 2 secondes, le coût de cette fonction est bien supérieur à 0,00001

dollar selon la documentation technique.
La mise à l'échelle est une bonne chose, mais la limite entre le coût d'une simultanéité provisionnée inactive et le coût d'une machine virtuelle traditionnelle est plus mince que vous ne
le pensez.

Décision architecturale 3 : Quand s'évader ?

À un moment donné, vous devez vous arrêter et demander : « Pourquoi n'utilisons-nous pas Kubernetes ou un serveur bare-metal ? » Si votre trafic est stable, prévisible et élevé 24 heures sur 24, 7 jours sur 7, Serverless est le choix le plus cher

pour vous.

Serverless est une aubaine pour le trafic élevé (incertain et qui monte en flèche). Mais utiliser Serverless sur un système qui fonctionne en permanence revient à prendre un taxi pour aller au travail tous les jours. Il est bien plus logique d'acheter (ou de louer) une voiture après un certain temps

.

4. La « vraie » recette de l'optimisation

Alors, comment protéger le portefeuille ?

  • Culture FinOps : Le suivi des coûts n'est pas seulement l'affaire du comptable, mais aussi du développeur. Vous ne pouvez pas être « senior » sans savoir combien coûte le code que vous écrivez
  • . Le
  • piège de la granularité : diviser l'application en milliers de petites fonctions (nano-services) augmente les coûts de gestion et de communication. Faites des regroupements logiques
  • .
  • Paramètres de temporisation : les délais d'attente de 5 minutes restants par défaut sont dangereux. Vous ne voulez pas payer la facture pour la fonction qui entre dans une boucle erronée
.

Le dernier mot : le cloud n'est pas une technologie, c'est une stratégie financière

En fin de compte, les fournisseurs de cloud ne sont pas des organisations caritatives. Le mode Serverless offre une grande agilité lorsqu'il est configuré correctement ; s'il est mal configuré, cela vous fait encore plus mal qu'une dette technique, c'est-à-dire une dette réelle. Lorsque vous prenez vos décisions en matière d'infrastructure, ne pensez pas « c'est le plus récent », mais « c'est le plus durable

 ».