Applications avec et sans état : comment elles affectent DevOps

Avec état et sans état sont deux types différents d’architecture de calcul qui définissent la façon dont une application gère les processus de longue durée. Certains systèmes sont intrinsèquement sans état, tandis que d’autres ont tendance à être modélisés avec état. Quelle que soit l’approche que vous choisissez, cela affectera la façon dont les équipes de conception et d’exploitation construisent et maintiennent la solution.

Dans cet article, vous découvrirez les différences entre les applications avec état et sans état, et quand vous pouvez les utiliser. Vous verrez également comment les deux modèles affectent les exigences d’une implémentation DevOps.

Qu’est-ce qu’un état ?

L’« état » d’un service est une information persistante qui est enregistrée lors d’une transaction ou d’un événement, puis appelé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 stockées en toute sécurité. Un enregistrement enregistré dans une session doit être disponible pour la session suivante.

L’État doit être soigneusement géré afin qu’il puisse être utilisé à l’avenir. Les systèmes externes n’ont pas besoin de fournir beaucoup d’informations pour se référer à un événement précédent. Un simple identifiant, tel qu’un numéro de transaction de paiement, permet au service de récupérer d’autres données associées à l’action, telles que le montant du paiement et l’adresse de livraison.

Que sont les applications sans état ?

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

Les applications sans état gèrent chaque événement de manière isolée. Les événements ne sont pas conscients les uns des autres ou du contexte plus large dans lequel l’application s’exécute. Cette qualité simplifie la prise en compte des systèmes sans état. Il n’y a aucun risque que l’activité précédente affecte l’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 visualisé avec ou sans état, selon le point de vue à partir duquel vous l’abordez.

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

Vous pouvez déterminer si une application a besoin d’un modèle de déploiement avec ou sans état en regardant comment elle stocke les données. Il n’y a pas d’état s’il n’y a pas de persistance ou si les données sont uniquement stockées sur l’appareil de l’utilisateur ou dans un fournisseur de stockage non lié tel qu’Amazon S3. Une application conservera l’é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 conteneurs et cloud

Les applications modernes sont souvent déployées dans le cloud sous forme de conteneurs. Les conteneurs sont conçus comme 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.

Cependant, les conteneurs peuvent être utilisés pour encapsuler des systèmes avec état. Les volumes persistants permettent de monter un stockage durable qui dure plus longtemps que les instances de conteneur individuelles. Par rapport aux VM traditionnelles et aux déploiements bare metal, la différence se résume à l’intentionnalité interne 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 des chemins de système de fichiers arbitraires car ils ne seront pas mappés à 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 garantir que votre application écrit de manière cohérente le chemin d’accès au volume monté. Vous devez donc déterminer à l’avance vos besoins en matière de stockage de données.

Comment le statut affecte DevOps

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

Un service avec état nécessite une approche plus réfléchie de la gestion. Chaque instance d’application doit avoir accès à l’état partagé. Cela peut imposer des restrictions de mise à l’échelle. Peu de distributions Kubernetes permettent , par exemple, à plusieurs nœuds de monter un volume avec un accès en écriture en même temps.

Les deux types d’applications 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 exigences de stockage et déterminer quand le montage du volume affecte les options de planification des conteneurs. Les déploiements avec état doivent également être pris en charge par une stratégie de sauvegarde normale.

L’état complique également le processus DevOps en rendant difficile la reproduction précise des environnements. Il devient possible que le problème existe en production, tout en restant insaisissable sur la machine du 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 d’intégration continue plus complexes et difficiles à maintenir. L’état est inévitable dans la plupart des applications majeures, donc essayer trop fort de garder les systèmes sans état peut être un faux-fuyant 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 plus de travail à venir.

Sommaire

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

Les applications sans état sont complètement séparées de leur environnement, ce qui facilite généralement leur conteneurisation et leur mise à l’échelle dans le cloud. Cependant, les véritables systèmes sans état sont relativement rares, ils sont donc généralement associés à des magasins de données avec état. La refactorisation vers des composants sans état lorsque cela est possible lors de la création d’outils pour prendre en charge les déploiements avec état est généralement le moyen le plus efficace d’équilibrer DevOps optimisé avec les exigences fonctionnelles de votre système.