Contexte et problème d’inactivité
Lors du lancement d’AWS Lambda Web Functions en octobre 2026, Easel a testé la capacité du service à gérer un site Next.js 16. Les premiers essais ont montré que 300 requêtes simultanées étaient traitées sans erreur et qu’une nouvelle fonction était prête en moins de neuf secondes. Cependant, les environnements d’exécution restaient actifs bien après la dernière requête, ce qui a déclenché le problème d’inactivité étudié.
Analyse des coûts de mémoire
Les mesures effectuées sur six environnements représentatifs ont révélé des périodes d’inactivité comprises entre 313 s et 411 s, soit 5 à 7 minutes. Pendant ces intervalles, la facturation de la mémoire se poursuit alors que le CPU n’est plus utilisé. Pour une requête de 200 ms suivie de 345 s d’inactivité, le temps facturé en mémoire dépasse 1 700 fois la durée réelle de la requête. En appliquant les prix publiés, la mémoire représente environ 88 % du coût total calculé (compute + requêtes), même si l’application n’utilise que 160–210 Mo. Le coût total de l’expérience s’élève à deux centièmes de dollar, un montant négligeable isolément mais potentiellement significatif à l’échelle de milliers d’applications.
Comparaison de performances
Pour évaluer l’impact sur la latence, Easel a déployé la même application sur son propre serveur US East et sur Lambda Web Functions, puis a exécuté des benchmarks depuis Ashburn, Virginie. Les temps de réponse à chaud sont 1,5 à 3 fois plus rapides sur l’infrastructure propriétaire. Un test de charge CPU consistant en 20 000 opérations SHA‑256 en chaîne a donné 29,2 ms contre 43,8 ms, soit une amélioration de 1,5 ×. Les démarrages à froid, mesurés après 12 minutes d’inactivité, montrent que le serveur interne répond environ 3,5 fois plus vite. Après une pause de cinq minutes, Web Functions met 908 ms à répondre, alors que le serveur interne reprend en 14 ms, illustrant la pénalité d’attente liée à la persistance de l’environnement.
Enjeux de l’auto‑hébergement
Passer à une infrastructure auto‑gérée implique la gestion de la capacité, de la résilience et de la répartition des ressources entre applications. L’avantage principal réside dans le contrôle du cycle de vie des environnements, éliminant les frais de mémoire inutiles et permettant le partage de capacité. Le modèle reste pertinent pour les charges à trafic soutenu, où les coûts d’inactivité sont amortis, mais pour Easel, la multiplication d’applications à trafic irrégulier rend la solution interne économiquement plus viable tout en conservant des performances supérieures.
