Stateless vs Stateful : Pourquoi votre stratégie de déploiement en dépend

Vous avez deux instances de la même application en cours d'exécution. Un utilisateur envoie une requête. Quelle instance la traite ? Si la réponse est "n'importe laquelle, peu importe", vous avez affaire à une application stateless. Si la réponse est "ce doit être la même qui a traité sa requête précédente", vous êtes face à une application stateful.

Cette distinction n'est pas théorique. Elle détermine la facilité avec laquelle vous pouvez déployer une nouvelle version, monter en charge lors d'un pic de trafic, ou effectuer un rollback en cas de problème. De nombreuses équipes l'apprennent à leurs dépens : elles construisent un pipeline de déploiement qui fonctionne parfaitement pour un service, puis tentent d'appliquer la même approche à un autre service et se heurtent à des échecs inattendus.

Qu'est-ce qui rend une application Stateless ?

Une application stateless ne conserve aucune information entre les requêtes. Chaque requête est indépendante. L'application reçoit une entrée, la traite, retourne un résultat, et oublie tout de cette interaction.

Pensez à un point d'accès API qui prend un ID de produit et retourne les détails du produit depuis une base de données. Chaque appel est autonome. L'application ne se soucie pas de savoir qui l'a appelée, ce qu'ils ont appelé avant, ou ce qui se passe après. Si vous exécutez trois instances de cette API derrière un répartiteur de charge, n'importe quelle instance peut traiter n'importe quelle requête. Elles sont interchangeables.

Les exemples courants d'applications stateless incluent :

Le diagramme suivant compare les chemins de déploiement pour les applications stateless et stateful.

