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

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