Le thème du « lock-in » est très populaire. Le « lock-out » devrait l’être tout autant !

Le présent nous aveugle. Nous ne regardons pas suffisamment à long terme. Nous ne nous posons pas la question suivante : « Et dans 90 jours, si une autre opportunité ou réalité se présente ? » C’est le sujet du lock-out.

« Nous sommes responsables de nos données ! Que se passe-t-il, en effet, si on a besoin d’une certaine fonctionnalité dans trois mois et que nous en sommes ‘exclu’ ? On craint le lock-in d’un fournisseur, on néglige le lock-out qui est pleinement de notre responsabilité », estime Michael Cade, Global Field CTO, Veeam Software. Concrètement, nous négligeons de nous laisser des options ouvertes ! »

Verrouillage de comptes dans des référentiels renforcés, problèmes de stockage comme des défaillances du mode de conformité du verrouillage d’objet nécessitant des procédures de restauration spécifiques… C’est cela le lock-out. Et plus encore.

Politiques de verrouillage

« Le lock-out des données peut faire référence à un blocage soudain de l’accès aux données ou à la configuration d’un système, souvent causé par des politiques de verrouillage de compte mal configurées ou des problèmes système, mais aussi à la fonction d’immuabilité des données qui empêche leur modification ou suppression pendant une période définie, précise Michael Cade. Les politiques de verrouillage de compte bloquent les tentatives d’accès non autorisées après un certain nombre d’échecs, tandis que la fonction d’immuabilité -par exemple, avec S3 Object Lock- protège les données contre les attaques de ransomware. »

Paradoxalement, on pense davantage lock-in que lock-out. Chez Veeam, qui a tout misé sur la flexibilité du format de données portable, la question du lock-in ne se pose pas. « Si vous décidez de ne plus être client Veeam, quelle qu’en soit la raison, vous bénéficiez d’un avantage majeur : une porte de sortie ! Le client n’a pas à payer de frais de maintenance pour restaurer ses charges de travail et effectuer des sauvegardes plus longues. »

Comprendre nos données

De là, une plus grande flexibilité. Et une meilleure gestion des coûts. Pour Michael Cade, il s’agit de voir plus loin. « Nous avons fait exploser les murs des centres de données, illustre-t-il. Cela signifie que nous n’avons plus besoin d’exister au même endroit, mais que nos données sont réparties sur de multiples plateformes. Ce qui veut dire que nous devons ‘comprendre’ nos donnée, savoir quelle est la partie la plus critique de ces données. Nous en avons toujours besoin, mais ce n’est probablement pas aussi important qu’on ne l’imagine, surtout en cas de problème. Néanmoins, il est essentiel de savoir où se trouvent nos données les plus critiques, parfaitement les localiser. »

La réponse commence par la création des données elles-mêmes. Autrement dit, la gestion du cycle de vie des données. Comprendre ses données est essentiel à bien des égards : comment les protéger, comment les déplacer, où sont-elles disponibles et bien d’autres choses encore.

Identifier les données redondantes

« En fin de compte, tout se tient. Et tout commence par l’application en tant que telle. Il faut toujours commencer par l’application, qu’elle soit sur Kubernetes, sur une machine virtuelle ou sur un serveur physique ; il faut que ce soit là, qu’on l’ait développée ou achetée. Ensuite, il faut l’exécuter quelque part : c’est la gestion du cycle de vie de l’infrastructure. Celle-ci sera peut-être construite manuellement. Ou, peut-être, utiliserons-nous une IaC (Infrastructure-as-Code) ou d’autres outils d’automatisation. Ensuite, il s’agira de gérer le cycle de vie continu. »

Pour Michael Cade, il sera regrettable de ne pas pouvoir accéder aux nouvelles fonctionnalités en général. Ainsi, pour les bases de données. « Si vous optez pour Amazon RDS, vous êtes redevable des mises à jour de cette base de données par Amazon. Il peut s’agir de Postgres 16 ou 17. Et si la mise à jour n’est pas assez rapide, vous passerez à côté des nouvelles fonctionnalités de la nouvelle version de Postgres si vous choisissez de rester bloqué sur Amazon RDS plutôt que d’utiliser votre propre version. Évidemment, vous devrez alors gérer cette version plus que la version RDS. »

Plus besoin ? Alors, on s’en débarrasse !

L’important est de pouvoir collaborer, évoluer et examiner la redondance. Autrement dit identifier les données redondantes, obsolètes ou triviales. Et pouvoir répondre à la question « En avons-nous encore besoin ? »

« Cela ramène à une approche plus saine des données : si nous n’en avons plus besoin, mieux vaut s’en débarrasser, car leur stockage coûte probablement cher. Ensuite, s’assurer que les données conservées sont de la plus haute qualité ; qu’elles résident sur le stockage le plus performant ; qu’elles sont protégées et offrent une résilience optimale. Et là, vous êtes dans le bon ! »

photo : Jan Volejníček