Salut l’internaute,

Il y en a qui disent que le domaine BDD (bases de données) est incompatible avec l’agilité ou le DevOps. Faux, faux, FAUX ! Les conclusions de cet article clouent le bec à tous ces médisants.

Je suis Sophie et je te partage ma restitution de notre atelier de retours d’expériences de migrations de bases de données dans le cloud et sur site.

Je commence par la fin

Parce que tu es impatient l’internaute (et parce que j’aime clouer les becs), je commence par mes trois conclusions de notre atelier :

Conclusion 1 : 100% des migrations BDD aboutissent

Sur les 9 projets de migration BDD vécus par nos participants, aucun n’a été abandonné.

Conclusion 2 : qui va trop vite fait nin d’bien

Quand le premier objectif est la réduction des coûts il est tentant de vouloir aller vite, mais en dessous d’un an de durée de projet ça coûte très cher : épuisements professionnels, départs de personnel, dégradation des services métiers avec impact financier. Un projet de migration BDD sans impact est un projet réalisé au fil des évolutions applicatives.

Conclusion 3 : les DBA ont l’agilité dans le sang

Le groupe a synthétisé les bonnes pratiques à appliquer pour un projet de migration :

• Commencer par ce qui est simple à migrer, et complexifier au fur et à mesure
• Intégrer tous les acteurs (métiers, DEV et OPS) et soigner la communication entre eux
• Prendre son temps, ne pas créer de dette technique et de dette d’exploitation
• Tester en recette, tester en pré production, tester, tester, TESTER !

Si ça ce ne sont pas des bonnes pratiques de l’agilité et du DevOps, je veux bien changer la couleur de TECHSYS !

Et si tu veux connaître le cheminement qui nous a mené à ces conclusions, tu peux lire le détail maintenant :

Les participants de l’atelier

Ingénieur data, ingénieur réseaux, DBA (administrateur de bases de données), intégrateur technique, CTO (Chief Technical Officer), responsable de production, architecte technique, ingénieur d’affaires : nous étions 12 et pluridisciplinaires avec une forte représentativité du métier des DBA.

Pourquoi migre-t-on les bases de données ?

Sur les 9 cas travaillés en séance et vécus par les participants, les migrations BDD sont justifiées par :

• L’obsolescence des socles dans 55% des cas. Ici la fin du support des solutions en place est le déclencheur.
• La volonté de migrer vers le cloud 45% des cas. Ici, aller dans le cloud est l’objectif, de façon totale ou partielle.

Quelle que soit la raison, l’efficience financière est toujours recherchée.

Nous avons évoqué les tactiques d’optimisation des coûts les plus fréquemment rencontrées :

• Supprimer les hébergements sur site (On Premise) et/ou en Data Center
• Utiliser des services managés dans le cloud, ou DBAAS (DataBase As A Service)
• Privilégier les solutions libres aux solutions éditeurs

Vers quoi migre-t-on les bases de données ?

Sur les 9 cas vécus par les participants, 8 migrations BDD intégraient un mixte de :

• Montée de versions des socles BDD (Oracle, PostGreSQL, MySQL et Microsoft SQL)
• DBAAS (AWS RDS ou Aurora, Google BigQuery, Oracle Exadata Cloud Customer, Oracle Cloud Infrastructure)
• Remplacement de solutions éditeurs par des solutions libres (le plus souvent de Oracle Database vers PostGreSQL)

Une exception : un seul cas concernait une migration en « Lift and Shift » de On Premise vers le cloud, c’est-à-dire à l’identique de l’existant, au prorata des adaptations indispensables au support du provider. L’objectif était d’aller vite car les socles nécessaires dans le cloud (Infrastructure As A Service) sont plus chers que les socles On Premise.

Le choix du socle IT cible est un arbitrage entre les moyens financiers, le besoin d’innovation, l’acceptation du risque, les ressources IT techniques et humaines, la capacité de transformation, … le choix du socle IT cible est donc par essence sur mesure du contexte de l’entreprise.

Comment migre-t-on les bases de données ?

Les participants ont recensé les solutions qu’ils ont mises en œuvre en identifiant pour chacune les limites et/ou les points d’attention. Voici un résumé de leur travail :

Lift and Shift

Les points d’attention identifiés en atelier sont les licences, la compatibilité du ou des cloud providers avec les moteurs BDD et leurs versions (par exemple, il est difficile d’héberger des BDD Oracle sur Google Cloud Provider), le coût du « ménage à réaliser sur les socles » avant la migration.

DBAAS

Les difficultés listées en atelier sont la compatibilité du ou des cloud providers avec les moteurs BDD et leurs versions, les arrêts contractuels de ces services pour le patching des moteurs BDD, la complexité de migration vers un moteur « maison » du CSP (Cloud Solutions Provider) type AWS Aurora ou GCP Spanner, mais surtout la dépendance à terme induite par l’utilisation de ce type de service.

