Serverless pour les applications : architecture avec exemples réels

Le sans serveur est facile à expliquer dans l’abstrait et difficile à visualiser dans la pratique. La plupart des introductions parlent de fonctions, d'événements et d'évolutivité automatique, qui sont des concepts corrects, mais ils n'aident pas ceux qui doivent décider si cela convient au problème en question.

La meilleure façon de comprendre le serverless est de voir où il brille vraiment. Quels problèmes concrets résout-il mieux que les alternatives ? Quels modèles se répètent dans les architectures qui fonctionnent.

Ce texte échange la théorie contre des exemples. Examinons les architectures réelles, celles qui apparaissent chaque jour dans les produits numériques, et comprenons pourquoi sans serveur a du sens dans chacune d'entre elles. Non pas pour vendre la technologie, mais pour vous permettre de savoir quand c'est le bon choix.

Le modèle derrière presque toutes les bonnes utilisations du sans serveur

Avant les exemples, il convient de noter une chose. Les meilleures applications sans serveur partagent une caractéristique : ce sont des tâches qui se produisent en réponse à un événement et qui n'ont pas besoin d'être exécutées en permanence.

Quelque chose se produit, un fichier arrive, un utilisateur clique, une heure est atteinte, un message est reçu et une fonction se réveille, fait son travail et se rendort à nouveau. Vous ne payez que pour le moment de l'exécution. Il n’y a pas de machine qui attend.

Lorsque vous internalisez ce modèle, vous commencez à voir des opportunités sans serveur partout. Et il commence aussi à reconnaître les domaines où il n'a pas sa place.

Exemple 1 : Traitement du téléchargement

Imaginez un produit où les utilisateurs envoient des images, des documents, des photos de profil, des reçus. Chaque téléchargement doit être traité : redimensionné, validé, voire analysé.

Dans une architecture traditionnelle, vous maintiendriez des serveurs prêts pour ce traitement, inactifs la plupart du temps et surchargés pendant les pics de traitement. Dans serverless, le flux est différent. Le fichier arrive en stockage, cet événement déclenche une fonction, la fonction traite l'image et se termine.

Si mille téléchargements simultanés arrivent, la plateforme exécute mille exécutions en parallèle. Si aucun n’arrive, vous ne payez rien. L'adéquation est parfaite car le travail est basé sur des événements et intermittent, exactement le terrain où serverless gagne.

Exemple 2 : API avec un trafic irrégulier

Pensez à une API backend pour une application dont les heures de pointe sont bien définies. Une application de transport utilisée matin et soir. Un système de prise de rendez-vous avec des rafales en début de mois.

Maintenir des serveurs dimensionnés pour les périodes de pointe signifie payer pour la capacité inutilisée dans les vallées. Dimensionner pour la vallée signifie ne pas gérer le sommet. C'est un dilemme classique.

Une API sans serveurrésout ce problème avec élégance. Chaque requête déclenche une exécution et la plateforme évolue en fonction du trafic. Au sommet, échelle ; dans la vallée, collectez. Vous suivez la courbe d’utilisation réelle au lieu de prévoir le pire des cas. Pour le trafic irrégulier, il s’agit de l’un des cas d’utilisation les plus rentables.

Exemple 3 : automatisations et tâches planifiées

De nombreuses organisations vivent de petites automatisations. Générez un rapport chaque matin. Envoyez des rappels à des heures précises. Synchronisez périodiquement les données entre les systèmes. Effacez les anciens enregistrements.

Traditionnellement, ces tâches nécessitaient un serveur fonctionnant en permanence, juste quelques minutes par jour. Un gaspillage. Dans serverless, vous définissez le déclencheur, une heure par exemple, et la fonction ne s'exécute qu'à ce moment-là.

Pour une administration municipale, cela pourrait impliquer de consolider les données de service chaque nuit ou de déclencher des notifications d'impôts dus sans maintenir une infrastructure dédiée. Des tâches administratives qui s'exécutent seules et ne coûtent que les secondes qu'elles prennent.

Exemple 4 : Architecture multiservice basée sur les événements

L’exemple le plus sophistiqué est aussi le plus puissant. Les applications modernes sont souvent constituées de plusieurs parties qui doivent réagir les unes aux autres.

Une commande est passée. Cela nécessite de mettre à jour l'inventaire, d'informer le client, d'enregistrer la transaction et peut-être de déclencher la logistique. Au lieu d’un système monolithique faisant tout de manière couplée, chacune de ces réactions peut être une fonction indépendante, déclenchée par l’événement « commande passée ».

Cette architecture événementielle est naturellement serverless. Chaque pièce est petite, indépendante et évolue d’elle-même. Si un composant tombe en panne, les autres continuent. La flexibilité est énorme, même si, comme nous le verrons, elle apporte sa propre complexité.

La thèse : le sans serveur est une question d'adéquation, pas de supériorité

Ce que révèlent ces exemples, c’est ma position centrale. Le sans serveur n'est ni meilleur ni pire que les architectures traditionnelles. C'est différent et sa valeur dépend entièrement de son adéquation au problème.

Lorsque le travail est basé sur des événements, intermittent et variable, sans serveur est souvent un excellent choix. Lorsque le travail est constant, prévisible et sensible à la latence, d’autres approches peuvent s’avérer plus efficaces.

La maturité technique ne consiste pas à adopter le serverless pour la mode, mais à reconnaître la forme du problème et à choisir l'outil qui convient. Les exemples ci-dessus partagent une signature commune, et c'est cette signature que vous devez apprendre à identifier.

Erreurs qui apparaissent dans la pratique

La première erreur est de forcer serverless là où cela ne convient pas. Les applications avec un traitement long et continu, ou qui dépendent d'une latence faible et constante, souffrent des limites de l'approche. Le montage forcé génère de la frustration et des coûts.

La seconde est de sous-estimer la complexité distribuée. Les architectures événementielles, comportant des dizaines de fonctions, peuvent devenir un enchevêtrement difficile à comprendre et à déboguer. Plus de flexibilité signifie plus de pièces communiquant entre elles, ce qui nécessite une discipline de conception.

La troisième consiste à ignorer les coûts à une échelle extrême. Pour des volumes très élevés et constants, le modèle de paiement à l’exécution peut s’avérer plus cher que les machines dédiées. Cela vaut la peine de faire le calcul, sans présumer des économies.

Ce qui compte, c'est de reconnaître le modèle

Après ces exemples, la leçon pratique est simple. Apprenez à reconnaître le format de problème que serverless résout bien : événements, intermittence, variabilité, indépendance entre les parties.

Lorsque vous voyez ce schéma, la décision devient naturelle. Et lorsque vous ne le voyez pas, vous vous évitez d’avoir à adopter une architecture qui ne correspond pas à ce que vous devez faire.

Une bonne architecture ne consiste pas à choisir la technologie la plus récente. C'est choisir celui qui correspond au problème comme une pièce qui a toujours manqué.

Si vous concevez une architecture et souhaitez discuter de la place réelle de serverless dans votre cas, cela vaut la peine d'en parler. J'ai d'autres articles sur le blog sur le sans serveur dans la pratique et dans la vie de tous les jours, avec un focus sur l'exécution et le fonctionnement, pour ceux qui ont déjà décidé de suivre cette voie.