Cinq risques liés au déplacement de votre base de données vers le cloud

Passer au cloud fait fureur. Selon un sondage IDC Spotlight, Expérience dans la migration de bases de données vers le cloud, 63 % des entreprises migrent activement leurs bases de données vers le cloud, et 29 % envisagent de le faire dans les trois prochaines années.

Cet article traite de certains des risques que les clients peuvent involontairement rencontrer lors du déplacement de leur base de données vers une base de données en tant que service (DBaaS) dans le cloud, en particulier lorsque la DBaaS exploite un logiciel de base de données open source tel qu’Apache Cassandra, MariaDB, MySQL, Postgres ou Redis. . Chez EDB, nous classons ces risques en cinq catégories : support, service, stagnation technologique, coût et blocage. Le passage au cloud sans une diligence suffisante et une atténuation des risques peut entraîner des dépassements de coûts et des retards de projet importants et, plus important encore, peut signifier que les entreprises ne tirent pas les avantages commerciaux attendus de la migration vers le cloud.

Étant donné qu’EDB se concentre sur la base de données Postgres, je tirerai les détails de nos expériences avec les services Postgres, mais les conclusions sont également valables pour d’autres services de base de données open source.

Prise en charge du risque. Les clients exécutant des logiciels pour des applications de production ont besoin d’assistance, qu’ils s’exécutent dans le cloud ou sur site. La prise en charge des logiciels d’entreprise doit couvrir deux aspects : des conseils d’experts sur la manière d’utiliser correctement le produit, en particulier dans des circonstances difficiles, et la résolution rapide des bogues et des défauts qui ont un impact sur la production ou le passage en production.

Pour les logiciels commerciaux, un niveau minimal de support est fourni avec la licence. Les bases de données open source ne sont pas livrées avec une licence. Cela ouvre la porte à un fournisseur de base de données cloud pour créer et exploiter un service de base de données sans investir suffisamment dans la communauté open source pour résoudre les bogues et fournir une assistance.

Les clients peuvent évaluer la capacité d’un fournisseur de base de données cloud à prendre en charge leur migration vers le cloud en consultant les notes de version du logiciel open source et en identifiant les membres de l’équipe qui participent activement au projet. Par exemple, pour Postgres, les notes de version sont disponible gratuitement, et ils nomment chaque personne qui a contribué à de nouvelles fonctionnalités ou à des corrections de bogues. D’autres communautés open source suivent des pratiques similaires.

Les fournisseurs de bases de données cloud open source qui ne sont pas activement impliqués dans le processus de développement et de correction des bogues ne peuvent pas fournir les deux aspects de l’assistance (conseils et réponse rapide aux problèmes), ce qui présente un risque important pour la migration vers le cloud.

Risque de service. Les bases de données sont des produits logiciels complexes. De nombreux utilisateurs ont besoin de conseils d’experts et d’une assistance pratique pour configurer correctement les bases de données afin d’obtenir des performances optimales et une haute disponibilité, en particulier lors du passage de déploiements sur site familiers au cloud. Les fournisseurs de bases de données cloud qui n’offrent pas de services professionnels consultatifs et experts pour faciliter cette transition introduisent des risques dans le processus. Ces fournisseurs demandent au client d’assumer les responsabilités d’un entrepreneur général et d’assurer la coordination entre le fournisseur DBaaS et les fournisseurs de services professionnels potentiels. Au lieu d’une seule entité qu’ils peuvent consulter pour les aider à réaliser un déploiement transparent avec les niveaux de performance et de disponibilité requis, ils se retrouvent pris au milieu, devant coordonner et atténuer les problèmes entre les fournisseurs.

Les clients peuvent réduire ce risque en s’assurant qu’ils comprennent clairement qui est responsable de la réussite globale de leur déploiement, et que cette entité est effectivement en mesure d’exécuter l’ensemble du projet avec succès.

Risque de stagnation technologique. Le modèle de responsabilité partagée est un élément clé d’un DBaaS. Pendant que l’utilisateur gère la définition du schéma et le réglage des requêtes, le fournisseur de base de données cloud applique les mises à jour de version mineures et les mises à niveau de version majeures. Tous les fournisseurs ne s’engagent pas à effectuer la mise à niveau en temps opportun, et certains peuvent accuser un retard important. Au moment d’écrire ces lignes, l’un des principaux fournisseurs Postgres DBaaS est en retard de près de trois ans sur la communauté open source dans son déploiement des versions Postgres. Alors que les fournisseurs de DBaaS peuvent rétroporter de manière sélective les correctifs de sécurité, une application retardée des nouvelles versions peut mettre les clients dans une situation où ils manquent de nouvelles fonctionnalités de base de données, parfois pendant des années. Les clients doivent inspecter les antécédents d’un fournisseur en matière d’application de mises à niveau pour évaluer cette exposition.

