La migration vers Aurora est devenue beaucoup plus facile

  • FrançaisFrançais



  • Sponsorisé Le déplacement de votre base de données propriétaire sur site vers le cloud rend votre infrastructure plus flexible. Le passage à une base de données gérée open source dont le fournisseur de services cloud s’occupe pour vous permet également à votre DBA d’économiser une tonne de travail à long terme.

    À court terme, cependant, ce dernier implique de soulever des charges lourdes. Qu’en est-il de tous les schémas et codes transactionnels existants dans votre installation existante ? La transition de tout cela vers un nouveau format dans le cloud demande beaucoup de travail.

    Jusqu’à présent, cela aurait pu faire réfléchir les développeurs et les administrateurs de base de données lorsqu’ils envisageaient une transition vers Aurora, la base de données relationnelle native du cloud d’Amazon Web Service. Développé à partir de zéro avec le cloud à l’esprit, le service offre de nombreux avantages, notamment une haute disponibilité par défaut, une flexibilité et un fonctionnement simple sans licence.

    Le géant du cloud propose déjà son service de migration de base de données (DMS) pour aider à la transition, y compris un outil qui facilite la tâche de conversion des schémas entre les bases de données sur site et gérées. Maintenant, il s’attend à ce qu’un nouveau service appelé Babelfish rende le processus beaucoup plus facile. Il offre une traduction simple à la volée entre Microsoft SQL Server (MSSQL) et l’implémentation open source PostgreSQL d’Aurora.

    Le résultat, un peu comme le poisson Babel dans The Hitchhiker’s Guide to the Galaxy de Douglas Adams, est qu’une application qui parle MSSQL peut se faire comprendre à Aurora, et vice versa. Cela devrait éviter bien des maux de tête.

    Maux de tête de migration d’applications

    L’outil de migration de schéma d’Amazon simplifie la migration d’une base de données d’un système sur site vers Aurora. Cependant, les développeurs d’applications doivent faire face à des différences subtiles lors de la migration de leur code entre différentes versions de bases de données relationnelles, telles que PostgresQL et MSSQL. Par exemple, les types de données peuvent varier de manière subtile entre PostgreSQL et MSSQL, même s’ils ont le même nom. En effet, les fournisseurs développent souvent leurs types de données pour dépasser les normes ANSI afin de pouvoir offrir plus de fonctionnalités à leurs clients.

    Un programmeur travaillant avec le type de données Money dans MSSQL rencontrera des problèmes lors de la migration vers PostgreSQL. Dans la base de données de Microsoft, il a une précision à quatre chiffres. Dans Postgres, il n’en a que deux. Cela peut introduire des changements dans le fonctionnement des applications qui pourraient ne pas toujours apparaître sans des tests approfondis. Certains types de données qui existent dans une base de données peuvent ne pas exister du tout dans d’autres, ce qui nécessite un travail de refactorisation sérieux du côté de l’application.

    Un autre problème surgit avec la sémantique transactionnelle. MSSQL gère certaines transactions différemment de Postgres. Le premier examinera tous les enregistrements pour les clés uniques lors du chargement de toutes les données dans une table et ignorera les doublons. PostgreSQL est moins indulgent et échouera complètement l’opération de chargement s’il découvre des enregistrements en double. Cela peut affecter le comportement de l’application.

    Les développeurs rencontreront également rapidement des problèmes avec la syntaxe du langage dans leur base de données. Chacun a sa propre variante de langage qui varie souvent de la vanille SQL. Le dialecte TSQL de Microsoft est différent de PostgreSQL, qui propose son propre langage PL/pgSQL. Ces deux langages sont des langages procéduraux, y compris des constructions qui permettent à la base de données de renvoyer des types de données complexes, mais ils incluent des primitives de langage différentes.

    Les développeurs utilisent généralement des outils de conversion de syntaxe pour gérer ce problème, en générant automatiquement du code pour combler le fossé entre la langue d’une base de données et une autre. Cela a des inconvénients, cependant. Cela rend le code difficile à lire, surtout s’il a déjà été généré automatiquement par un outil de gestion relationnelle objet (ORM). Cela rend le code difficile à vérifier, surtout si le codeur d’origine n’est plus là. De plus, cela pourrait enfreindre les spécifications de codage existantes d’une organisation.

    Une autre façon de résoudre tout ce gâchis enchevêtré consiste à repenser les choses du côté des applications. C’est une grande entreprise, cependant, impliquant des réécritures et des tests de systèmes déjà en production qui pourraient avoir plusieurs dépendances. Ce ne serait pas si mal si vous travailliez avec un environnement modulaire basé sur des microservices, mais les entreprises migrant vers Aurora n’en seront pas encore à ce stade et travailleront avec des applications monolithiques traditionnelles.

    Réduire les frictions dans le processus de migration de la base de données

    Amazon a fait de son mieux pour faciliter ce processus de migration avec le DMS et l’outil de conversion de schéma (SCT). Une fois que le client a choisi une application à migrer, le DMS aide à transférer l’application telle quelle dans une version qui peut communiquer avec Aurora. AWS utilise son SCT pour analyser le code d’accès à la base de données héritée et estimer le temps qu’il faudra pour le migrer vers l’environnement Aurora, ce qui laisse plus de temps pour les complexités telles que les procédures stockées. Si vous avez des incompatibilités entre votre code de base de données propriétaire et la base de données open source, la société mettra à votre disposition des experts pour vous consulter.

    Babelfish est la tentative de l’entreprise de rationaliser et d’améliorer ce processus afin de faciliter la migration pour les clients. C’est une capacité d’Aurora qui s’occupe automatiquement de la traduction entre MSSQL et PostgreSQL, gère les conversions de types de données appropriées et prend en charge les primitives du langage MSSQL lors de la communication avec Aurora.

    Votre application MSSQL pense toujours qu’elle parle à la base de données de Microsoft, mais vous l’avez pointée vers un serveur Babelfish, qui traduit ses commandes pour Aurora. Amazon affirme que cela réduira le temps de développement pour les clients faisant le saut vers sa base de données cloud relationnelle gérée.

    En pratique, il y aura souvent du travail à faire en amont. Vous devez déterminer les types de données que votre application utilise, puis vous assurer que les extensions appropriées sont installées sur le serveur Babelfish.

    Murali Brahmadesam, directeur du logiciel pour Aurora chez Amazon, promet de sérieux avantages à Babelfish. Le système permet aux développeurs d’utiliser des objets MSSQL via l’interface PostgreSQL, ce qui facilite le déploiement d’applications existantes tout en conservant la majeure partie du code.

    « Babelfish réduira la quantité de code que vous devez réécrire de 90 % ou plus pour la plupart des applications », explique Murali. Cela signifie également que cela réduira les temps de développement des applications, dit-il, permettant aux clients de passer plus rapidement au cloud et éliminant le besoin de modifier les tests de code ou les pilotes clients. « Au lieu de prendre un an pour migrer votre application de SQL Server vers PostgreSQL, vous pouvez le faire en une durée beaucoup plus courte, peut-être un ou deux mois », dit-il.

    Faire la transition avec Babelfish

    Babelfish sera open-source sur GitHub avec une licence Apache 2.0 afin que les entreprises puissent héberger leurs propres versions, mais AWS le proposera également en tant que service géré. La société met à niveau son outil de conversion de schéma pour identifier la quantité de schéma de base de données d’un client pris en charge par Babelfish, et équipera le SCT pour soit apporter des modifications au code de base de données existant automatiquement, soit faire des recommandations à l’équipe de développement. « L’outillage reste le même, mais l’expérience client sera meilleure », déclare Murali.

    L’avantage de se connecter à Babelfish est que les clients bénéficient de la commodité d’une migration lift-and-shift, mais avec les avantages d’une base de données gérée. Ils peuvent passer à un moteur de base de données natif du cloud, mais sans rien modifier dans leur pile d’applications jusqu’à ce qu’ils soient prêts. Vous pouvez même laisser votre application sur site si vous le souhaitez, réduisant ainsi la latence d’accès à l’aide du service Direct Connect d’Amazon, explique Murali.

    La transition accélérée séduira les clients désireux d’échapper aux frais de licence draconiens des bases de données propriétaires sans investir dans un projet de refactorisation majeur, ajoute-t-il.

    « Maintenant, ils ont un contrôle total sur les modifications apportées aux applications dans leur propre calendrier », dit-il. “Ils peuvent continuer à développer en TSQL tout en utilisant Babelfish s’ils le souhaitent, mais avec le temps, ils peuvent passer à pgSQL.”

    Les développeurs peuvent toujours ajouter des fonctionnalités cloud natives du côté d’Aurora. La base de données peut appeler des lambdas sur les insertions d’enregistrements, ce qui permet aux développeurs d’étendre ses fonctionnalités avec des fonctions sans serveur dans le cloud AWS sans modifier leur pile d’applications existante. Ils peuvent effectuer des transactions à l’aide de l’interface de base de données et du schéma auxquels ils sont habitués via le pilote client MSSQL et invoquer des lambdas pour des fonctionnalités supplémentaires du côté Aurora. Murali cite l’intégration avec le service d’apprentissage automatique AWS Sagemaker comme exemple de cas d’utilisation.

    L’outil Babelfish d’Amazon soutiendra les développeurs d’applications qui voient l’intérêt de passer à un moteur de base de données alternatif, mais qui s’inquiètent de la tâche de migrer leur logique métier. Il simplifie le défi d’intégration, réduit les frictions impliquées et laisse les clients mieux préparés à faire le saut.

    Commandité par AWS

    L'équipe de Comparaland

    Rédacteur web depuis 2009 et webmestre depuis 2011.

    Je m'intéresse à tous les sujets comme la politique, la culture, la géopolitique, l'économie ou la technologie. Toute information permettant d'éclairer mon esprit et donc, le vôtre, dans un monde obscur et à la dérive. Je suis l'auteur de plusieurs livre

    Pour me contacter personnellement :

    Laisser un commentaire

    Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *