Bonnes pratiques et avantages des applications Stateful et Stateless

Par Gursimran Singh|Insights|06,Oct,2020

Qu’est-ce que les applications Stateful et Stateless ?

Une application Stateful se souvient des détails spécifiques d’un utilisateur comme son profil, ses préférences et ses actions. Ces informations sont considérées comme le  » statut  » d’un système.
Par exemple, votre panier d’achat lors de l’utilisation de n’importe quel site web dans le Cloud. Chaque fois que vous sélectionnez un article et l’ajoutez dans votre panier, vous l’ajoutez avec les articles ajoutés précédemment et finalement, vous naviguez vers la page de paiement.

Une application ou un processus apatride est quelque chose qui ne sauvegarde pas ou ne référence pas les informations sur les opérations précédentes. Chaque fois, il effectue chaque opération à partir de zéro comme la première fois et fournit des fonctionnalités pour utiliser l’impression, le CDN (Content Delivery Network) ou les serveurs Web afin de traiter chaque demande à court terme.
Par exemple, quelqu’un cherche une question dans le moteur de recherche et a appuyé sur le bouton Entrée. Dans le cas où l’opération de recherche est interrompue ou fermée pour une raison quelconque, vous devez en commencer une nouvelle car il n’y a pas de données sauvegardées pour votre requête précédente.

Session statique vs session sans état

Les applications statiques et sans état stockent l’état des requêtes du client sur le serveur lui-même et utilisent cet état pour traiter d’autres requêtes. Elles utilisent DB pour stocker les données comme backend, mais les informations de session sont stockées sur le serveur lui-même. Lorsqu’un utilisateur envoie une demande de connexion, cela permet de vérifier que la connexion est vraie et que l’utilisateur est authentifié maintenant, et à la deuxième demande, l’utilisateur voit le tableau de bord. Les applications à états n’ont pas besoin d’appeler la base de données une deuxième fois, car les informations de session sont stockées sur le serveur lui-même. Comprendre le rôle des conteneurs dans DevOps est une meilleure façon de se familiariser avec les applications Microservices.

Il est donc plus rapide. Mais elle présente des inconvénients. Il y a un équilibreur de charge, et il y a deux serveurs derrière, qui exécutent la même application Stateful. La première demande de connexion va au serveur 1 et la deuxième demande pourrait aller au serveur 2 ; maintenant, puisque seul le serveur a activé la connexion pour être vrai, l’utilisateur ne sera pas capable de logique quand LB l’envoie au 2ème serveur. Il n’est donc pas possible de faire évoluer horizontalement les applications Stateful.

Stateless and Stateful Container Management

Bien que les applications Stateeless fonctionnent de différentes manières, elles ne stockent aucun état sur le serveur. Elles utilisent la base de données pour stocker toutes les informations. DB est stateful, c’est-à-dire qu’un stockage persistant lui est attaché.

Typiquement, un utilisateur demande une connexion avec des informations d’identification, l’un des serveurs derrière LB traite la demande, génère un jeton d’authentification, le stocke dans DB, et renvoie le jeton au client sur le front-end. La demande suivante est envoyée avec le jeton. Maintenant, quel que soit le serveur qui traite la demande, il fera correspondre le jeton avec les informations dans la base de données, et accordera la connexion à l’utilisateur. Chaque requête est indépendante et n’a pas de lien avec les requêtes précédentes ou suivantes, tout comme REST.

Bien que les apps apatrides aient un surcoût supplémentaire de l’appel à la BDD, ces apps sont étonnantes pour la mise à l’échelle horizontale, cruciale pour les apps modernes, qui pourraient avoir des millions d’utilisateurs.

Les applications modernes et les applications héritées ont une caractéristique commune, celle de stocker l’état ou non. Le fait de traiter avec des Monolithes ou des microservices dépend des besoins de l’application’ ; certaines ont besoin de stocker l’état tandis que d’autres n’ont pas besoin de se soucier de l’état.

