Dans l’article « L’économie des bases de données multicloud », nous avons examiné les arguments financiers en faveur de la répartition des charges de travail des bases de données entre AWS, Azure et Google Cloud Platform (GCP) : d’où proviennent les économies, pourquoi éviter la dépendance vis-à-vis d’un fournisseur revêt une réelle importance économique, et comment les frais de sortie de données et les coûts opérationnels peuvent discrètement annuler ces économies s’ils ne sont pas maîtrisés. Cet article démontrait que le multicloud constitue une véritable option stratégique, et non une bonne pratique universelle, et qu’il n’est réellement rentable que lorsqu'il fait l'objet d'une gestion active plutôt que laissé à lui-même jusqu’à ce qu’il prenne de l’ampleur de façon non planifiée.
Cet article fait suite au précédent. Si les arguments économiques sont convaincants, la question suivante est d’ordre opérationnel : comment gérer au quotidien un parc de bases de données multicloud sans que la complexité ne finisse par absorber les économies réalisées ? De plus en plus d'organisations exploitent désormais des bases de données chez plusieurs fournisseurs cloud, souvent AWS, Azure et Google Cloud Platform (GCP) simultanément. Parfois, ce choix est délibéré et s'inscrit dans une stratégie de résilience. Plus souvent, il résulte d'une accumulation progressive : une équipe standardise ses opérations sur AWS RDS pour un projet, une autre déploie Azure SQL Database pour une nouvelle application, tandis qu'une équipe de data science s'appuie sur BigQuery ou Cloud SQL parce que ces solutions s'intègrent à ses outils. Dans tous les cas, le résultat est le même : un parc de bases de données réparti sur trois consoles différentes, trois modèles de facturation distincts et trois ensembles de particularités opérationnelles différentes.
Pourquoi les équipes optent-elles pour le multicloud ?
Les raisons sont rarement aléatoires. Éviter la dépendance vis-à-vis d’un fournisseur unique est une motivation fréquente : répartir les charges de travail entre plusieurs fournisseurs réduit la dépendance à l'égard des changements de tarification ou des interruptions de service d’un fournisseur donné. Les exigences réglementaires et celles relatives à la localisation des données orientent certaines charges de travail vers les régions spécifiques d'un fournisseur donné. Les fusions et acquisitions entraînent souvent la reprise des choix d’infrastructure effectués par une autre entreprise. Enfin, dans certains cas, les équipes choisissent tout simplement l'outil le plus adapté à leurs besoins : Azure pour ses intégrations avec l'écosystème d'entreprise Microsoft, GCP pour ses capacités d'analyse et de machine learning, ou encore AWS pour la diversité de ses options de bases de données gérées.
Les coûts réels de la fragmentation
Si les avantages sont bien réels, les coûts le sont tout autant et se manifestent généralement à trois niveaux :
- La charge opérationnelle. Chaque fournisseur de cloud dispose de sa propre console de gestion, de sa propre syntaxe CLI et de ses particularités en matière de gestion des sauvegardes, de la réplication et de mise à l'échelle. Les ingénieurs doivent constamment changer d'interface pour effectuer des tâches courantes, et ce coût lié au changement de contexte finit par peser lourd sur l'ensemble de l'équipe.
- Le manque de vision d'ensemble. Lorsque les données de performance des bases de données, les journaux de requêtes et la documentation des schémas sont répartis dans trois silos distincts, obtenir une vue d'ensemble unifiée de l'ensemble du parc devient une tâche manuelle source d'erreurs, souvent réalisée a posteriori à l'aide de feuilles de calcul.
- La duplication des compétences et des outils. Les équipes ont souvent besoin de collaborateurs maîtrisant les produits de plusieurs fournisseurs, ou bien elles finissent par développer des scripts et des processus redondants pour des tâches conceptuellement identiques mais mises en œuvre différemment selon le cloud utilisé.
Pris individuellement, aucun de ces coûts n’est rédhibitoire. Mais ensemble, ils réduisent progressivement les gains de coût et d’agilité qui avaient initialement motivé l’adoption d’une approche multicloud.
Gérer la complexité grâce à une couche unifiée
Le dénominateur commun de ces écueils est la fragmentation ; la solution pratique consiste à mettre en place une couche de gestion qui se superpose aux consoles cloud individuelles sans pour autant les remplacer. C'est ici qu'un outil comme Navicat Premium trouve toute sa place dans une stratégie multicloud.
Navicat Premium permet de se connecter aux bases de données des trois principaux fournisseurs depuis une application unique — notamment Amazon RDS, Aurora et Redshift sur AWS ; Azure SQL Database et Azure Cosmos DB for MongoDB sur Azure ; ainsi que Google Cloud SQL sur GCP. Il prend également en charge les instances locales de MySQL, PostgreSQL, SQL Server, Oracle, MongoDB et d'autres moteurs. Les connexions peuvent être sécurisées via un tunnel SSH, HTTP/HTTPS ou SSL, quel que soit le fournisseur cloud hébergeant la base de données distante.
Pour une équipe multicloud, l’intérêt pratique ne réside pas seulement dans l’étendue des moteurs pris en charge, mais aussi dans la cohérence. Un administrateur de bases de données qui rédige une requête, compare des schémas ou exécute une synchronisation de données n’a pas besoin de réapprendre le flux de travail pour la console de chaque fournisseur ; l’interface, l’éditeur de requêtes et le concepteur d’objets se comportent de la même manière, que la cible soit une base de données AWS, Azure ou GCP. Navicat permet également de synchroniser les profils de connexion, les modèles et les requêtes enregistrées avec un service de collaboration basé sur le cloud. Ainsi, une équipe distribuée travaillant sur plusieurs fournisseurs peut partager ses configurations plutôt que de devoir les recréer individuellement pour chaque membre.
Démarrer sans viser trop haut
Les équipes qui envisagent de mettre en place une couche de gestion unifiée n'ont pas besoin d'effectuer de migration pour l'adopter ; la valeur ajoutée réside dans la connexion des bases de données existantes, telles quelles. Une bonne approche consiste à commencer par recenser les bases de données existantes chez chaque fournisseur, puis à les regrouper sous une interface unique pour les requêtes quotidiennes, la surveillance et la comparaison des schémas, avant de s’attaquer à des problèmes plus complexes tels que la synchronisation des données entre les clouds ou la planification de la reprise après un sinistre.