flowchart TD A[Début du déploiement] --> B{Type d'application ?} B -->|Stateless| C[Lancer de nouvelles instances avec la nouvelle version] C --> D[Basculer progressivement le trafic vers les nouvelles instances] D --> E[Les anciennes instances sont vidées et supprimées] E --> F[Rollback ? Il suffit de rebasculer le trafic] B -->|Stateful| G[Planifier la migration des données et la gestion des sessions] G --> H[Lancer de nouvelles instances avec un ensemble stateful] H --> I[Migrer soigneusement les données ou utiliser des sessions persistantes] I --> J[Surveiller la corruption des données ou la perte de session] J --> K[Le rollback nécessite une compatibilité de format de données]
  • API REST qui lisent et écrivent dans une base de données partagée
  • Services de traitement d'images qui transforment des fichiers et retournent des résultats
  • Services d'authentification qui valident des jetons sans stocker de données de session
  • Pages web rendues par le serveur qui stockent tout l'état dans des cookies ou des paramètres d'URL

Les applications stateless sont les plus faciles à déployer, à mettre à l'échelle et à restaurer. Vous pouvez exécuter plusieurs versions côte à côte, basculer le trafic progressivement et revenir en arrière instantanément si quelque chose se casse.

Qu'est-ce qui rend une application Stateful ?

Une application stateful doit se souvenir de quelque chose entre les requêtes. Ce quelque chose s'appelle l'état. Il peut s'agir d'un panier d'achat, d'une session de chat active, d'un téléchargement de fichier en cours, ou d'une session d'authentification utilisateur stockée dans la mémoire du serveur.

Prenons l'exemple d'une application e-commerce. Un utilisateur ajoute des articles à son panier. Les données du panier résident sur le serveur qui a traité cette requête. Si la requête suivante va vers un serveur différent, ce serveur ne connaît pas le panier. L'utilisateur voit un panier vide. C'est un problème stateful.

Les applications stateful stockent l'état à plusieurs endroits :

  • En mémoire sur le serveur d'application (données de session)
  • Dans des fichiers locaux sur le serveur (fichiers téléchargés, données temporaires)
  • Dans des bases de données embarquées exécutées parallèlement à l'application
  • Dans des caches au niveau de l'application qui ne sont pas partagés entre les instances

Le défi n'est pas que l'état existe. Le défi est de savoir où il vit. Si l'état est lié à une instance spécifique, vous ne pouvez pas router librement le trafic, remplacer des instances ou réduire la capacité sans perdre de données.

Comment les applications Stateless simplifient le déploiement

Déployer une application stateless est simple. Vous démarrez de nouvelles instances avec la nouvelle version à côté des anciennes. Le répartiteur de charge dirige progressivement le trafic vers les nouvelles instances. Une fois que tout le trafic est sur la nouvelle version, vous arrêtez les anciennes instances.

Si la nouvelle version a un bug, vous inversez le processus. Redirigez le trafic vers les anciennes instances. Pas de migration de données, pas de changement de schéma, pas de récupération de session. Le rollback n'est qu'un réacheminement de trafic.

La mise à l'échelle suit la même logique. Besoin de plus de capacité ? Démarrez plus d'instances. Le trafic a baissé ? Supprimez des instances. Il n'y a pas de données à redistribuer. Chaque instance est identique et jetable.

C'est cette simplicité qui explique pourquoi les architectures microservices privilégient les conceptions stateless. Chaque service peut être déployé indépendamment sans se soucier de ce que les autres instances mémorisent.

Pourquoi les applications Stateful nécessitent plus de précautions

Déployer une application stateful implique de gérer des données qui ne peuvent pas être perdues ou corrompues. Si l'application stocke les sessions en mémoire, remplacer toutes les instances à la fois déconnecte tous les utilisateurs actifs. Si l'application écrit dans des fichiers locaux, ces fichiers doivent être migrés ou la nouvelle version doit être compatible avec l'ancien format de données.

Les stratégies courantes pour déployer des applications stateful incluent :

Déplacer l'état en dehors de l'application. Stockez les sessions dans un cluster Redis partagé ou une base de données. Stockez les fichiers téléchargés dans un stockage d'objets comme S3. Cela transforme l'application en une application stateless du point de vue du déploiement. L'application peut être remplacée librement car l'état vit ailleurs.

Utiliser des sessions persistantes (sticky sessions). Configurez le répartiteur de charge pour envoyer le même utilisateur vers la même instance. Cela fonctionne mais crée des problèmes lors des déploiements. Vous ne pouvez pas vider le trafic d'une instance sans perturber les utilisateurs actifs. Les mises à jour progressives deviennent plus lentes car vous devez attendre l'expiration des sessions.

Utiliser des StatefulSets ou des opérateurs. Les StatefulSets Kubernetes et les opérateurs de bases de données gèrent la complexité du déploiement d'applications stateful. Ils garantissent que les instances sont démarrées et arrêtées dans l'ordre, que les données sont préservées et que les identités réseau sont stables. Mais ils nécessitent de comprendre comment votre application stateful spécifique se comporte.

Planifier la migration des données. Si la nouvelle version modifie la façon dont les données sont stockées, le déploiement doit inclure une étape de migration. Le rollback devient risqué car l'ancienne version peut ne pas comprendre le nouveau format de données. C'est courant avec les changements de schéma de base de données.

L'impact réel sur votre équipe

La distinction entre stateless et stateful affecte plus que les décisions techniques. Elle façonne la façon dont votre équipe fonctionne.

Les applications stateless permettent des déploiements rapides et fréquents. N'importe quel membre de l'équipe peut déployer une nouvelle version sans craindre une perte de données. Les rollbacks sont sûrs et rapides. Cela réduit la peur du déploiement et encourage des versions plus petites et plus fréquentes.

Les applications stateful nécessitent une coordination minutieuse. Les déploiements doivent être planifiés en fonction de la migration des données, de la gestion des sessions et de la compatibilité des rollbacks. Les équipes développent souvent des procédures spéciales pour les services stateful : fenêtres de déploiement, étapes d'approbation, étapes de vérification manuelle. Cela ralentit la livraison.

Si votre organisation possède les deux types d'applications, ne vous attendez pas à ce qu'un seul processus de déploiement fonctionne pour tout. Le pipeline d'une API stateless ne conviendra pas à une migration de base de données ou à un service stateful qui gère les sessions utilisateur.

Une checklist rapide pour votre prochain déploiement

Avant de planifier un déploiement, posez-vous ces questions :

  • L'application stocke-t-elle des données localement qui doivent survivre à un redémarrage ?
  • Les sessions utilisateur sont-elles stockées en mémoire ou dans un stockage externe partagé ?
  • N'importe quelle instance peut-elle traiter n'importe quelle requête, ou le routage dépend-il de l'instance qui possède les données ?
  • Si vous revenez à la version précédente, le format des données sera-t-il toujours lisible ?
  • Pouvez-vous exécuter deux versions côte à côte sans conflits de données ?

Si vous avez répondu "non" à toutes les questions concernant le stockage local et la dépendance aux sessions, vous avez une application stateless. Déployez librement. Si vous avez répondu "oui" à l'une d'elles, vous devez planifier la gestion de l'état avant de concevoir votre stratégie de déploiement.

Ce qu'il faut retenir

Les applications stateless vous donnent de la liberté. Les applications stateful vous imposent des contraintes. L'erreur est de les traiter de la même manière. Avant de concevoir un pipeline de déploiement, comprenez où vivent vos données. Si elles vivent à l'intérieur de l'instance d'application, votre stratégie de déploiement doit en tenir compte. Si elles vivent à l'extérieur, vous pouvez traiter l'application comme jetable et déployer en toute confiance.