Lambda, Cloud Run, Vercel Functions. Quand le Pay-per-Request est plus économique qu'un serveur — et quand non.
Catégorie · DevOps & Infra
Aucun serveur, juste une fonction.
Serverless ne veut pas dire qu'aucun serveur ne tourne, mais qu'on ne s'en occupe pas. On téléverse du code — AWS Lambda, Google Cloud Run, Vercel Functions — et le fournisseur le lance à chaque requête.
On ne paie que l'exécution réelle. S'il n'y a aucune requête, rien ne tourne et rien ne coûte.
Quand le pay-per-request l'emporte.
Pour une charge sporadique ou très fluctuante, le serverless est souvent le choix le moins cher et le plus simple : webhooks, jobs en arrière-plan, traitement d'événements, endpoints au trafic irrégulier.
Nous l'utilisons là où une machine dédiée passerait l'essentiel de son temps à consommer du courant sans rien faire — la mise à l'échelle de zéro à de nombreuses requêtes est gérée par la plateforme.
Quand un serveur est moins cher.
Pour une charge élevée et constante, le calcul s'inverse : un serveur utilisé en continu revient alors bien moins cher par requête que des millions d'appels facturés un à un chaque mois.
S'y ajoutent les cold starts au premier appel et des limites de durée d'exécution strictes. Les processus longs, gourmands en mémoire ou critiques en latence s'intègrent mal au modèle serverless — ici, c'est le profil de charge qui décide, pas la tendance.
