- Le serverless semble simple, mais en réalité il entraîne de la complexité, des contraintes et des coûts élevés
- Les conteneurs offrent portabilité, persistance d’état et contrôle explicite, et conviennent mieux à la plupart des cas d’usage
- Le serverless a une structure tarifaire opaque, imprévisible, et introduit une complexité inutile entre les composants
- La scalabilité et la simplicité du serverless ne sont adaptées qu’à des cas d’usage limités
- En environnement de production réel, les déploiements basés sur des conteneurs sont plus simples, plus évolutifs et plus rentables
Serverless Is a Scam. Just Use a Container.
Qu’est-ce que le serverless ?
- Le serverless consiste à déployer du code sous forme de fonctions individuelles, la plateforme cloud se chargeant automatiquement de l’exécution et de la mise à l’échelle
- Mais en pratique, les problèmes suivants existent
- Limite de durée d’exécution (ex. : AWS Lambda est limité à 15 minutes)
- Absence de persistance d’état (réinitialisation à chaque exécution)
- Problèmes de cold start
- Environnement impossible à déboguer
- Paramétrage et configuration propres à chaque plateforme
- Usage excessif de YAML
- Cela paraît simple, mais c’est inadapté aux tâches complexes
Les conteneurs : simples, puissants et ennuyeux au bon sens du terme
- Les conteneurs présentent les avantages suivants
- Démarrage rapide
- Exécution possible dans n’importe quel environnement
- Persistance d’état possible (avec
Docker volume) - Aucune limite de durée d’exécution
- Liberté totale pour le débogage, le développement local et le passage à la production
- Exemple de code :
docker run -v my-data:/data my-app - Au final, il est possible d’exécuter des workloads avec état de manière cohérente partout
- Aucune dépendance à un fournisseur, aucun coût caché, aucune refonte d’architecture inutile
Tarification du serverless : conçue pour embrouiller les utilisateurs
- Le coût du serverless est structuré de manière très complexe
- Coût par appel
- Utilisation mémoire
- Temps d’exécution
- Volume de données transférées
- Variations selon la région
- Coût d’accès aux clés secrètes, etc.
- Exemples de termes déroutants :
- Provisioned Concurrency Units
- GB-seconds
- Requests Tier 1/2/3
- À cause de cette facturation imprévisible, on peut recevoir des factures inattendues
- En comparaison, un VPS à 5 $ offre un tarif fixe prévisible avec contrôle de toutes les ressources
Réponse à l’argument « le serverless est scalable »
- Le serverless est techniquement scalable, mais dans les faits, la plupart des apps n’en ont pas besoin
- La plupart des applications ont surtout besoin de
- Prévisibilité
- Observabilité
- Limites de ressources adaptées
- Environnements de développement et de staging
- Avec une approche basée sur des conteneurs, la montée en charge reste simple
replicas: 5 - Ou bien on peut faire du scale horizontal avec un load balancer
La conception stateless crée des problèmes artificiels
- Le serverless impose une architecture entièrement stateless
- Pas de cache, pas de session, pas de fichiers temporaires, pas de connexions persistantes
- Cela oblige donc à ajouter
- Une base de données externe
- Un cache distribué
- Un stockage de fichiers
- Un event bus
- Une machine à états
- Au final, une application serverless dite « simple » se retrouve avec plus de 6 dépendances SaaS
- À l’inverse, avec des conteneurs, on peut avoir
- Du cache en mémoire
- De l’écriture sur disque
- Des sessions persistantes
- Une exécution sans limite
Réponse à l’argument « je ne veux pas gérer de serveurs »
- Il existe des moyens d’utiliser des plateformes basées sur des conteneurs sans gérer soi-même les serveurs
- Utiliser des plateformes comme Sliplane, Railway, Coolify, etc.
- Ou simplement un VPS avec Docker + systemd
- Déploiement basé sur Git, rollback, logs, métriques : le confort opérationnel est assuré
- Cela permet aussi de comprendre et de contrôler l’ensemble du système
Réponse à l’argument « le serverless coûte moins cher »
- Cela peut être économique avec une fréquence d’appels extrêmement faible
- Mais le coût explose dans les cas suivants
- Si le trafic dépasse un certain niveau
- Si davantage de mémoire est nécessaire
- Si la charge de calcul réelle est importante
- Si les transferts de données sont volumineux
- Le serverless masque tout derrière la plateforme, ce qui rend l’optimisation difficile
- À l’inverse, les conteneurs
- Peuvent tourner en continu même sur du matériel peu coûteux
- Peuvent être combinés avec du cache et du stockage
- Sont faciles à benchmarker et à tuner
- N’ont pas de facturation à la milliseconde
Quand le serverless est réellement adapté
- Il convient à des tâches intermittentes et sans état comme
- Des fonctions orientées événements (ex. : redimensionnement d’images)
- Des tâches rares ou des webhooks
- Des outils internes
- Des POC
- Des besoins de scale up/down rapide
- Mais pour de vraies applications, on atteint vite ses limites,
- avec un prix élevé en temps, en argent et en complexité
Pourquoi les conteneurs sont un meilleur choix
- Les conteneurs apportent
- Portabilité
- Contrôle
- Simplicité
- Transparence
- Flexibilité
- Déploiement mono ou multi-conteneur, scaling, persistance d’état, tâches en arrière-plan, intégration DB : tout est possible
- Il est aussi possible de changer de plateforme sans réécrire le code
Résumé (TL;DR)
- Le serverless paraît séduisant en théorie
- Dans la réalité, c’est
- Opaque
- Coûteux
- Excessivement complexe
- Survendu
Avant de commencer, posez-vous la question :
« Est-ce que je ne pourrais pas simplement faire ça avec un conteneur ? »
- Si la réponse est oui, commencer avec un conteneur est un meilleur choix
Suite recommandée
- Il est recommandé de partager des cas où le serverless a entraîné des coûts imprévus ou des workflows inefficaces
- Évitez de rendre des problèmes simples inutilement complexes
19 commentaires
Il y a xfaas... il y a aussi cf workers. J'ai l'impression que c'est un article biaisé.
Je pensais à exécuter brièvement quelque chose en mode fonction serverless quand on loue un GPU.
Est-ce que c'est aussi possible avec des conteneurs ?
Dans les anciens services d’hébergement web PHP, si on enlève PHP pour le remplacer par du JS bien chargé en vendor lock-in....
je n’arrive pas à me défaire de l’idée qu’il devient difficile de faire la différence avec les plateformes FaaS serverless les plus connues.
Bien sûr, comme je suis un fin connaisseur des technos un peu douteuses qui utilise surtout PHP et JS/TS, je m’en sers avec satisfaction,
mais je ne comprends pas vraiment pourquoi autant de gens trouvent ça si bon.
À mon avis, utiliser un service serverless d’un fournisseur est risqué, mais fournir en interne un environnement serverless en s’appuyant sur des conteneurs me paraît être une bonne idée. Ce serait bien d’utiliser le serverless non pas comme un service, mais comme un concept.
Pendant un temps, le tweet et la vidéo[1] expliquant qu’ils avaient abandonné l’Edge rendering de Vercel, ainsi que l’article sur les serverless servers (mdr)[2], ont beaucoup fait parler d’eux. J’ai l’impression d’avoir un point de vue assez proche de celui des textes parus à ce moment-là.
C’est un avis personnel, mais du point de vue d’un développeur frontend, je pense qu’attacher des serverless functions aux requêtes des utilisateurs est encore une perspective lointaine (sauf si l’application qu’on veut créer est un MVP).
[1] https://youtu.be/lAGE-k1Zfrg
[2] https://vercel.com/blog/…
[2-1] https://bobaekang.com/blog/…
Bien sûr, comme cela a aussi été noté sur ce post, on dirait que c’est un article volontairement très racoleur :(
Ayant travaillé à la fois dans des environnements basés sur des conteneurs (principalement ECS Fargate et des clusters Kubernetes) et dans des environnements serverless (AWS), ça ne me parle pas vraiment tant que ça.
Les points présentés comme des avantages d’un environnement basé sur des conteneurs sont aussi, en même temps, des aspects qui peuvent devenir des inconvénients.
Tout ce qui est mentionné sous l’angle du « contrôle direct » et du fait de « pouvoir conserver un état » devient aussi, d’une certaine manière, autant de points de gestion supplémentaires qui rendent l’exploitation plus difficile.
Pour ma part, je recommande vivement le serverless, surtout aux petites organisations ou à celles qui n’ont pas d’équipe spécialisée dans l’administration serveur.
Ah, en revanche, je suis d’accord sur le fait que le calcul des coûts soit complexe ou difficile à prévoir, ainsi que sur le problème de vendor lock-in.
Puisqu’il y a des personnes qui parlent d’expérience de développement et d’observabilité, j’ajouterais ceci :
si l’on met bien en place l’environnement d’intégration initial, on peut obtenir une expérience de développement qui n’a rien à envier à une approche basée sur les conteneurs, voire qui est encore plus proche du natif. (Il existe d’ailleurs divers outils pour cela.)
Quant à l’observabilité, si l’on veut aller en profondeur, ni le serverless ni l’approche basée sur les conteneurs n’en font un sujet particulièrement simple. Centralisation des logs, visualisation de diverses métriques, APM, visualisation de l’utilisation CPU/mémoire et définition de stratégies de scaling en conséquence, etc.
Si l’on n’en est pas à ce niveau-là, l’intégration métriques/logs fournie par défaut par le cloud vendor est suffisamment puissante, donc au final c’est kif-kif.
Pour le dire de manière agressive, j’aurais envie de demander : « Jusqu’à quel point avez-vous vraiment fait du serverless correctement ? » 😅
Je me dis aussi qu’il vaudrait peut-être mieux ne lancer que certains endpoints nécessaires sur Lambda. Cela dit, comme je n’ai au départ aucune expérience du développement serverless, je ne peux pas vraiment me prononcer, mais j’ai quand même l’impression que cela pourrait convenir à quelques cas particuliers.
L’entreprise qui a écrit cet article étant justement une plateforme d’hébergement de conteneurs, n’est-ce pas un point de vue un peu biaisé ? haha
Il y avait déjà eu ici des personnes qui doutaient d’un article écrit côté frontend par un développeur de chez Netlify (un concurrent) à propos de Next.js (Vercel). Mais à voir les commentaires, ça n’a pas l’air particulièrement biaisé.
Moi, je suis plutôt du côté frontend... donc je ne suis pas très familier de ce domaine, mais le mème du serverless (avec des serveurs) revient souvent, j’ai l’impression haha
Le fait que l’expérience de développement soit nettement inférieure au natif est un point de douleur beaucoup trop important, et comme le logiciel lui-même devient dépendant du fournisseur d’infrastructure, une fois qu’on s’y est installé, il devient difficile d’en sortir. Il y a évidemment bien moins de références, et l’observabilité est beaucoup trop faible.
Cloudflare semble être celui qui essaie le mieux de faire du serverless par rapport aux autres entreprises. La base de données aussi est serverless, le stockage clé-valeur aussi est serverless, et il y a même des files de messages serverless...
(Bien sûr, à ce stade, on peut aussi ressentir un rejet face à l’impression de devenir complètement dépendant et prisonnier de la plateforme.)
Malgré cela, tant que le débogage, l’observabilité et l’expérience de développement ne s’améliorent pas, on continuera à faire du sur-place.
Cloud Run, foncez.
Exploiter un service en serverless, c’est choisir le mauvais outil.
Il existe des problèmes spécifiques pour lesquels le serverless est nécessaire. C’est adapté aux usages intermittents.
Pensez-vous la même chose des services de conteneurs serverless ?
À cause des problèmes des services serverless existants (comme Lambda), AWS a créé Fargate, puis même App Runner pour simplifier encore davantage 🤔
Il y a même Cloud Run de Google Cloud, un excellent service de conteneurs serverless avec
scale to zeroPersonnellement, parmi eux, c’est Cloud Run qui m’a offert la meilleure expérience de développement.
Le serverless (il y a bien des serveurs)
Avis de Hacker News
libcDès le départ, ce n’était pas du
serverless, mais duserverlease.MDRRRR