Le rythme des migrations depuis les SGBDR propriétaires vers PostgresQL est soutenu. Pour que les entreprises se sentent en confiance dans leurs projets ambitieux de migrations de bases critiques, il est essentiel que la première migration soit suffisamment simple pour ne pas être un échec et suffisamment complexe pour que le projet soit significatif. Il est donc essentiel de bien choisir la base de données de sa première migration.
Selon le rapport 2019 PostgreSQL Trends Report, PostgreSQL est si populaire que 11,5 % des personnes interrogées affirment avoir en cours des projets de migration vers le SGBDR open source. Tous besoins confondus, il s’agit du premier des 4 systèmes les plus populaires au monde.
Le rapport, qui analyse également les combinaisons de bases de données les plus utilisées avec PostgreSQL, pointe que 27,3 % exploitent Oracle Database au sein de la même organisation. On peut attribuer cette situation au passage d’un modèle commercial basé sur les licences à un modèle d’utilisation de solutions open source, au sein duquel les organisations développent de nouvelles applications en association avec une base de données open source alors que les systèmes plus anciens, ou plus difficiles à migrer sans impact sur la continuité des affaires, restent sur Oracle.
Les nouvelles applications sont un excellent moyen pour les entreprises de tester PostgreSQL avant de migrer d’autres éléments de leur infrastructure. Dans les faits, PostgreSQL est généralement l’alternative principale à Oracle et en complément des nouveaux projets applicatifs, les migrations se poursuivent à un rythme soutenu.
Proximité technologique
Ce type de migration est facilité par une proximité sur le plan technique et par le fait que les deux systèmes partagent beaucoup de concepts communs : transactions, vues matérialisées, procédures stockées, fonctions analytiques, etc. Dès lors, migrer d’Oracle à PostgreSQL n’a rien d’un séisme technologique : au contraire, les DBA Oracle sont en mesure de maîtriser sans difficulté un parc d’instances PostgreSQL.
Du pareil au même ?
Cette facilité de transition, et l’aspect quasiment « iso-fonctionnel » signifient aussi que les avantages de la migration peuvent parfois être mal compris.
Le passage d’un système propriétaire traditionnel vers une base comme PostgreSQL est un projet ambitieux, qui demande du temps, et qui peut être perçu comme n’apportant qu’une valeur ajoutée marginale : si l’outil fait globalement la même chose, alors pourquoi changer ? La question mérite d’être posée.
L’explication réside dans le fait que les bénéfices se trouvent « ailleurs ». Pour la migration, le changement de paradigme ne se situe simplement pas au niveau technique.
Choisir PostgreSQL consiste surtout à opérer un virage à 180° dans la relation client-fournisseur.
Le premier changement concerne le modèle de licence : opter pour PostgreSQL, c’est bénéficier des avantages de la licence BSD dérivée, qui donne le droit d’utiliser gratuitement PostgreSQL sans restrictions et sans redevance. Pour autant, cela ne signifie pas que le coût de possession de PostgreSQL est nul : un TCO incompressible doit être évalué.
Par ailleurs, les freins à la virtualisation n’existent pas : PostgreSQL fonctionne parfaitement sur des serveurs physiques ou virtuels, sans que cela n’impacte les coûts de possession. Ce n’est d’ailleurs pas un hasard si de grands acteurs du Cloud Computing ont opté pour PostgreSQL comme base de données par défaut.
Les autres avantages du passage à PostgreSQL consistent à s’affranchir des verrous technologiques imposés par les fournisseurs propriétaires, des ventes liées (qui augmentent la dépendance au fournisseur) et des audits intrusifs qui ont été décriés pendant les dernières décennies par les groupements d’utilisateurs, parmi lesquels le Cigref et EuroCIO dont la relation avec leurs fournisseurs est depuis longtemps — et jusqu’à récemment — faite de hauts et de bas.
En comparaison, PostgreSQL offre aux entreprises de reprendre le contrôle sur l’infrastructure, de bénéficier d’une meilleure visibilité sur les feuilles de route produit, et donc assurer la pérennité de l’infrastructure de données. Ce n’est donc pas un hasard, si — en France — le Groupe de Travail Inter-Entreprises PostgreSQL (PGGTIE) avait lancé un appel aux éditeurs de logiciels pour un support de PostgreSQL.
Reste à savoir « par où commencer ? »
La question est moins évidente qu’il n’y paraît de premier abord. Un grand nombre de critères peuvent être pris en compte pour prioriser les bases à migrer. On peut par exemple commencer par les bases techniquement les plus simples, les bases/applications les moins coûteuses à migrer, les projets dont le ROI est le plus évident. Bien sûr, il faut pouvoir aussi tenir compte des « roadmaps » applicatives.
Il est intéressant de noter que la criticité du système pour l’activité de l’entreprise n’est généralement pas un critère qui entre en ligne de compte dans la priorisation des projets de migration.
Le choix de la première base à migrer est essentiel, et repose sur d’autres critères.
Il peut en effet s’avérer démotivant d’initier un projet de migration sur une base trop compliquée. Dans la situation d’une entreprise n’ayant pas d’expérience au préalable de migration, qui ne connaît pas les spécificités de PostgreSQL, il vaut mieux se concentrer sur un projet parfaitement dimensionné en termes de taille et de difficulté.
Si l’entreprise démarre sur un projet trop long, trop complexe, qui demande trop d’interactions avec les équipes, en fait, elle risque d’apporter un contre-argument pour la migration vers PostgreSQL. Cela peut être perçu comme un signal très fort qu’il ne s’agit pas d’une stratégie appropriée et qu’il va falloir identifier ailleurs des leviers de réduction des coûts.
Pour crédibiliser le programme global, la première migration doit donc être à la fois significative et… absolument réussie.
Il faut donc que la cible choisie ne soit pas trop complexe. Pas trop facile non plus, pour éviter l’excès de confiance.
L’outil Ora2Pg, très réputé dans la communauté, fournit des indications concernant les meilleurs candidats à la migration. Il est la référence open source en matière de migration et embarque une fonctionnalité très intéressante permettant d’effectuer un scoring. Il se connecte au système, effectue un inventaire de toutes les bases de données qu’on souhaite migrer dans un parc, et établit un score. En comptabilisant le nombre de tables, le nombre d’index, le nombre de procédures et en analysant les composants dans la base de données Oracle, Ora2Pg catégorise les bases en fonction de leur complexité. Il estime même la durée de migration et permet, à partir de cette image du parc, d’identifier rapidement les pièges et de sélectionner les bons candidats pour une première migration.
Étude de faisabilité
Ensuite, avec l’accompagnement et les outils appropriés, il faut étudier la faisabilité sur la base d’éléments techniques. Suivent donc les phases d’étude, le plus souvent menées par un prestataire externe, expert de PostgreSQL. Il s’agit du moment où l’on regarde au plus près la base de données, les applications, où les outils sont analysés, où les échanges sont menés avec les équipes de développement, où l’on s’assure enfin de la possibilité de connecter les systèmes. C’est à ce moment qu’est déterminée la méthode qui sera appliquée, la recette.
Cette étude demande un temps variable en fonction du planning de l’entreprise et de ses priorités. Mais une fois l’étude livrée, l’entreprise dispose au choix :
- d’une base de données PostgreSQL sur laquelle la couverture fonctionnelle est de 100 %, à l’identique de l’environnement précédent.
- d’un document d’exploitation qui explique précisément comment utiliser la nouvelle fonctionnalité par rapport à l’ancienne, avec des exemples pour que des études puissent être effectuées en interne, dans l’éventualité où la solution fonctionnelle alternative différerait beaucoup de la solution initiale.
La bascule
Vient ensuite le moment de la bascule. Dans la majorité des cas, la migration se passe bien, et l’entreprise bénéficie d’une solution fiable, pérenne pour les besoins de gestion des données et peut se concentrer sur l’innovation plutôt que sur la gestion des audits agressifs. Un point de suivi avec le client permet de vérifier qu’il n’y a pas de retour négatif de la part des utilisateurs. Dans le cas contraire, un plan de retour en arrière est amorcé pour arriver à une situation satisfaisante.
Pour résumer, la première migration doit pouvoir mettre les équipes en confiance pour les prochaines migrations. Il est donc essentiel de bien choisir la base concernée.
Il est aussi essentiel de s’assurer de disposer des ressources humaines et matérielles suffisantes, et de contrôler les coûts. Enfin, il est important de se donner le temps, et de profiter du fait que le service rendu par l’infrastructure existante est déjà présent et fonctionnel.
Précipiter la migration et imposer des délais difficiles à tenir est contre-productif, car le stress qui en résulte risque de changer les équipes concernées en détracteurs, plutôt qu’en promoteurs du changement. Pour que la première migration soit un succès, il faut donc donner le temps aux équipes responsables de se préparer, de comprendre chaque étape, pour que la migration de la base suivante, nécessairement plus complexe, soit elle aussi, le moment venu, un succès.
____________________________
Par Florent Jardin, Associé, Consultant migrations, Chef de projets et Formateur chez DALIBO
puis