Différence entre les applications Stateful vs Stateless

Les Stateful et Stateless sont omniprésents dans les ateliers informatiques. Mais les logiciels modernes étant architecturés à la manière Stateless puisque la mise à l’échelle est un facteur essentiel pour le monde d’aujourd’hui.

Les huit principales différences entre les applications Stateful et Stateless sont –

1. L’état de fonctionnement : Les applications Stateful réagissent par l’état actuel, tandis que les applications Stateless agissent indépendamment avec la prise en compte de la demande précédente/suivante.
2. Données stockées : Si le serveur web stocke des données de manière backend et les utilise pour identifier l’utilisateur comme un client toujours connecté, le service est Stateful. Alors que dans Stateless, le serveur stocke bien des données, mais dans une base de données pour vérifier l’utilisateur/client chaque fois qu’il doit se connecter.
3. Réaction envers les clients : Dans Stateful, le serveur pense qu’un client est juste une machine muette, alors que dans Stateless, le serveur pense que le client est une machine intelligente qui n’a pas besoin de dépendre d’un état quelconque du côté du serveur.
4. Demandes : Dans Stateless, les demandes sont autonomes, c’est-à-dire que tout est contenu dans la demande, et traitées en deux phases distinctes, une « demande » et une « réponse ». Alors que dans Stateful, les demandes dépendent toujours de l’état côté serveur.
5. État généré : Lors de la navigation sur internet, l’état généré et stocké quelque part. Bien que l’état généré dans les deux types lorsque l’état stocké sur le serveur, il génère une session. C’est ce qu’on appelle une application Stateful.
6. Etat stocké : Lorsque l’état stocké par le client, il génère certaines données utilisées pour d’autres demandes tout en étant techniquement « Stateful » car il fait référence à un état, mais l’état stocké par le client, donc l’appeler Stateless.
7. Cookie Stores : Du côté client, le cookie stocke les données d’authentification. Côté serveur, créer des données temporaires du client ou stocker sur une base de données(c’est le cas typique). En revenant sur le tableau de bord pour effectuer un autre paiement, c’est un cookie stocké dans le navigateur qui établit l’état avec le serveur.
8. Base d’utilisateurs : Stateful est passé quand il y avait des Monolithes et pas de base d’utilisateurs dynamique. Stateless est le futur, ayant des Microservices flottant autour et communiquant principalement par le biais d’interfaces REST et évoluant comme n’importe quoi puisqu’il n’y a pas d’état stocké.

Le passage aux microservices et aux conteneurs aide les entreprises qui cherchent à dépasser les technologies héritées, mais des défis subsistent.

Pourquoi les applications apatrides sont-elles importantes ?

• Pourquoi les applications apatrides sont-elles nécessaires alors que tout fonctionnait bien auparavant avec les applications Stateful ?

Les applications Stateful sont excellentes pour les cas d’utilisation minimaux, mais elle présente quelques problèmes. Tout d’abord, lorsque l’utilisateur fait référence à un état sur le serveur, il ouvre beaucoup de sessions incomplètes et des transactions se produisent.

• Dans un système Stateful, l’état calculé par le client, combien de temps le système doit-il laisser la connexion ouverte ?
• Comment vérifier côté serveur que le client s’est écrasé ou déconnecté de la session ?
• Comment les actions de l’utilisateur ont-elles été suivies tout en maintenant les modifications du document et en faisant des rollbacks ?
• La plupart des consommateurs/clients répondent au serveur de manière intelligente et dynamique, maintenant ainsi un état du serveur indépendant du client en supposant que le client est simplement un  » muet  » ; le client est gaspilleur.
• L’apatridie est un aspect fondamental des applications modernes – tous les jours ; il utilise une variété de services et d’applications sans état. Il utilise HTTP pour se connecter de manière apatride, en utilisant des messages qui sont rendus et qui travaillent dans l’isolement les uns des autres et de l’état du client.
• Facebook utilise continuellement un service apatride. Lorsque le serveur demande une liste de messages récents à l’aide de l’API Facebook, il émet une requête GET avec un jeton et une date. La réponse est indépendante de tout état du serveur, et tout est stocké sur la machine du client sous la forme d’un cache.
• De même, invoquer une commande POST, passer un corps complexe avec des données d’autorisation/authentification dans l’en-tête sans tenir compte de l’état du serveur.
• Il n’y a aucune relation avec la demande précédente, actuelle & suivante. Dans Stateless, le client n’attend pas la synchronisation du serveur. Il n’y a pas de concept d’achèvement de processus dans l’architecture serverless pour le Big Data. C’est donc plus rapide.

