Histoires d’horreur du serverless

Histoires d’horreur du serverless

• Histoires d’horreur du serverless est un blog simple qui partage des expériences cauchemardesques survenues lors de l’utilisation de technologies serverless.
• Ce blog a été créé par Andras, qui développe Coolify, une alternative open source et auto-hébergeable à Heroku / Netlify / Vercel.
• Les personnes ayant une histoire d’horreur liée au serverless peuvent envoyer leur récit à Andras ou le partager en ouvrant une PR sur GitHub.

Cas notables de coûts serverless

• 27 mars 2020 : un cas où quelqu’un a dépensé 72 000 dollars en testant Firebase et Cloud Run, frôlant presque la faillite.
• 27 février 2024 : quelqu’un a reçu un e-mail de Netlify pendant le week-end indiquant qu’une facture de 104 500 dollars était en retard de paiement.
• 13 février 2024 : quelqu’un a spammé EchoFox, faisant grimper la facture Vercel à 23 000 dollars et provoquant plus de 56 000 comptes et essais.
• 5 avril 2023 : un retour d’expérience avertissant les utilisateurs de Vercel d’être prudents lors des tests ou des déploiements sur Vercel.

L’avis de GN⁺

• L’architecture serverless est attractive pour les développeurs grâce à une infrastructure sans gestion, mais ces cas montrent que les coûts imprévus peuvent devenir un problème majeur.
• Ces exemples soulignent l’importance d’une gestion rigoureuse des coûts et du monitoring lors de l’utilisation de services serverless.
• Avant d’adopter une technologie serverless, il est recommandé d’utiliser des outils offrant des fonctions de prévision des coûts et de définition de plafonds.
• Même avec d’autres produits serverless comme AWS Lambda, des problèmes de coûts similaires peuvent survenir ; il est donc important de choisir un service en tenant compte de son efficacité économique.
• Les avantages de cette technologie sont un déploiement rapide et une bonne scalabilité, mais si l’usage réel est mal anticipé, il existe un risque de dépasser le budget.

[GN⁺]

Commentaires Hacker News

• Résumé des commentaires sur Netlify :

  • Un utilisateur a indiqué qu’il hébergeait un fichier audio de 3,44 Mo sur son site web et qu’à cause de cela, il avait subi une attaque DDoS. Bien qu’il utilisât un compte gratuit chez Netlify, il a souligné qu’il risquait de recevoir une facture très élevée en raison des coûts liés à un trafic excessif.
  • Un autre utilisateur a jugé cette situation regrettable, affirmant qu’un fichier de 3,44 Mo ne devrait pas poser problème et que la solution consistant à l’héberger ailleurs n’était pas appropriée. Il a également insisté sur le fait que le « gratuit » n’existe pas réellement et qu’il faudrait davantage de mesures pour éviter ce type de situation.
  • Il a été mentionné qu’un VPS (Virtual Private Server) est peu coûteux, facile à administrer et dispose automatiquement de limitations de trafic.

• Résumé des commentaires sur Coolify :

  • Un utilisateur a évoqué Andres, qui développe Coolify, une alternative auto-hébergée similaire à Heroku/Netlify. Il a expliqué utiliser Coolify depuis plusieurs mois et a salué l’aide que cela lui a apportée pour auto-héberger plusieurs services.
  • Il a été mentionné que la communauté Coolify grandit, que des utilisateurs ajoutent de nouveaux templates et s’entraident pour le débogage.
  • Comme inconvénient, il a été signalé que des problèmes peuvent survenir lorsque l’espace disque vient à manquer, et qu’il faudrait de meilleurs avertissements ou des mesures préventives à ce sujet.

• Résumé des commentaires liés à l’architecture serverless :

  • Il a été affirmé que le problème survenu chez Netlify n’était pas dû à l’architecture serverless. Bien que le serverless comporte plusieurs problèmes techniques, la facturation massive liée au trafic serait un problème indépendant du serverless.
  • Il a été mentionné qu’une situation similaire pourrait se produire même avec son propre matériel placé dans un data center et des frais de trafic à payer, en l’absence de protection DDoS.
  • Il a été souligné que le principal problème réside dans les coûts de trafic excessifs et l’absence d’atténuation DDoS.

• Résumé des commentaires liés à la décision de quitter Netlify :

  • Un utilisateur a déclaré avoir décidé de migrer son site personnel de Netlify vers une autre solution. Il a précisé que la migration consistait principalement à mettre à jour le DNS, et qu’il préférait générer le HTML en local avant de le téléverser.
  • Il a trouvé étrange que la plupart des solutions populaires ne permettent pas de définir un plafond de dépenses.

• Résumé des commentaires sur la surfacturation des fournisseurs cloud :

  • Il a comparé le fait que les fournisseurs cloud facturent des montants excessifs à un garagiste qui remplacerait en boucle une pièce défectueuse avant de présenter une facture énorme.
  • Il a indiqué qu’en tant que petit utilisateur, il lui est impossible de lire et comprendre l’intégralité de la documentation, et qu’il souhaite une fonctionnalité permettant d’arrêter le service lorsqu’un plafond de dépenses est atteint.

• Résumé des commentaires liés aux clés d’API OpenAI :

  • Un utilisateur a mentionné que lorsqu’il enregistre une clé d’API OpenAI, il applique par défaut un quota, puis désactive la clé en cas de dépassement.
  • Il s’est dit surpris que davantage d’entreprises n’adoptent pas cette approche, estimant qu’elle permettrait de protéger tout le monde contre les factures imprévues.

• Résumé des commentaires sur les problèmes des services cloud :

  • Il a été souligné que nous acceptons que les fournisseurs cloud facturent le trafic inter-AZ (zones de disponibilité) comme mesure d’atténuation de leurs propres problèmes potentiels.

• Résumé des commentaires sur le manque de réaction de Netlify :

  • Une déception a été exprimée face au fait que Netlify facture trop cher la bande passante sans fournir aux clients d’outils pour réagir à des attaques qu’ils ne peuvent pas contrôler.
  • Netlify a été critiqué pour son manque d’intérêt à résoudre le problème alors qu’il existerait plusieurs moyens d’y parvenir. À titre d’exemple, diverses options proposées par le CDN bunny.net ont été mentionnées.

• Résumé des commentaires sur la nécessité de fixer un plafond de dépenses :

  • Il a été souligné que la possibilité de fixer un plafond de dépenses n’est pas un problème du serverless, mais du cloud.
  • Il a été mentionné qu’un petit serveur cloud peut tomber en panne s’il subit une attaque, et qu’il est préférable, comme avec AWS, de ne payer que pour le trafic sortant.