Lorsque l’on parle aujourd’hui d’applications faites pour le cloud, qu’il soit privé, public ou souverain, le réflexe quasi instantané est de se tourner vers une plateforme moderne de gestion de conteneur telle que Kubernetes, avec tout son écosystème et des méthodologies DevSecOps. Dans ce contexte et ces usages, la capacité à déplacer les applications et les données est un enjeu majeur pour les entreprises qui s’appuient sur Kubernetes ; et la recherche d’une solution de gestion et de protection des données pour ces environnements est devenue une quête stratégique, avec des critères bien précis à intégrer.

Certains verticaux, comme le secteur de la finance et des assurances ou encore le secteur public, ont clairement franchi le pas en décidant d’opérer cette nouvelle forme d’application, considérée comme « Coud Native » en production. Historiquement, dans des environnements Kubernetes, on différencie les applications ne stockant pas de données persistantes (dites « Stateless ») et celles consommant des services de données sous toutes ses formes (dites « Stateful »).

Depuis sa création, le projet Kubernetes n’a cessé d’évoluer dans la gestion et la prise en charge des volumes de données persistantes, sous l’effet notamment de l’apparition du composant CSI driver (Container Storage Interface) en 2017, puis du standard homonyme en 2018 et enfin des snapshots et des clones en 2019. Depuis trois ans, on constate une croissance exponentielle des applications dites « Stateful » en production – ces deux termes étant clés. La CNCF (Cloud Native Computing Foundation) réalise chaque année une étude auprès des utilisateurs de Kubernetes pour comprendre et analyser son adoption sur le marché. Parmi les 11 technologies les plus déployées en environnement Kubernetes, 9 correspondent à des moteurs de base de données ou application stockant de la donnée persistante sous différentes formes, d’après une étude réalisée par Datadog. 

Portabilité des données et des applications, un critère central

Les décideurs techniques doivent se conformer à des règlementations et des obligations lors de la mise en production de ces nouvelles applications, nécessitant des services de plan de reprise d’activité, de sauvegarde et de restauration. Pour beaucoup se pose aussi la question du débordement dans le cloud public ou le cloud souverain en fonction de la nature des données et des activités concernées. Le sujet de la mobilité des applications constitue une préoccupation majeure qui doit être adressée.

Les décideurs métiers doivent être capables d’aller capter de nouveaux marchés de plus en plus rapidement. La portabilité des applications devient un enjeu fondamental tout en préservant l’intégrité de la donnée. La capacité à déplacer les applications ainsi que les données qui y sont associées constitue un facteur de compétitivité important. Cette problématique est déjà bien connue dans le monde du Edge Computing, et notamment des opérateurs de télécommunications, mais c’est également le cas du secteur de la finance, aussi bien les banques que les assurances. Ces acteurs cherchent constamment à se rapprocher du marché qu’ils tentent de conquérir, que ce soit pour améliorer une expérience utilisateur ou avoir la possibilité de se déployer dans une nouvelle zone géographique pour satisfaire des contraintes règlementaires. Ce besoin de mobilité des applications se retrouve également dans certains secteurs verticaux et dans le retail et sera de plus en plus présent pour les secteurs d’activité où l’agilité est essentielle pour rester compétitif.

Le défi de la gestion de la donnée en production dans Kubernetes

C’est la raison pour laquelle l’ensemble des décideurs doivent se pencher sur la question de la gestion de la donnée en production dans le cadre de cette nouvelle plateforme cloud qu’est Kubernetes. C’est probablement la première fois sur le marché de l’IT qu’il existe une plateforme commune et complètement standardisée, capable d’unifier l’ensemble des clouds. Que l’environnement Kubernetes soit déployé dans un cloud privé, public, souverain ou dans des scenarios de Edge Computing, l’API Kubernetes reste la même, quel que soit le fournisseur retenu (Red Hat, Suse, VMware, AWS, Azure, GCP ou encore OVH). Ce dénominateur commun vient accélérer et faciliter tous les enjeux autour du cloud hybride.

Il existe un certain nombre de bonnes pratiques pour réussir avec succès l’adoption de Kubernetes, qui plus est dans un contexte hybride et multicloud. Le maître mot est la mobilité. La portabilité des applications permet de se rendre agnostique du cloud, de l’infrastructure et de la distribution Kubernetes qui peut être retenue à un instant du cycle de décision.

En tant que dénominateur commun entre tous les cloud disponibles aujourd’hui, l’API Kubernetes permet d’avoir une standardisation des services proposé par la plateforme. L’approche consiste, dans un premier temps, à disposer d’une méthode de sauvegarde de nouvelle génération garantissant la consistance de la donnée de bout en bout. La consistance au niveau applicatif est liée à la présence importante de bases de données dans ces applications dites cloud native.

Dans un deuxième temps, un plan global de reprise d’activité doit être mis en place pour répondre aux SLAs (Service Level Agreements) des environnements de production, avec la mise en place d’une automatisation afin d’éviter l’erreur humaine. Puis, dans un troisième temps, lors de la restauration de ces applications sur le site de destination, un mécanisme de transformation doit être enclenché pour rendre les applications compatibles avec l’environnement de destination. Une transformation qui s’avère parfois nécessaire car elle intègre les spécificités des services d’infrastructures source dans l’environnement de destination (nouveau type de stockage, réseau).

Quels critères fondamentaux pour le choix d’une plateforme ?

Le choix d’un service de stockage pour gérer les données sur ce type d’application doit faire l’objet de la plus grande attention. Afin de pouvoir supporter tout type de donnée et tout type d’application, le principal critère est de disposer de fonctionnalités de snapshot et de clone sur les volumes de données consommés par ces applications s’exécutant au sein d’une plateforme Kubernetes.

Pour bénéficier de ces atouts sur la gestion du stockage, la donnée doit résider au plus près de l’application, autrement dit à l’intérieur du cluster Kubernetes. Cette unification de la donnée avec les composants applicatifs permet de traiter l’ensemble comme un tout, une seule unité opérationnelle simplifiant grandement les scénarios de mobilité. Lorsque la donnée réside à l’extérieur du cluster Kubernetes, il faut démultiplier les process et les efforts pour capturer d’un côté l’application, et de l’autre le service de données. Ce type de schéma est souvent hérité des équipes IT, encore bien trop souvent organisées en silos. Séparer les compétences stockage, DevOps et bases de données au sein d’une équipe se reflète inévitablement sur les choix d’architectures des applications.

En résumé, pour négocier correctement le virage du cloud natif, il est recommandé de casser les silos organisationnels pour rassembler les compétences au sein d’une même équipe, et de garder la donnée au plus proche de l’application, car Kubernetes et son écosystème ont atteint le niveau de maturité nécessaire. Cette unification de la donnée avec l’application constitue le sésame pour bénéficier de la mobilité des applications dans des scénarios de cloud hybride.