REST est une façon courante de concevoir, d’architecturer et de développer des API modernes & Representational State Transfer (REST) est sans état.

Comment fonctionne une application sans état?

L’architecture sans état signifie que l’application ne dépend que du stockage tiers car elle ne stocke aucune sorte d’état en mémoire ou sur son disque. Toutes les données dont elle a besoin ou qui lui sont nécessaires doivent être récupérées à partir d’un autre service à état (Base de données) ou sont présentes dans la requête CRUD.

L’architecture sans état est entièrement différente et meilleure que celle à état. Les applications Stateless passent très mal à l’échelle.

Étape 1 : Les demandes sont équilibrées en charge vers toute réplique d’un service stateless parce qu’il a toutes les données stockées ailleurs, généralement DB avec un stockage persistant.

Étape 2 : Lorsque le volume d’utilisateurs simultanés augmente en taille dans les applications Stateful, plus de serveurs exécutent les applications ajoutées, et la charge distribuée uniformément entre ces serveurs en utilisant un équilibreur de charge. Mais comme chaque serveur « se souvient » de l’état de chaque utilisateur connecté, il devient nécessaire de configurer cet équilibreur de charge en « sticky-mode ».’

Étape 3 : En même temps, la distribution de la charge à travers les serveurs, l’équilibreur de charge nécessaire pour envoyer la demande de chaque utilisateur au même serveur qui répond à la demande précédente de cet utilisateur, pour traiter la demande correctement, ce qui va à l’encontre de l’objectif de l’équilibrage de la charge parce que la charge n’étant pas distribuée dans un véritable Round-Robin.

Etape 4 : La logique côté serveur codée de telle sorte qu’elle ne dépende pas de  » l’état précédemment stocké  » du client.

Etape 5 : Les informations d’état envoyées avec chaque demande, au serveur par lequel le serveur procède au service de la demande. L’équilibreur de charge n’a pas besoin de se préoccuper de l’acheminement des demandes vers le même serveur, et un équilibrage de charge véritablement uniforme est réalisé.

Étape 6 : L’équilibreur de charge envoie le trafic vers n’importe quel serveur & demande bien desservie depuis que le client envoie un jeton ou toute autre info nécessaire avec chaque demande. JSON Web Token (JWT) largement utilisé pour créer des applications apatrides.

Avantages des applications apatrides

Les 5 avantages majeurs de l’application apatrides sont les suivants :

1. Supprime les frais généraux pour créer/utiliser des sessions.
2. Mauvaise échelle horizontale nécessaire pour les besoins des utilisateurs modernes.
3. Nouvelles instances d’une application ajoutées/supprimées à la demande.
4. Il permet la cohérence entre diverses applications.
5. L’apatridie rend une application plus confortable à travailler et maintenable.

Les avantages supplémentaires d’échelonnement et de performance des applications apatrides sont ci-dessous :

1. Réduit l’utilisation de la mémoire côté serveur.
2. Elimine le problème d’expiration de session – Parfois, les sessions expirantes causent des problèmes qui sont difficiles à trouver et à tester. Les applications apatrides n’ont pas besoin de sessions & donc elles n’en souffrent pas.
3. Du côté de l’utilisateur, l’apatridie permet aux ressources d’être liables. Si une page est apatride, alors lorsque l’utilisateur lie un ami à cette page, il s’assure que l’utilisateur visualise la même chose qu’un autre utilisateur visualisant.

