Applications avec état vs sans état : leur impact sur DevOps

Avec état et sans état sont deux types différents d’architecture de calcul qui déterminent la façon dont une application gère les processus de longue durée. Certains systèmes sont naturellement sans état tandis que d’autres ont un parti pris pour la modélisation avec état. Quelle que soit l’approche que vous choisissez, cela affectera la façon dont les équipes d’ingénierie et d’exploitation construisent et maintiennent la solution.

Dans cet article, vous apprendrez les différences entre les applications avec et sans état, ainsi que le moment où chacune peut être utilisée. Vous verrez également comment les deux modèles influencent les exigences des implémentations DevOps.

Qu’est-ce que l’État ?

L’« état » d’un service est l’information persistante qui est enregistrée lors d’une transaction ou d’un événement, puis rappelée lors d’une autre. L’un des exemples les plus simples d’état est un serveur de base de données : il gère les données stockées qui doivent être conservées de manière fiable. Un enregistrement sauvegardé dans une session devra être récupérable par la suivante.

L’état doit être soigneusement géré afin qu’il soit utilisable à l’avenir. Les systèmes externes ne devraient pas avoir besoin de fournir beaucoup d’informations pour référencer un événement précédent. Un simple identifiant tel qu’un numéro de transaction de paiement permet au service de restaurer le reste des données associées à l’activité, telles que le montant du paiement et l’adresse de livraison.

Que sont les applications sans état ?

Toutes les applications n’ont pas d’état. Certains systèmes ne fonctionnent pas avec des données à longue durée de vie ou ne les mettent en cache que pour améliorer les performances. Ils fonctionneront toujours si les données précédemment stockées sont perdues.

Les applications sans état gèrent chaque événement de manière isolée. Les événements n’ont aucune connaissance les uns des autres ou du contexte plus large dans lequel l’application fonctionne. Cette qualité rend les systèmes sans état plus faciles à raisonner. Il n’y a aucun risque qu’une activité antérieure affecte une opération en cours.

Mon application est-elle avec ou sans état ?

Certaines applications brouillent les frontières entre les modèles avec et sans état. Le même système peut être considéré à la fois avec état et sans état, selon la perspective à partir de laquelle vous l’abordez.

Les applications Web côté client sont généralement considérées comme sans état du point de vue d’un opérateur de service. Ils peuvent être hébergés par un serveur Web statique, indépendamment de tout autre composant. L’application peut encore accumuler de l’état pendant l’utilisation, comme les paramètres enregistrés sur l’appareil de l’utilisateur et un historique des pages récentes. Cette forme d’état n’est pas pertinente pour les équipes DevOps car elle n’affecte pas la façon dont l’application est déployée.

Vous pouvez déterminer si une application a besoin d’un modèle de déploiement avec ou sans état en examinant la manière dont elle stocke les données. L’état n’est pas présent lorsqu’il n’y a pas de persistance ou que les données ne sont stockées que sur l’appareil de l’utilisateur ou dans un fournisseur de stockage découplé comme Amazon S3. L’application sera avec état si elle modifie directement son environnement par le biais d’écritures sur le système de fichiers et d’autres modifications, puis exige que ces modifications persistent indéfiniment.

État avec les conteneurs et le cloud

Les applications modernes sont souvent déployées dans le cloud sous forme de conteneurs. Les conteneurs sont conçus pour être des unités fonctionnelles éphémères qui peuvent être remplacées sans effets secondaires. Cela signifie qu’il s’agit principalement de composants de calcul sans état.

Les conteneurs peuvent cependant être utilisés pour encapsuler des systèmes avec état. Les volumes persistants permettent d’attacher un stockage fiable qui survit aux instances de conteneur individuelles. Par rapport aux machines virtuelles traditionnelles et aux déploiements bare metal, la différence se résume à l’intentionnalité inhérente de la gestion de l’état des conteneurs.

La conteneurisation d’un système avec état nécessite que vous anticipiez où l’état se produit et comment il est stocké. Vous ne pouvez pas écrire naïvement dans des chemins de système de fichiers arbitraires car ils ne seront pas mappés sur un volume. Sans volume, les données seront perdues si le conteneur s’arrête ou est remplacé. Une période de refactorisation peut être nécessaire pour que votre application écrive de manière cohérente sur un chemin de volume monté. Vous devez donc identifier à l’avance les besoins en stockage de données.

Comment l’état affecte DevOps

Les processus DevOps doivent être ajustés selon que vous exécutez des services avec état ou sans état. Les modèles de déploiement sans état offrent beaucoup plus de liberté de fonctionnement. Vous pouvez facilement lancer de nouveaux conteneurs et les mettre à l’échelle sur plusieurs nœuds distribués sans avoir à vous soucier de l’accès à l’état persistant.

Un service avec état nécessite une approche de gestion plus réfléchie. Chaque instance d’application doit avoir accès à l’état partagé. Cela peut imposer des restrictions sur la façon dont vous évoluez. Peu de distributions Kubernetes permettent à plusieurs nœuds de monter simultanément un volume avec un accès en écriture, par exemple.

Les deux types d’application nécessitent une surveillance proactive afin que vous soyez au courant des problèmes avant qu’ils ne surviennent. Ceci est plus important pour les solutions avec état, car vous devez garder une longueur d’avance sur les besoins de stockage et identifier quand les options de planification des conteneurs sont affectées par les montages de volume. Les déploiements avec état devront également être pris en charge par une stratégie de sauvegarde régulière.

L’état complique également le processus DevOps en rendant difficile la reproduction exacte des environnements. Il devient possible qu’un problème existe en production tout en restant insaisissable sur la machine d’un développeur. Ces problèmes peuvent être difficiles à diagnostiquer. Vous pouvez les rendre plus gérables en fournissant des mécanismes permettant aux développeurs de cloner des environnements afin qu’ils puissent reproduire les problèmes dans un bac à sable.

L’état ajoute toujours de la complexité et des frais généraux. Vous devez configurer et fournir des solutions de gestion d’état telles que des volumes et des bases de données, ce qui rend les pipelines CI plus compliqués et plus difficiles à entretenir. L’état est inévitable dans la plupart des applications majeures, mais essayer trop fort de garder les systèmes sans état peut être une diversion inutile. Il est préférable d’utiliser des outils et une formation pour intégrer de manière transparente des applications avec état dans vos routines DevOps, même si cela signifie qu’il y aura plus de travail en amont.

Sommaire

La distinction entre les applications avec état et sans état est importante pour le succès de DevOps. Du point de vue DevOps, une application avec état sera plus complexe à déployer et à maintenir car vous devez fournir à chaque instance un accès à un magasin de données persistant.

Les applications sans état sont entièrement découplées de leur environnement, ce qui facilite généralement leur conteneurisation et leur mise à l’échelle dans le cloud. Cependant, les systèmes véritablement sans état sont relativement rares, vous les combinerez donc généralement avec des magasins de données avec état. La refactorisation vers des composants sans état lorsque cela est possible, tout en créant des outils pour prendre en charge les déploiements avec état, est normalement le moyen le plus efficace d’équilibrer DevOps rationalisé avec les exigences fonctionnelles de votre système.