La nouvelle façon de gérer les bases de données open source

Il n'y a pas si longtemps, l'industrie des bases de données se composait d'une poignée de fournisseurs. Les bases de données étaient principalement relationnelles et fonctionnaient sur des machines uniques. La haute disponibilité a été mise en œuvre via des «clusters» actifs en veille. Avec un modèle « scale-up » vertical, il s'agissait principalement de stockage partagé (SAN ou DRBD) ou de réplication asynchrone des journaux pour synchroniser l'état avec un nœud de secours. En 2001, lorsque j'ai commencé à travailler avec NDB Cluster (ce qui deviendrait plus tard MySQL Cluster), le concept de conserver une base de données entière dans la mémoire principale était bizarre - "et si vous éteigniez le serveur ?". La distribution d'une base de données sur plusieurs serveurs était inquiétante - "vous avez des morceaux de données ici et là". Et toute l'idée d'une base de données open source pour les charges de travail critiques était risible.

Avance rapide de 15 ans et nous avons maintenant des dizaines de fournisseurs de bases de données sur le marché - principalement open source, différents modèles (valeur clé, document, graphique, ...) et distribués par défaut. Les données résidentes en mémoire sont à peu près la norme pour obtenir des performances élevées et une faible latence. Trois des 5 bases de données les plus populaires (selon le classement db-engines) sont open source (MySQL, PostgreSQL et MongoDB). De nos jours, vous êtes plus susceptible de gérer une flotte de serveurs de bases de données répartis sur différents centres de données. Certaines de vos bases de données peuvent même être gérées par un fournisseur de cloud tiers.

Alors, à quoi ressemble la gestion des bases de données en 2018 ?

AUTOMATISATION

Avec autant de tâches à gérer et seulement tant d'heures dans une journée, on serait fou de faire les choses manuellement.

L'automatisation est un excellent moyen de faire avancer les choses. Lorsque nous avions peu de bases de données à gérer, l'exploitation de la base de données était très pratique, avec certaines tâches scriptées dans quelque chose comme bash ou perl - par exemple, un script pour sauvegarder la base de données, un autre pour déplacer les fichiers de sauvegarde vers un emplacement. Le basculement serait manuel, et nous débattrions même s'il devrait être automatisé ou non.

De nos jours, l'automatisation est une évidence. Il existe un certain nombre de systèmes d'automatisation informatique ou de gestion de la configuration qui peuvent être exploités - Puppet, Chef, Ansible et Salt offrent tous des cadres à usage général qui peuvent être utilisés pour créer une automatisation pour différentes topologies de base de données. Les logiciels de gestion de cluster écrits spécifiquement pour gérer les configurations de base de données incluent MongoDB Ops Manager et ClusterControl. Ils permettent aux équipes opérationnelles de gérer leurs clusters avec quelque chose qui est facilement disponible sur étagère. Construire un système de gestion de cluster à partir de zéro à l'aide d'un système de gestion de configuration n'est pas une mince affaire. Cela nécessite une expertise significative de l'outil d'automatisation ainsi qu'une compréhension des opérations de gestion telles que la planification et la vérification des sauvegardes, le basculement automatique avec reconfiguration ultérieure des systèmes, le déploiement des modifications de configuration, les correctifs, la mise à niveau ou la rétrogradation de version, etc.

Et bien sûr, il y a l'essor des plates-formes de services DBaaS, où le déploiement, la santé, le basculement, les sauvegardes, etc., sont tous contrôlés par des logiciels. Les fournisseurs de cloud sont en effet très doués pour l'automatisation. Amazon RDS est un excellent exemple d'automatisation de base de données à grande échelle :il automatise le déploiement, les mises à niveau des correctifs, les sauvegardes, la restauration ponctuelle, la mise à l'échelle des répliques et la haute disponibilité/le basculement.

ANIMAUX DE COMPAGNIE contre BOVINS

Dans les années 90 et jusqu'à l'essor et l'effondrement des dotcoms, Sun Microsystems et Oracle ont fait fortune en vendant des bases de données évolutives sur du gros matériel SMTP. Ajoutez-y du stockage SAN et un logiciel de basculement Veritas et vous obtiendrez un cluster de basculement de veille actif à la pointe de la technologie pour une haute disponibilité. Les serveurs de base de données étaient relativement peu nombreux, mais puissants car ils se développaient verticalement. Ils ont reçu des noms (comme vous nommez vos animaux de compagnie !) et ont été pris en charge par des DBA.