Transformer le PL/SQL

L’utilisation de PL/SQL est riche en fonctionnalité, mais cela est aussi un frein à la portabilité des applications et des moteurs BDD. Des outils de transposition de ce code PL/SQL existent, comme l’outil TRANSFORMER for PostgreSQL de la société CHEOPS TECHNOLOGY testé par nos participants. Leur utilisation engendre un coût financier, un coût en temps et en prestation ou en montée en compétences. Et un reliquat de code PL/SQL non transformé estimé à 20% reste à traiter « à la main et au cerveau ».

ETL

Les ETL (Extract Transform Load) collectent la donnée, la transforment et la transfèrent d’un composant data à un autre. S’ils sont déjà en place pour leur utilisation dans le domaine BI (Business Intelligence), leur utilisation dans le cadre d’une migration BDD peut être une bonne solution. Mais les coûts de leur intégration et de leur exploitation dans le seul but d’une migration BDD ne sont pas rentables.

Streaming de données

Les solutions de diffusion de données en continu, comme Apache Kafka, peuvent être utilisées pour transformer et transférer la donnée de l’existant à la cible de la migration. Comme pour les ETL, leur intégration dans le but unique de migrer des BDD n’est pas rentable.

Clonage

Les solutions de clonage d’environnements proposées par les CSP, ou issues de solutions Infras As Code du contexte existant, sont un accélérateur des migrations BDD à l’échelle.

Import/export

Les solutions d’export/import de données, comme Oracle Data Pump, font partie de la boîte à outils de l’administration des BDD, et sont à ce titre maîtrisées. Les limites à leur utilisation dans le cadre d’une migration sont les interruptions de services, les changements de plan d’exécution, et les temps de traitement des fortes volumétries (sous Oracle, l’utilisation de Transportable Tablespaces peut être une solution). Et attention à la compatibilité des « character set » des systèmes !

Utilitaire de montée de version

Certains éditeurs proposent des utilitaires de montée de version, comme Oracle Database Upgrade. Ils sont utiles pour les migrations iso moteur BDD, dans les limites des versions compatibles, et avec interruption de service.

Réplication BDD

Les solutions de réplication de BDD existantes pour un PCA (Plan de Continuité d’Activité), ou plus largement pour la résilience des BDD, peuvent être utilisées dans le cadre de migrations. Un exemple est Oracle Dataguard. L’avantage est que la migration se fait sans interruption de service et avec un outil maîtrisé par les équipes. Par contre, leur intégration dans l’unique but d’une migration n’est pas du tout rentable, car ces solutions sont onéreuses, complexes, mono éditeur et en compatibilité de versions limitée.

Transformer le moteur

Des utilitaires pour passer d’un moteur BDD à un autre existent. Ora2pg est le plus connu car répondant au cas d’usage le plus courant de migrer d’Oracle Database vers PostGreSQL. Les limites sont le code PL/SQL, les temps de traitement et l’interruption de service.

Sauvegardes

La restauration d’une BDD depuis un utilitaire de sauvegarde (Oracle RMAN, PostGreSQL Foreign Data Wrapper) est également un bon moyen de migrer une BDD. C’est simple, maîtrisé par les DBA et une bonne occasion de tester les sauvegardes ! La limite est la création préalable d’un socle cible compatible.

Ce qu’on néglige fréquemment

L’établissement d’un plan de migration utilisant efficacement les moyens détaillés plus haut est dans la zone de confort de tout DBA expérimenté. Les problèmes rencontrés par les participants relevaient plutôt du manque de transversalité dans le projet global de migration. Quelques exemples frappants :

Le réseau

Les migrations impactent les flux entre composants IT. L’existence d’une matrice de flux complète et à jour c’est un peu comme l’existence du Yéti… alors il est indispensable de prévoir du temps, des tests et une équipe réseau impliquée dans la préparation de la migration.

Spécifiquement pour les migrations BDD vers le cloud, une erreur courante est de croire que la liste des ouvertures de flux des firewalls sera suffisante : les BDD étant par nature en DMZ basses, certains flux sont internes à un VLAN, et donc sans firewalls.

De plus, l’utilisation des services réseaux des CSP engendre des changements technologiques, et donc des impacts techniques nécessitant des adaptations.

Et aussi, l’hybridation IT On Premise/Cloud peut engendrer des ralentissements ou des dysfonctionnements si les interactions entre composants IT ne sont pas auditées, notamment pour la bande passante et la latence.

L’exploitabilité

Supervision, sauvegardes, processus et documentation, gestion des patchs, outils d’administration courante et avancée, … ce qui est utile à l’exploitation des socles et de leurs applications l’est dès la fin de la migration ! Sans eux, les équipes support et d’astreinte seront très sollicitées, et essuyer cette dette prendra du temps.

Merci pour ta lecture l’internaute ! N’hésite pas à réagir à cet article en commentaire de mon post LinkedIn 😊