Le sans serveur pour les applications : l'architecture en pratique

Comprendre serverless est une chose. Bien le mettre en œuvre en est une autre. De nombreuses personnes qui ont adopté le concept ont découvert, chemin faisant, que la facilité promise s’accompagnait de décisions difficiles dont personne n’avait parlé.

La distance entre le sans serveur des diapositives et le sans serveur du code de production est le point où les équipes sont blessées. Non pas parce que la technologie est mauvaise, mais parce qu’elle nécessite une façon de penser que peu de gens développent avant d’être déjà en difficulté.

Ce texte s'adresse à ceux qui ont décidé de construire avec serverless et qui veulent le faire correctement. Parlons des véritables décisions de conception, des pièges qui apparaissent lors de la mise en œuvre et de la discipline qui sépare une architecture solide d'un fouillis de fonctions difficiles à maintenir.

La facilité trompeuse du début

Le sans serveur a un début séduisant. En quelques minutes, vous téléchargez votre première fonction, elle répond et il semble que tout sera aussi simple. C'est là que réside le piège.

Le problème n'est pas d'écrire une fonction. C'est écrire une cinquantaine de fonctions qui communiquent entre elles, partagent une logique, dépendent de données et doivent être comprises par une équipe six mois plus tard. La complexité ne disparaît pas avec serverless. Il change de lieu, quitte l'infrastructure et se dirige vers l'architecture.

Ceux qui ne s’en rendent pas compte construisent ce qu’on appelle un « monolithe distribué » : tous les inconvénients d’un système distribué, sans aucun des avantages d’une conception réfléchie. C’est le pire des mondes, et c’est plus courant qu’on ne le pense.

La thèse : le sans serveur nécessite plus de conception, pas moins

Voici ma position centrale. Le sans serveur ne dispense pas de l'architecture, il en exige davantage.

Lorsque vous gérez des serveurs, une partie de la discipline est imposée par l'infrastructure. Vous êtes obligé de réfléchir à la façon dont les pièces sont organisées. Le sans serveur supprime cette imposition et rend une liberté totale. Et la liberté sans discipline devient le chaos.

Par conséquent, bien mettre en œuvre serverless est un exercice de conception consciente. Vous devez décider délibérément comment répartir les responsabilités, comment les fonctions communiquent, où réside l’État et comment tout cela reste compréhensible. Ceux qui considèrent le sans serveur comme un « code sans serveur rapide » accumulent des dettes techniques à une vitesse record.

Concevoir des décisions qui définissent le résultat

Granularité : quelle doit être la taille de chaque fonction

La première décision difficile est la taille. Des fonctions trop petites multiplient la complexité de la communication. Les fonctions trop volumineuses perdent les avantages de la modularité et de l’évolutivité indépendante.

Une bonne règle de base consiste à organiser les rôles autour de responsabilités commerciales claires, et non d’opérations triviales. Chaque fonction doit faire quelque chose de cohérent et compréhensible. Résistez à la tentation de tout fragmenter en micro-morceaux, la séduction de « l’extrêmement granulaire » aboutit généralement à l’ingouvernabilité.

État : où se trouvent réellement les données

Les fonctions sans serveur sont, par nature, sans état. Ils naissent, ils exécutent et ils meurent. Cela signifie que tous les États doivent vivre en dehors d’eux, dans des bases de données, des caches et des magasins.

C’est l’un des plus grands changements de mentalité. Vous ne pouvez rien garder en mémoire entre les exécutions. Toute persistance est explicite et externe. Bien concevoir cela, choisir les bons magasins pour chaque type de données, est ce qui différencie une application fiable d’une application pleine de comportements imprévisibles.

Communication : comment les pièces communiquent entre elles

Dans une véritable architecture sans serveur, les fonctions doivent interagir. Le choix de la manière dont ils communiquent, de manière synchrone, en attendant une réponse, ou de manière asynchrone, via des événements et des files d'attente, façonne toute la robustesse du système.

La communication asynchrone, via des événements, tend à apporter plus de résilience : si une pièce tombe en panne, le message attend. Mais cela ajoute de la complexité au suivi. La communication synchrone est plus simple à comprendre, mais elle crée des couplages et propage les pannes. Ce choix n’est pas technique mineur, il est structurel.

Un exemple de mise en œuvre consciente

Imaginez créer le backend d'une application de livraison en utilisant serverless. Le déroulement d'une commande comporte plusieurs étapes : validation, chargement, notification au restaurant, suivi de la livraison.

L'implémentation naïve créerait une fonction géante essayant de tout orchestrer de manière synchrone. Résultat : lent, fragile et impossible à déboguer. Si la notification échoue, la requête entière se bloque.

Une mise en œuvre consciente sépare les responsabilités. Une fonction reçoit et valide la demande en l'enregistrant. Cela émet un événement qui déclenche indépendamment la facturation, la notification et le suivi. Chaque pièce tombe en panne et récupère d'elle-même. Le statut de la commande réside dans une base de données, accessible à tous.

La différence entre les deux ne réside pas dans la technologie. C'est le soin apporté au design avant d'écrire la première ligne.

Les pièges de la mise en œuvre

Le premier écueil est le débogage. Lorsqu’un problème survient dans un système réparti sur des dizaines de fonctions et d’événements, il est difficile d’en trouver la cause. Sans un suivi approprié dès le début, vous restez aveugle. Investir dans l’observabilité n’est pas une option, c’est une condition de survie.

La seconde est l’explosion de la configuration. Chaque fonction a ses permissions, ses variables, ses déclencheurs. À grande échelle, gérer cela manuellement devient une source d’erreurs. Traiter l’infrastructure comme du code, versionné et automatisé, n’est plus un raffinement mais devient une nécessité.

Le troisième est l’illusion de l’isolement. Les fonctions semblent indépendantes, mais partagent des banques, des files d'attente et des limites de fournisseur. Une fonction mal conduite peut affecter les autres. Penser à ces dépendances invisibles fait partie du travail.

La discipline est la véritable infrastructure

Ce que j'ai découvert, en pratique, c'est que sans serveur n'élimine pas le travail acharné, il le remplace. Vous arrêtez de vous occuper des machines et commencez à vous occuper de la conception, de la communication et de l’état. Pour ceux qui abordent cela avec discipline, le résultat est puissant : des systèmes flexibles, évolutifs et rentables.

Pour ceux qui le considèrent comme un raccourci, le résultat est un enchevêtrement que personne ne comprend et que personne ne veut entretenir. La technologie est la même. Ce qui change, c'est la rigueur de ceux qui l'exercent.

Le sans serveur n'est pas plus simple. C'est différent. Et la différence se fait avec le design, pas avec la précipitation.

Si vous implémentez une architecture serverless et souhaitez éviter les pièges classiques, cela vaut la peine de changer d'avis. J'ai d'autres articles sur le blog sur le concept du sans serveur, les cas d'utilisation et les opérations quotidiennes qui complètent cette vision de mise en œuvre.