AWS Lambda
Ce que c'est et pourquoi c'est terrible
Une présentation et une démonstration en direct mettant en évidence le ventre sombre des solutions "sans serveur", en choisissant AWS Lambda car c'est le plus préalable. Nous construisons un HitCounter à l'ancienne dans Lambda + DynamoDB et comparons cette approche à CGI + SQLite.
Contour
- La latence élevée lors de la réinstallation de nouvelles instances.
- Le nouveau modèle "de concurrence provisoire" est AWS Billing Double-Speak, pourquoi ne pas acheter une machine virtuelle?
- Le débogage est un cauchemar:
- Les journaux ne viennent pas immédiatement par CloudWatch
- Pas de ptrace ou de bpftrace pour le débogage de la production
- Non au sommet de la compréhension de l'utilisation des ressources.
- Modèle d'emballage et de déploiement étrange qui n'est pas utilisé ailleurs.
- En pratique, vous devez utiliser un framework comme Serverless ou Zappa
- Ils gèrent certains mais pas tous pour vous - où doit être tracé la ligne?
- Les "serveurs de correction" sont-ils vraiment si difficiles? Yumcron, quelqu'un?
- Fournir des secrets signifie utiliser + payer pour AWS Secrets Manager
- Aucun gestionnaire de secrets signifie garder des secrets en texte en clair quelque part
- Éviter les secrets signifie compter pleinement sur IAM, qui peut être facile à bousiller
- Les performances du réseau sont proportionnelles à l'allocation de la mémoire
- Cela vous fait payer bien plus que ce dont vous avez besoin pour obtenir une application réactive
- Spéculation: cela provient de la RAM sursubscriptive via KSM, ne peut pas faire de même avec le réseau
- Lambda permet d'économiser de l'argent lorsque les applications sont principalement désactivées, mais le temps du développeur ne sera jamais payant.
Remerciements
- Abe Simpson Image © 20th Century Fox
- Problèmes modernes Meme © Dave Chappelle / Comedy Central
- Commentaires critiques de @ myoung34
