serverless · cloud · architecture
Le serverless, c'est quoi exactement ?
Le mot est un terme marketing qui est resté, et il induit presque tout le monde en erreur la première fois. Serverless ne veut pas dire qu'il n'y a pas de serveur. Cela veut dire que vous n'en voyez jamais un : vous ne choisissez pas sa taille, vous n'installez pas ses mises à jour, vous ne décidez pas combien en faire tourner. Quelqu'un d'autre s'en charge, et on vous facture ce que votre code a réellement fait.
Ce que cela retire vraiment
Sur un VPS, vous louez une machine. Elle existe que quelqu'un vienne ou non, vous choisissez sa RAM et ses vCPU, vous patchez son noyau, et vous décidez quand en ajouter une seconde. Chacune de ces décisions est la vôtre, et chaque heure de facture aussi.
Le serverless retire la machine en tant qu'unité de raisonnement. Vous confiez à la plateforme un morceau de code et un déclencheur : une requête HTTP, un message dans une file, un fichier déposé dans un stockage. La plateforme fait en sorte que ce code s'exécute quand le déclencheur se produit. Combien de copies tournent, et sur quoi, n'est ni votre problème ni votre décision.
Voilà tout l'échange, dit simplement : vous renoncez au contrôle du runtime en échange de ne jamais l'exploiter.
Les deux familles
Le Function as a Service est la partie à laquelle on pense d'abord. Vous déployez une fonction, la plateforme l'exécute par événement, et elle disparaît. AWS Lambda, Google Cloud Functions et Azure Functions en sont les exemples familiers.
Les services managés serverless sont la moitié la plus vaste et la moins commentée : bases de données, files d'attente, stockage objet et recherche, facturés à la requête ou à l'unité de travail plutôt qu'à l'instance provisionnée. La plupart des vrais systèmes serverless sont surtout faits de cela, avec une modeste quantité de code de fonction pour tenir l'ensemble.
La facturation, et pourquoi le scale to zero est l'argument phare
Une machine louée se facture au temps qui passe. Elle coûte autant à trois heures du matin sans visiteur qu'au pic de trafic. Le serverless facture à l'invocation, plus les ressources consommées par cette invocation pendant qu'elle tournait.
La conséquence est le scale to zero : sans trafic, rien ne tourne et il n'y a rien à payer. Pour un projet personnel, un outil interne utilisé deux fois par semaine, ou une charge en pics qui reste inactive la plupart du temps, c'est l'avantage réel, et il est important.
Le même mécanisme joue dans l'autre sens sous charge. La plateforme démarre autant de copies concurrentes que les événements l'exigent, sans que vous configuriez d'autoscaler, et c'est le second avantage réel.
Les contraintes que l'argumentaire omet
Les démarrages à froid. Quand aucune copie de votre fonction n'est chaude, la première requête paie l'initialisation du runtime et de vos dépendances avant que votre code ne commence. Des bundles plus petits et des runtimes plus légers réduisent ce coût. Les fournisseurs vendent de la capacité préchauffée, qui fonctionne et qui annule discrètement le scale to zero, puisque préchauffé signifie payé pendant l'inactivité.
L'absence d'état. Rien de ce que vous gardez en mémoire ou sur le disque local n'est garanti présent la fois suivante. Deux invocations peuvent atterrir sur des instances différentes, et une instance disparaît quand la plateforme le décide. L'état va dans une base ou un stockage objet, toujours.
Les limites d'exécution. Une invocation a une durée maximale et un plafond de mémoire. Les traitements par lots longs et tout ce qui garde une connexion ouverte des heures s'y prêtent mal, et atteindre la limite n'est pas un avertissement mais un échec.
Le couplage. Le corps de la fonction est en général portable. Les formes d'événements, le modèle d'identité et les services managés qui l'entourent ne le sont pas, et c'est là que partir plus tard coûte vraiment.
Où la courbe de coût se croise
La facturation à l'invocation est bon marché quand la machine serait restée inactive, et chère quand elle aurait été occupée. En dessous d'une certaine charge stable, le serverless gagne facilement. Au-dessus, vous payez une prime par unité de travail pour une élasticité que vous n'utilisez plus, et un serveur allumé en permanence, même modeste, revient moins cher et plus prévisible.
La règle honnête est de regarder la forme du trafic plutôt que son volume. En pics, occasionnel et imprévisible : avantage serverless. Stable et continu : avantage machine louée au mois, et à ce moment-là le travail d'exploitation que vous reprenez est un prix correct pour une facture qui cesse de surprendre.
Si votre charge se révèle du côté stable, un VPS est la réponse simple, et Docker plus un peu de discipline vous rend l'essentiel de la reproductibilité qui rendait le serverless attirant au départ.
Un serveur pour le côté stable de la courbe
Quand le trafic cesse d’être en pics, la facturation à l’invocation coûte plus cher qu’une machine qui allait de toute façon être occupée. DigitalOcean propose des VPS et serveurs cloud avec contrôle root complet, facturés au mois plutôt qu’à l’appel.
Voir DigitalOcean Cloud →Lien affilié - il soutient ces guides gratuits.
En bref
Serverless signifie que les serveurs sont le problème de quelqu'un d'autre, pas qu'ils sont absents. Vous gagnez le scale to zero, la concurrence automatique et zéro patch. Vous acceptez les démarrages à froid, l'absence d'état, les limites d'exécution et une facture qui suit l'usage plutôt que le temps. Cela convient au travail en pics et intermittent, et cesse de convenir quand le trafic devient assez stable pour qu'une machine louée ait de toute façon été occupée.