Comment orchestrer la mutation de sa base de données vers une architecture libre ?

Par - Publié le Modifié le

Article modifié le 18/10/2018.

Cela fait 20 ans que dans l’univers des bases de données, les SI de nos entreprises restent pieds et mains liés aux grands éditeurs comme Oracle ou IBM. Une vraie solution s’impose désormais : Le moteur Libre PostgreSQL

Le modèle économique des éditeurs est trop souvent calqué sur les ressources de nos infrastructures. Les politiques tarifaires des éditeurs de base de données et le besoin croissant de processeurs puissants, ont étranglés nos entreprises. En effet, plus vous avez de cœurs processeurs sur une machine, plus vous payez. On peut donc très vite se retrouver avec une note astronomique.
Jusqu’à présent, les DSI (Directeurs de Système d’Information) étaient frileux envers l’utilisation de solutions du monde du logiciel libre.

Les raisons :

  • Pas ou peu de support
  • Des fonctionnalités de hauts niveaux non disponibles comme le partitionnement ou la réplication.

Mais cette ère est maintenant révolue avec le moteur PostgreSQL. Toutes les fonctionnalités d’un moteur de base de données moderne sont là.
Prenons pour exemple la réplication multi-esclaves (un serveur principal localisé à Paris et d’autres répartis dans le monde, répliquant les données). Celle-ci est complètement intégrée depuis la version 9 de PostgreSQL et permet d’avoir un environnement hautement sécurisé pour des entreprises exigeantes.

PostgreSQL : quelles sont les dernières réticences des DSI ?

Principalement la peur de l’inconnu, des chantiers de migration pouvant être longs et coûteux, ainsi que la formation de collaborateurs capables d’appréhender un nouveau moteur de base de données tel que PostgreSQL.

Tout cela peut sembler insurmontable, d’autant plus que des éditeurs comme IBM ou Oracle ont généralement entretenu la dépendance de leurs clients à leurs technologies propriétaires. Mener une politique de changement est une question de volonté et répond à des objectifs de développement. Le plus compliqué étant de prendre les bonnes décisions.

Une fois la stratégie arrêtée, la méthodologie de migration peut commencer par un POC (Proof Of Concept) afin de tester le processus de migration et appréhender le nouveau moteur sur une application existante.

L’expérience démontre que la migration des données est simple. Le plus gros du travail s’oriente sur la migration des applicatifs qui interrogent la base de données.
Un audit est nécessaire afin d’apprécier la complexité des adaptations à faire. Si l’application est récente, construite sur des technologies Java avec des outils de persistance comme Hibernate, l’adhérence à la base de données est alors faible. Souvent, la migration se résume à un changement de connecteur et à une retouche du code négligeable.
En revanche, d’autres applicatifs développés avec les clients et des langages livrés par l’éditeur lui-même, peuvent nécessiter une réécriture complète. Tout ceci est à évaluer dans un plan de migration et doit être écrit lors de l’audit préalable d’analyse d’impact.

En résumé, le monde des bases de données a pris un nouveau virage et l’hégémonie des grands éditeurs tend à s’effriter avec la venue du moteur PostgreSQL.

 

Besoin d’un accompagnement sur PostgreSQL ? Contactez-nous

 

Cet article vous a plu ?

Inscrivez-vous à notre newsletter pour être alerté de nos prochaines news !



Taggué avec
Partager l'actualité sur

Page Linkedin Cyrès

Facebook

Twitter

11/07/2019 @ 7:29
Comment utiliser son budget innovation en tant que grand groupe ? 🚀

#innovation #dsi #tech #devops

https://t.co/XY7ns1yR3H https://t.co/TDFIJZdmib
cyresgroupe photo
10/16/2019 @ 14:35
👉 Evolution de la cybersécurité
👉 Pratiques frauduleuses
👉 Systèmes de de protection
👉 Quelques bonnes pratiques
✔️ Les premiers éléments de réponses aux questions que vous vous posez sur la #cybersecuritehttps://t.co/8fpEcu7wLg

#cybersecurity #ransomware #cyberattack https://t.co/iR2WT48bRn
cyresgroupe photo