Ne vous laissez pas berner par le serverless
(world.hey.com)- Un texte de DHH, le créateur de RoR
- Les fans du cloud affirment que tout — coûts, performances, complexité, etc. — se résout comme par magie dès qu’on passe au « serverless »
- Le cloud/VPS fonctionne selon le principe de l’achat en gros puis de la revente au détail
- Acheter un gros serveur à 1 000 $ et le louer à 7 personnes pour 200 $ chacune afin de dégager 400 $ de profit par mois
- Cela fonctionne bien si ces 7 personnes ne mettent pas une forte charge sur le serveur, ou l’utilisent à des moments différents
- Si vous avez besoin de toute la capacité du serveur, vous utilisez un ordinateur à 1 000 $ pour 1 400 $
- Avec un engagement d’un an, il est aussi possible d’obtenir une remise à 1 250 $ par mois (c’est fondamentalement un contrat de crédit à 25 % d’intérêt annuel)
- Le serverless suit la même logique, mais permet de découper le serveur de manière bien plus fine
- Au lieu de proposer un gros serveur à 7 personnes pour 200 $ par mois, on le fournit à 100 clients qui exécutent chacun des fonctions pour 20 $ par mois
- On ne réalise alors plus 400 $ de profit mensuel, mais 1 000 $
- Rien d’étonnant à ce que les fournisseurs cloud adorent le serverless
- C’est bien si vous n’avez besoin que de quelques fonctions exécutées de temps à autre (au moins à court terme)
- Mais si vous devez utiliser toutes les capacités d’un ordinateur, c’est terrible
- Car vous payez plus cher pour une même fréquence d’horloge, avec en plus un lock-in énorme
- Plus vous utilisez de services « cloud native » dans le serverless, plus il devient difficile d’en sortir
-
« Ne vous laissez pas berner par le serverless. Si vous avez besoin de tous les cycles de calcul d’un ordinateur, il n’existe pas de magie qui change le fait que vous devez acheter cet ordinateur. Si vous commencez avec une configuration serverless propriétaire, vous découvrirez que vous ne pouvez pas échapper au lock-in. »
-
« Le cloud est fait pour des entreprises dont l’usage varie fortement, comme Amazon qui connaît une demande énorme à Black Friday et à Noël, et se retrouve avec beaucoup de capacité inutile le reste du temps, ou pour des entreprises qui n’ont pas un business justifiant de posséder un ordinateur entier, ou encore pour des jeunes sociétés dont les dépenses cloud sont si faibles que cela ne pose pas problème. Le serverless ne change rien à cela. »
8 commentaires
Il y a aussi la différence entre un service qui a des pics de charge et un service qui n’en a pas. Dans le cas d’une application de livraison, il y a clairement des créneaux où l’affluence se concentre, donc un cloud capable de ne faire du scale-out qu’à ces moments-là est séduisant. En revanche, du côté de l’IoT, où 99 % du trafic est constant, il peut être préférable de faire tourner des serveurs physiques.
Au-delà de l’utilité réelle du serverless, il y a aussi un aspect largement trop porté par le hype, donc je pense que cela apporte un point de vue qui mérite réflexion.
Si l’on réfléchit et décide en tenant compte de ces deux enjeux, il me semble qu’il y a peu de chances de se tromper lourdement.
Personnellement, je me demande si le serverless est la bonne abstraction ; je pense que le temps le démontrera. En revanche, la question du lock-in du serverless continuera à être épineuse, et j’ai l’impression que c’est un problème difficile à résoudre à l’échelle de l’ensemble du secteur.
Même si les startups manquent d’argent, elles manquent encore davantage de personnes et de temps, donc je pense que le serverless est une option extrêmement séduisante pour elles.
Au final, comme il s’agit d’un domaine où un choix rationnel entre l’offre et la demande est possible, je n’ai pas l’impression qu’on se fasse tromper ou qu’on trompe qui que ce soit.
Sur le marché, selon la taille de l’entreprise, la nature de l’activité et le type de service, il existe forcément des entreprises et des personnes qui ont besoin, de manière appropriée, du cloud, de l’on-premise ou du serverless.
Décider s’il est pertinent de payer 200 dollars pour un serveur ou 20 dollars pour utiliser une function relève au final d’une réflexion que le CEO/CTO de chaque entreprise peut mener pour prendre une décision rationnelle. Si les coûts immédiats et le calendrier sont contraignants, 20 dollars peut être préférable ; s’il y a un peu plus de marge, une option à 200 ou 1 000 dollars peut constituer une décision rationnelle. Du point de vue de la demande, avoir davantage d’options pour répondre à des situations variées est plutôt une bonne chose. En plus, ce n’est pas une technologie monopolistique, et comme c’est un marché où les grands groupes se livrent une concurrence acharnée, les prix continuent naturellement de baisser.
Il semble que la limite, c’est AWS Fargate ou GCP Cloud Run sans ingénieur infra dédié (DevOps, SRE, platform engineer ou autre). Container as a Service.
Bien sûr, même là, il y a divers avantages et inconvénients...
À ce sujet, il existe aussi un article qui critique le fait qu’AWS encaisse autant d’argent avec Lambda sans pour autant améliorer réellement le runtime.
https://www.lastweekinaws.com/blog/aws-is-asleep-at-the-lambda-wheel/
Je suis d'accord.
Quand on regarde le cycle de mise à niveau de la plateforme de Lambda ou d'autres services AWS, je n'ai pas l'impression qu'ils soient particulièrement agiles ; cela donne plutôt l'impression qu'ils sont très conservateurs ou qu'ils n'y consacrent pas énormément de ressources. J'imagine que c'est sans doute parce que l'ajout d'une nouvelle version de plateforme nécessite beaucoup de tests et que cela augmente aussi fortement les coûts de support ; ils privilégient donc la stabilité et maintiennent le nombre de versions de plateforme dans une certaine limite... mais ce n'est qu'une supposition.
Comme toujours, DHH a tendance à s’exprimer de façon un peu provocatrice. Gardez-le à l’esprit en le lisant, haha.