16 commentaires
C'est le vieux débat du contrôle vs vélocité. Avec Kubernetes, tu maîtrises ton stack, tes sidecars, ton réseau. Le serverless, c'est le syndrome de la boîte noire. Si tu as un cold start ou une limitation spécifique, tu es bloqué par le fournisseur cloud.
Le problème, c'est le lock-in. Si tu construis tout ton backend sur Lambda avec des triggers SQS et des tables DynamoDB, tu es marié à AWS pour les 10 prochaines années. Kubernetes te donne la portabilité.
Le serverless coûte une fortune à grande échelle. Dès que tu as un trafic constant, le coût par requête devient ridicule comparé à des pods réservés sur un cluster bien dimensionné.
Le souci c'est la complexité de debug. Tente de suivre une requête qui traverse 5 fonctions serverless sans un outil d'observabilité à 10k€ par mois.
Je trouve que le compromis idéal reste le conteneur géré type Cloud Run ou ECS Fargate. Tu gardes la logique du conteneur sans gérer le plan de contrôle K8s.
Et le monitoring ? PromQL sur K8s est super puissant. Dans le serverless, tu es limité aux métriques fournies par le cloud provider.
Le serverless, c'est bien pour les prototypes. K8s, c'est pour la scalabilité prévisible. Chaque outil a son usage.
Laisser une réponse
Vous devez être connecté pour poster un message !
Je lance ce débat car je vois trop d'équipes foncer tête baissée vers Kubernetes pour des besoins qui seraient gérés en 10 minutes avec du FaaS. On finit avec des clusters GKE ou EKS monstrueux, une complexité opérationnelle délirante, alors qu'on pourrait juste exposer une fonction.
Est-ce que l'abstraction du serveur n'est pas le futur, ou est-ce juste une prison dorée pour les équipes qui veulent éviter de gérer du
deployment.yaml?