Sans serveur pour les applications : qu'est-ce que c'est et pourquoi c'est important

Peu de termes technologiques génèrent autant de confusion que « serverless ». Le nom suggère qu’il n’y a pas de serveurs, ce qui est tout simplement faux. Il existe des serveurs, bien sûr, mais vous n'en êtes plus responsable. Et c’est dans ce changement de responsabilité que toute l’idée vit.

Pour ceux qui dirigent la technologie ou les produits, comprendre serverless n’est pas un caprice technique. Il s'agit de comprendre l'un des changements les plus profonds dans la manière dont les logiciels sont construits et exploités. Un changement qui a des conséquences directes sur les coûts, la rapidité et la concentration des équipes.

Ce texte est une introduction honnête. Je ne vais pas vendre serverless comme une solution à tout, car ce n'est pas le cas. Je vais vous expliquer de quoi il s'agit, pourquoi il est apparu et quand cela a du sens, afin que vous puissiez décider clairement, et non avec des modes.

Ce que signifie réellement le sans serveur

Pendant des décennies, exécuter une application nécessitait de prendre soin des serveurs. Acheter ou louer des machines, installer des systèmes, appliquer des mises à jour, s'assurer que tout reste debout. Même dans le cloud, il fallait encore quelqu'un pour faire évoluer et gérer ces machines.

Le sans serveur inverse cette logique. Vous écrivez votre code, définissez quand il doit s'exécuter et le fournisseur de cloud s'occupe de tout le reste, de son provisionnement, de sa mise à l'échelle et de son maintien en ligne. Vous ne pensez plus aux serveurs. Pensez simplement à la fonction qui doit être exécutée.

C'est comme passer de la possession d'une voiture à l'utilisation du transport à la demande. Vous ne vous occupez pas de l'entretien, de l'assurance ou du stationnement. Commandez quand vous en avez besoin, payez ce que vous utilisez et continuez.

Pourquoi cela est-il apparu maintenant

Le sans serveur n’est pas né par hasard. C'est la réponse à une vieille frustration : les équipes technologiques passaient trop de temps à entretenir l'infrastructure et pas assez de temps à résoudre les problèmes commerciaux.

Chaque heure passée à configurer un serveur est une heure non consacrée au produit. Pour la plupart des organisations, la gestion des serveurs n’a jamais été une source de valeur, mais plutôt un coût nécessaire. Le sans serveur promet d’éliminer une grande partie de ce coût.

Ajoutez à cela l’évolution du cloud computing et la pression d’une livraison plus rapide, et les bases étaient prêtes. Le sans serveur est, essentiellement, la tentative de ramener les équipes à se concentrer sur ce qui compte vraiment.

La thèse : le sans serveur est une décision cruciale

Ma position est que sans serveur n'est pas principalement une décision technique. Il s'agit de décider sur quoi votre équipe porte son attention.

En adoptant serverless, vous dites que s'occuper des serveurs n'est pas là où vous souhaitez investir le talent de l'équipe. Vous externalisez une complexité qui ne différencie pas votre produit, pour concentrer votre énergie sur ce qui le différencie.

Ceci est particulièrement puissant pour les organisations disposant d’équipes réduites. Ceux qui ne disposent pas d’une grande équipe d’infrastructure accèdent à une robustesse opérationnelle dont disposaient auparavant seules les grandes entreprises. C'est la démocratisation de la capacité technique.

Mais comme toute décision, elle comporte des compromis. Et c’est en les ignorant que les gens sont blessés.

Les avantages qui rendent le serverless attractif

Le premier est le modèle de coût. Dans serverless, vous payez généralement pour ce que vous utilisez réellement, et non pour la capacité inutilisée. Pour les charges de travail intermittentes ou imprévisibles, cela peut signifier de réelles économies et aucune dépense lorsque personne ne l'utilise.

La seconde est la mise à l’échelle automatique. Lorsque la demande augmente, la plateforme évolue d’elle-même. Quand il tombe, il recule. Vous n'avez pas besoin de prévoir les pics ou de maintenir les machines à l'arrêt en attendant l'arrivée du mouvement.

Le troisième est la vitesse du développement. Sans les frais généraux liés à la gestion de l’infrastructure, les équipes peuvent passer plus rapidement du code à la production. Pour ceux qui ont besoin de valider des idées et d’itérer, c’est du carburant.

Les limites à connaître

Le sans serveur n’est pas magique, et le traiter comme tel est une source de frustration.

Il existe un phénomène de « démarrage à froid » : les fonctions qui ont été inactives peuvent mettre un moment supplémentaire à répondre au premier appel. Pour certaines applications, cela n'a pas d'importance ; pour d’autres, sensibles à la latence, c’est important.

Il y a aussi la question de la dépendance envers le fournisseur. Les architectures sans serveur ont tendance à être couplées aux services spécifiques de chaque cloud, ce qui peut rendre une éventuelle migration difficile. Cette liaison doit être un choix conscient et non une surprise.

Et il y a le défi de penser différemment. Le sans serveur nécessite un nouveau modèle mental, basé sur des événements et de petites fonctions. Les équipes habituées aux applications traditionnelles ont besoin de temps pour s’adapter, et cela a un coût.

Quand le sans serveur a du sens

Le sans serveur brille dans des scénarios spécifiques. Charges de travail à demande variable, traitements événementiels, automatisations, API avec trafic irrégulier, nouveaux projets qui doivent démarrer rapidement.

Pensez à un système de notification d'application, qui déclenche des messages à des moments imprévisibles. Ou dans le traitement qui se produit lorsqu'un fichier est envoyé. Ou dans une startup validant un produit sans vouloir mettre en place une infrastructure. Il s’agit de cas où le paiement de l’utilisation et la mise à l’échelle s’accordent comme un gant.

En revanche, les applications avec une charge constante et prévisible, ou avec des exigences de latence strictes, peuvent bénéficier davantage des approches traditionnelles. Il n’y a pas de réponse unique. Il y a une adaptation au contexte.

Focus est le vrai produit

En fin de compte, serverless est un outil au service d'une idée plus large : votre équipe doit consacrer du temps à ce qui distingue votre produit, et non à ce qui le maintient à flot.

Comprendre serverless, c'est comprendre ce compromis. Vous abandonnez un certain contrôle et gagnez en concentration, en rapidité et en simplicité opérationnelle. Pour de nombreuses organisations, c'est une bonne affaire. Pour d’autres, pas tellement. L’important est de décider en sachant quels sont les enjeux.

Une bonne technologie est une technologie qui disparaît, laissant l’équipe libre de réfléchir au bon problème. Le sans serveur, lorsqu'il est appliqué correctement, fait exactement cela.

Si vous évaluez si sans serveur a du sens pour votre produit, cela vaut la peine d'en discuter avant de prendre une décision. J'ai d'autres articles sur le blog qui explorent le sans serveur avec des exemples, dans la pratique et dans la vie quotidienne, pour approfondir à mesure que vous avancez dans cette décision.