L’état d’une application (ou de toute autre chose, en fait) est sa condition ou sa qualité d’être à un moment donné dans le temps – son état d’être. Le fait que quelque chose soit stateful ou stateless dépend de la durée d’enregistrement de l’état de l’interaction avec cette application et de la manière dont cette information doit être stockée.
Sans état
Un processus ou une application sans état peut être compris de manière isolée. Il n’y a pas de connaissance stockée des transactions passées ou de référence à celles-ci. Chaque transaction est effectuée comme si elle partait de zéro pour la première fois. Les applications apatrides fournissent un service ou une fonction et utilisent des réseaux de diffusion de contenu (CDN), des serveurs web ou d’impression pour traiter ces demandes à court terme.
Un exemple de transaction sans état serait de faire une recherche en ligne pour répondre à une question à laquelle vous avez pensé. Vous tapez votre question dans un moteur de recherche et vous appuyez sur la touche Entrée. Si votre transaction est interrompue ou fermée accidentellement, il vous suffit d’en commencer une nouvelle. Pensez aux transactions sans état comme à un distributeur automatique : une seule demande et une réponse.
Stateful
Les applications et processus stateful, cependant, sont ceux auxquels on peut revenir encore et encore, comme la banque en ligne ou le courrier électronique. Ils sont exécutés avec le contexte des transactions précédentes et la transaction actuelle peut être affectée par ce qui s’est passé lors des transactions précédentes. Pour ces raisons, les apps stateful utilisent les mêmes serveurs chaque fois qu’elles traitent une requête d’un utilisateur.
Si une transaction stateful est interrompue, le contexte et l’historique ont été stockés de sorte que vous pouvez plus ou moins reprendre là où vous vous êtes arrêté. Les apps stateful suivent des choses comme l’emplacement de la fenêtre, les préférences de réglage et l’activité récente. Vous pouvez considérer les transactions stateful comme une conversation périodique continue avec la même personne.
La majorité des applications que nous utilisons au quotidien sont stateful, mais à mesure que la technologie progresse, les microservices et les conteneurs facilitent la création et le déploiement d’applications dans le cloud.
Conteneurs et état
Au fur et à mesure que le cloud computing et les microservices gagnent en popularité, il en va de même pour la conteneurisation des applications, qu’elles soient avec ou sans état. Les conteneurs sont des unités de code pour une application qui sont empaquetées, avec leurs bibliothèques et leurs dépendances, de manière à pouvoir être déplacées facilement et à pouvoir s’exécuter dans n’importe quel environnement, que ce soit sur un poste de travail, une infrastructure informatique traditionnelle ou sur un cloud.
À l’origine, les conteneurs étaient construits pour être apatrides, car cela convenait à leur nature portable et flexible. Mais à mesure que l’utilisation des conteneurs s’est généralisée, les gens ont commencé à conteneuriser (remanier et reconditionner aux fins d’exécution à partir de conteneurs) des apps étatiques existantes. Cela leur a donné la flexibilité et la vitesse d’utilisation des conteneurs, mais avec le stockage et le contexte de l’état.
En raison de cela, les applications avec état peuvent ressembler beaucoup aux applications sans état et vice versa. Par exemple, vous pourriez avoir une app qui est sans état, ne nécessitant aucun stockage à long terme, mais qui permet au serveur de suivre les demandes provenant du même client en utilisant des cookies.
Gestion des conteneurs avec et sans état
Avec la croissance de la popularité des conteneurs, les entreprises ont commencé à fournir des moyens de gérer les conteneurs avec et sans état en utilisant le stockage de données, Kubernetes et StatefulSets. Le Statefulness est maintenant une partie importante du stockage des conteneurs et la question est devenue non pas de savoir s’il faut utiliser des conteneurs stateful, mais quand.
L’utilisation ou non de conteneurs stateful ou stateless se résume à une question de type d’app que vous construisez et de ce que vous avez besoin qu’elle fasse. Stateless est la voie à suivre si vous avez juste besoin d’informations de manière transitoire, rapidement et temporairement. Si votre app nécessite plus de mémoire de ce qui se passe d’une session à l’autre, cependant, stateful pourrait être la voie à suivre.
Stateful, stateless, and Red Hat
Quand il s’agit de stateful ou stateless, Red Hat vous couvre. Que vous orchestriez des conteneurs stateful sur notre plateforme Kubernetes prête pour l’entreprise, Red Hat OpenShift, ou que vous créiez un environnement unifié pour le dev d’apps avec Red Hat Integration, vous serez soutenu par notre support primé et le plus grand écosystème de partenaires du secteur.