Comment adopter les applications apatrides ?

Voici les 5 étapes pour adopter les applications apatrides

Etape 1 : Adapter et développer de nouvelles applications

Adopter les applications apatrides peut être une tâche intimidante au début car c’est un nouveau paradigme. Mais avec le bon état d’esprit et les bonnes informations, adaptez et développez de nouvelles applications sans conserver aucun état. Utilisez l’authentification/autorisation pour vous connecter au serveur.

Étape 2 : développer des applications à l’aide de microservices

Dans cette étape, la conteneurisation sera effectuée à des fins de déploiement. Les conteneurs sont les meilleurs pour exécuter des charges de travail sans état. Lorsque plusieurs conteneurs à gérer l’augmentation, envisager de passer à des outils d’orchestration et de gestion du cloud tels que Kubernetes pour exécuter un grand nombre de conteneurs.

Etape 3 : Applications microservices conteneurisées

Trouver le meilleur emplacement pour exécuter la sécurité des conteneurs à partir d’un point de ressources et maintenir la HA (haute disponibilité) de l’application.

Etape 4 : Attacher le stockage à l’éphémère Stateless

Le stockage attaché à l’éphémère est éphémère. Les organisations doivent commencer par les conteneurs Stateless car ils sont plus facilement adaptés à ce type d’architecture et séparés des applications monolithiques et mis à l’échelle de manière indépendante.

Etape 5 : Appliquer la philosophie REST

Le backend doit utiliser les modèles de conception REST pour construire les applications. La philosophie REST consiste à ne pas maintenir l’état, seulement légèrement les cookies et le stockage local du côté client.

Best Practices For Stateless Applications

Neuf pratiques simples pour maintenir correctement les applications sans état sont ci-dessous:

1. Essayer d’éviter les sessions à tout prix.
2. Les sessions ajoutent une complexité inutile fournissant très peu de valeur.
3. Il devient difficile de reproduire les bugs.
4. Difficile de corriger les bugs liés aux sessions car tout est stocké côté serveur.
5. Il n’est pas possible de faire évoluer les sessions.
6. Si la charge de l’application augmente de manière exponentielle, distribuez la charge sur différents serveurs. Si vous utilisez des sessions, répliquez toutes les sessions sur tous les serveurs en même temps. Le système devient très sophistiqué et sujet aux erreurs. Évitez les sessions.
7. Les sessions ne sont utiles que pour des cas d’utilisation spécifiques tels que FTP (File Transfer Protocol).
8. Pour des cas d’utilisation tels que le partage de Dropbox, les sessions avec état ajoutent des frais généraux supplémentaires, tandis que les apatrides sont parfaits pour aller.
9. La fonctionnalité des sessions est répliquée en utilisant des cookies, la mise en cache côté client.

Explore plus sur Microservices avec Golang – Une solution complète

Les outils d’applications Stateless

Les meilleurs outils d’applications Stateless sont ci-dessous :

1. Les langages modernes tels que Python, Golang.
2. À des fins de déploiement – Conteneurs et orchestration tels que Docker et Kubernetes.
3. Découverte d’autres services – Service de proxy Kube, Etcd.
4. Passerelle API – Pour se connecter à divers services de l’extérieur.
5. Pour le maillage de services autour de toutes les applications apatrides : LinkerD / Istio.

Conclure les applications Stateless

La plupart des entreprises informatiques qui construisent des Microservices, créent déjà des applications Stateless en utilisant la conception d’API REST. La compréhension de ce concept est le fondement sur lequel reposent la plupart des architectures modernes, comme des concepts tels que la conception RESTful. Une bonne compréhension et un avantage de Stateless par rapport à Stateful sont essentiels pour développer des applications répondant aux besoins massifs des utilisateurs d’aujourd’hui.

Share :