De nos jours, les bases de données sont bon marché et fonctionnent bien sur du matériel standard. Il y en a beaucoup, et nous leur donnons des numéros - tout comme le bétail. Si l'un se casse, nous pouvons simplement en obtenir un nouveau.

C'est aussi une nouvelle race de bétail - du bétail open source ! Selon db-engines, trois des cinq principales bases de données sont toutes open source - elles rongent lentement mais sûrement la part de marché des deux fournisseurs propriétaires. L'open source est la nouvelle norme de centre de données, non seulement pour le système d'exploitation mais aussi pour les bases de données.

Alors qu'est-ce que cela signifie pour vous? Eh bien, à l'avenir, vous serez plus susceptible de gérer une base de données open source - ou même plusieurs pour des applications utilisant des collections de données hétérogènes. Dans un monde de persistance polyglotte et de microservices, le magasin de données sous-jacent est désormais dicté par la nature des données. D'un point de vue architectural, les bases de données à instance unique avec haute disponibilité sur disque cèdent la place à des clusters potentiellement répartis sur plusieurs centres de données.

Avons-nous besoin d'un DBA ?

Le rôle de DBA est spécialisé - il faut des années d'expérience pour le devenir. Dans le passé, lorsqu'il n'y avait que quelques fournisseurs de bases de données propriétaires parmi lesquels choisir, vous disposiez d'administrateurs de base de données spécialisés dotés d'un ensemble spécifique de compétences et d'expérience. C'était également nécessaire - les bases de données comme Oracle ou SQL Server ont d'énormes ensembles de fonctionnalités, construits au fil des décennies. Ils ne sont pas faciles à gérer. Ils étaient généralement déployés en tant que base de données unique pour une application et devaient être surveillés, les données sauvegardées et tout problème qui se présentait devait être traité. Ces tâches étaient exactement ce sur quoi les DBA devaient se concentrer.

Cependant, au cours de la dernière décennie, une toute nouvelle industrie des bases de données a émergé - avec des dizaines et des dizaines de bases de données open source, ainsi que des services de bases de données cloud. Comme nous l'avons vu précédemment, il n'est pas rare qu'une application utilise plusieurs magasins de données différents. Mais les entreprises disposent rarement d'un DBA pour ces datastores qu'elles utilisent. Où trouvez-vous un DBA MongoDB ou Cassandra ou avec plus de 5 ans d'expérience en production ? On peut affirmer que la nouvelle génération de bases de données NoSQL est beaucoup plus simple que ses prédécesseurs à source fermée, et n'entraînerait donc pas la même courbe d'apprentissage.

Leur gestion ne serait qu'une tâche supplémentaire ajoutée à la liste des tâches de l'équipe SysAdmin ou DevOps ou Site Reliability Engineering (SRE). Et nous constatons aujourd'hui que de nombreuses entreprises n'ont pas de DBA à temps plein. La responsabilité est plutôt répartie entre les équipes, les outils d'automatisation étant de plus en plus utilisés pour s'occuper des tâches quotidiennes de routine. Pour les bases de données qui ont migré vers le cloud, les aspects opérationnels du stockage des données sont entièrement sous-traités au fournisseur de cloud. Ainsi, au lieu de travailler sur la manière de stocker les données, l'équipe des opérations peut désormais se concentrer sur l'utilisation des données.

Cycle de vie de la base de données

Le cycle de vie moyen d'une base de données était beaucoup plus long qu'aujourd'hui. Une fois que vous avez choisi une plate-forme de base de données, c'était tout. La décision serait prise entre deux ou trois bases de données relationnelles, généralement par le DBA ou quelqu'un de plus haut placé dans l'organisation. L'entreprise trouverait l'argent pour acheter des licences perpétuelles. Une fois la décision prise, vous deviez maintenant vivre avec pendant les 10 prochaines années. Les bases de données étaient monolithiques et les applications utilisaient généralement une seule base de données partagée.

Aujourd'hui, dans un monde de conteneurs, de cloud, de microservices et de pipelines CI/CD, il n'est pas rare que les développeurs fassent des choix technologiques - surtout s'il s'agit d'une base de données open source qui peut être facilement téléchargée ou proposée en tant que service, sans avoir à parler à un représentant commercial ou à demander un budget à la direction. Les organisations sont mises au défi de créer de la valeur plus rapidement, de sorte que le taux de modification de l'infrastructure/des applications a considérablement augmenté. Les bases de données monolithiques sont désormais divisées en plusieurs petites bases de données, chaque base de données gérant les données de domaine pour un microservice individuel. Avec la variété de produits de base de données disponibles aujourd'hui dans l'écosystème open source, les équipes ont le choix et la liberté de passer à une meilleure banque de données. Au fur et à mesure que les services sont mis en service et déclassés, les bases de données suivent également - bien que les données elles-mêmes puissent être archivées ou déplacées dans un lac de données. Dans un paysage d'infrastructures beaucoup plus dynamique aujourd'hui, nous constatons que nos bases de données ont une vie plus courte.

RÔLE DBA

Le DBA, traditionnellement à la fois gardien et gardien de la base de données, répondrait aux besoins en base de données des différentes équipes d'application/d'infrastructure de l'organisation. Tout changement nécessitant un accès ou des modifications à la base de données nécessiterait les services du DBA. Cependant, des priorités conflictuelles et le manque de disponibilité de l'administrateur de base de données pourraient signifier que le projet serait bloqué/retardé, et des frictions inévitables s'ensuivraient.

Le coût élevé de la collaboration et l'innovation rapide/le court délai de mise sur le marché ne vont pas bien ensemble. Comme nous l'avons vu précédemment, les microservices sont un exemple de la façon dont l'infrastructure et les services applicatifs sont désormais architecturés de manière à se découpler autant que possible. Les bases de données sont de plus en plus automatisées et le contrôle de la base de données passe aux développeurs ou aux équipes de projet. Même des choses comme les changements de schéma ne sont plus aussi lourdes qu'avant. Ils étaient beaucoup plus durs dans le cadre d'une base de données centrale pour une application monolithique. Les données étant partagées entre différents composants, les modifications de schéma doivent être coordonnées et soigneusement planifiées, généralement des mois à l'avance. Les administrateurs de bases de données ont joué un rôle clé dans la compréhension et l'exécution des changements. La dynamique est différente aujourd'hui, où le taux de changement est beaucoup plus rapide. Il n'est pas rare que les équipes de développement poussent les changements de code en production sur une base hebdomadaire ou quotidienne - ou même plusieurs fois par jour ! Les bases de données ont besoin de mises à jour constantes pour suivre les changements d'application, et celles-ci sont effectuées par les développeurs. Certaines des bases de données les plus récentes comme MongoDB le rendent même très simple en ayant un modèle sans schéma. Cela signifie en fait que le schéma de la base de données se déplace dans le code de l'application.

Donc, si toutes les tâches de base communes sont automatisées, qu'adviendra-t-il du rôle de DBA à l'avenir ? Au lieu de se concentrer sur les tâches administratives, le DBA fonctionnera davantage comme un mentor pour les autres équipes de l'organisation. Les organisations doivent comprendre de quelles données elles disposent et comment ces données peuvent être utilisées. Après tout, les données sont plus précieuses lorsqu'elles sont partagées et combinées avec d'autres ressources, et pas seulement stockées. Schemaless sonne bien, mais nous devons toujours garder une trace de nos données - soit dans la base de données, soit dans le code. La sécurité est un défi et les violations de données ne cessent de s'aggraver. Donc, si nous voulons que les données redeviennent excellentes, le DBA doit passer à un rôle de conseiller/facilitateur horizontal qui s'étend à toutes les équipes. Du point de vue des compétences, le DBA moderne doit comprendre comment concevoir des systèmes distribués à haute disponibilité et mettre en place des systèmes d'automatisation efficaces pour prendre en charge les tâches banales. Alors que les entreprises déploient une infrastructure dans des environnements cloud ou même de conteneurs, comprendre comment créer des bases de données hautement disponibles et évolutives sur ces plates-formes garantira la survie de l'administrateur de base de données.

Résumé

Nous sommes assis à un carrefour fascinant de l'histoire de l'industrie des bases de données, qui a subi une transformation massive au cours des 2 dernières décennies. Le tableau ci-dessous tente de le résumer.

Je serais intéressé d'entendre vos réflexions sur la gestion de base de données open source et si vous avez vu les mêmes tendances ? À quoi ressemblaient vos difficultés ou vos succès avec les OSDB ces dernières années ? Et que prévoyez-vous pour l'année prochaine ?

Chez Plusieursnines, nous continuerons bien sûr à continuer à faciliter la gestion et l'automatisation de vos bases de données open source jusqu'à l'année prochaine et au-delà. Alors restez à l'écoute pour des mises à jour à ce sujet à partir de janvier prochain.

Mais en attendant, faites-moi part de vos impressions et rendez-vous en 2019 !

Photos par SoRad (Shutterstock) et Les Simpson ; les autres photos sont de leurs propriétaires respectifs.