Un risque similaire est introduit lorsqu’un fournisseur de base de données cloud propriétaire tente de créer son propre fork ou sa propre version d’un logiciel open source bien connu. Parfois, cela est fait pour optimiser le logiciel pour l’environnement cloud ou pour répondre aux restrictions de licence. Les versions fourchues peuvent s’écarter considérablement de la version parente la plus connue ou prendre du retard par rapport à la version open source. Des exemples bien connus de ces forks ou versions propriétaires sont Aurora Postgres (un dérivé de Postgres), Amazon DocumentDB (avec compatibilité MongoDB) et Amazon OpenSearch Service (initialement dérivé d’Elasticsearch).

Les utilisateurs doivent être prudents lorsqu’ils adoptent des versions ou des forks spécifiques au cloud de logiciels open source. Les capacités peuvent varier au fil du temps, et le fournisseur de base de données cloud peut ou non adopter les nouvelles capacités de la version open source.

Risque de coût. Les principaux services de base de données cloud n’ont pas connu d’augmentations de prix directes significatives. Cependant, on comprend de plus en plus que la nature des services cloud peut entraîner un risque de coût important, en particulier dans le cas du libre-service et de l’élasticité rapide combinée à un modèle de coût non transparent. Dans les environnements sur site, les administrateurs de base de données (DBA) et les développeurs doivent optimiser le code pour obtenir des performances avec le matériel disponible. Dans le cloud, il peut être beaucoup plus rapide de demander au fournisseur de cloud d’augmenter les opérations d’entrée/sortie provisionnées par seconde (IOPS), le calcul ou la mémoire pour optimiser les performances. Étant donné que chaque instance d’augmentation augmente les coûts, une telle solution à court terme est susceptible d’avoir des impacts négatifs à long terme sur les coûts.

Les utilisateurs atténuent le risque de coût de deux manières : (1) une surveillance étroite des augmentations d’IOPS, de CPU et de mémoire pour s’assurer qu’elles sont équilibrées par rapport au coût d’optimisation des applications ; (2) examen minutieux des modèles de coûts des fournisseurs de DBaaS pour identifier et éviter les fournisseurs avec des modèles de coûts complexes et imprévisibles.

Risque de blocage. Les services de base de données cloud peuvent créer un effet « Hotel California », où les données ne peuvent plus facilement quitter le cloud, de plusieurs manières. Tandis que le coût de sortie des données est souvent mentionné, la gravité générale des données et l’intégration avec d’autres outils spécifiques au cloud pour la gestion et l’analyse des données ont plus d’impact. Gravité des données est un concept complexe qui, à un niveau élevé, prétend qu’une fois qu’un ensemble de données d’entreprise est disponible sur une plate-forme cloud, davantage d’applications seront probablement déployées à l’aide des données sur cette plate-forme, ce qui rend moins probable que les données puissent être déménagé ailleurs sans impact commercial significatif.

Les outils spécifiques au cloud sont également un facteur significatif de verrouillage. Toutes les plates-formes cloud fournissent des outils de gestion et d’analyse de données pratiques et exclusifs. Bien qu’ils aident à générer rapidement de la valeur commerciale, ils créent également un verrouillage.

Les utilisateurs peuvent atténuer l’effet de verrouillage du cloud en évitant soigneusement l’utilisation d’outils cloud propriétaires et en s’assurant qu’ils n’utilisent que des solutions DBaaS qui prennent en charge une réplication efficace des données vers d’autres clouds.

Planification du risque. Déplacer des bases de données vers le cloud est sans aucun doute une cible pour de nombreuses organisations, mais cela n’est pas sans risque. Les entreprises doivent enquêter et comprendre pleinement les faiblesses potentielles des fournisseurs de bases de données cloud dans les domaines de l’assistance, des services, de la stagnation technologique, des coûts et du verrouillage. Bien que ces risques ne soient pas une raison pour éviter le cloud, il est important de les traiter dès le départ, de les comprendre et de les atténuer dans le cadre d’une stratégie de migration vers le cloud soigneusement réfléchie.

Ce contenu a été produit par EDB. Il n’a pas été rédigé par la rédaction de MIT Technology Review.