De DBA à Data Ops chez Numberly

DBA : Un métier qui ne disparaît pas, mais qui évolue

par Vincent Fricotteaux, Data Ops Engineer

Disclaimer : la vision qui est partagée dans cet article correspond à un contexte et un besoin spécifiques qui sont ceux de Numberly pour qui la Data est une valeur centrale. Elle peut très bien ne pas s’appliquer à votre contexte.

La fin d'une ère

C’était inéluctable. Le métier de DBA tel que nous l’avons connu, garant de la maintenance et de l’optimisation de nos infrastructures de données, est aujourd’hui sur le déclin. Bien triste nouvelle, n’est-ce pas ? Est-il pourtant en danger ? Certainement pas.

Bien au contraire, c’est un métier qui trouve de plus en plus son sens avec l’avènement des différents paradigmes de moteurs qui se sont multipliés ces dix dernières années. De l’invariable modèle relationnel, il y a eu l’émergence du NoSQL, véritable capharnaüm d’idées répondant à des besoins spécifiques, et nous parlons aujourd’hui de New SQL, sorte de moteur pour les gouverner tous. L’environnement aussi a changé, la data est devenue une matière première très convoitée, portant un besoin de législation (vis-à-vis du RGPD) et de gestion de qualité.

Devant un tel paysage, difficile de se passer du chef d’orchestre que représente notre cher DBA. Pourtant il faut adopter un œil nouveau sur la fonction, et les objectifs qu’il doit atteindre.

En effet, les enjeux ont évolué. La donnée est devenue une valeur centrale dans les métiers techniques, et la manière de la servir change avec le temps et les nouvelles technologies. Doit-on servir de la donnée sur ScyllaDB comme on le ferait sur PostgreSQL ? Certainement pas. Doit-on être en plus des experts Neo4j et Elasticsearch lorsqu’on est DBA ? Très peu peuvent vraiment s’en vanter. Alors qu’est devenu le DBA, s’il n’est plus l’expert pointilleux sur sa techno de prédilection ?

De DBA à Data Ops chez Numberly

Voici la réponse que nous avons décidé d’apporter chez Numberly. Le poste de DBA, garant de l’intégrité et de l’accès sécurisé à des données hautement disponibles, a muté vers une fonction plus globale de ce que nous appelons Data Ops : la rencontre entre les méthodologies de développement agiles et les besoins d’administration d’infrastructures de données, dans la lignée des mouvances “Ops” (Dev Ops, Net Ops, etc. décrits à cette adresse) qui ont émergé ces dernières années.

Il y a en effet une convergence qui se fait entre le besoin d’automatiser la maintenance des moteurs de base de données et le besoin de s’appuyer sur des outils d’automatisation et d’industrialisation tels que le font les équipes Dev Ops.

Avec l’arrivée d’outils comme Gitlab, Ansible et Terraform, et des méthodologies de déploiements agiles comme la CI/CD, ce mouvement fait totalement sens et nous disposons des moyens nécessaires à sa réalisation !
Le mindset a alors évolué. La gestion des infrastructures de bases de données ne passe plus par des outils propriétaires, mais par du code. Python a remplacé toutes les briques spécifiques pour amener une vision convergée de la méthodologie d’administration.

Vous cherchez les scripts de sauvegardes ? Ce sont des cronjobs sur Kubernetes. Vous souhaitez installer une nouvelle instance de votre moteur ? C’est vers Ansible qu’il faut se tourner.

Vous l’aurez compris, “l’infrastructure as code” est entrée dans le quotidien du DBA, faisant écho aux besoins des équipes infra et Dev Ops, apportant ainsi une manière fluide de travailler.

La vision Dev Ops appliquée au travail de Data Ops

Afin de mieux comprendre en quoi cette vision offre de nouvelles possibilités, nous vous proposons de l’illustrer par un cas très concret.

Chez Numberly nous gérons plusieurs modèles de bases de données. Ces modèles existent sur plusieurs bases au même moment, et il est de notre responsabilité de s’assurer que ces modèles soient cohérents entre eux. Pour encore complexifier le sujet, ces modèles doivent être portés par des moteurs aux paradigmes différents.

Il a alors fallu imaginer une solution pour assurer une convergence dans nos méthodes de déploiement sans s’enfermer dans les spécificités de tel ou tel moteur de base de données.

Afin de répondre à ce besoin, il faut donc une vision DBA (sécurité, accessibilité, etc.) et une vision Dev Ops (déploiements automatisés, centralisation, versioning, etc.). Le métier de Data Ops représente alors l’addition de ces deux sensibilités.

Nous avons imaginé une solution qui s’appuie sur les forces de Gitlab pour centraliser les demandes de développements de modèles, sécurisant ainsi les accès directs aux objets modifiés, tout en tirant l’avantage de Git pour la traçabilité des modifications apportées et de la CI/CD pour automatiser le déploiement de ces modèles sur les bases cibles. Grâce à Python et les infinies possibilités que ce langage comprend, on peut donc délivrer ces modèles sur n’importe quel moteur de base de données de manière unifiée.

Tout ceci mis ensemble apporte une vision déclarative, centralisée et commune pour toutes les équipes qui travaillent sur la Data !

“Database Octopus”, notre solution centralisée de gestion de modèles

 

Avec ces outils, la fonction de DBA a donc plus que jamais son sens. Ils apportent des réponses à des questions parfois laissées en suspens, permettent de nouvelles méthodologies de travail, et amènent une manière convergente de travailler avec les autres équipes techniques.

De DBA à Data Ops il n’y a qu’un pas

Tout ceci soulève une question : quelle est la démarche pour avancer vers une fonction de “Data Ops”, et quels sont les outils ?

Ce qui va vraiment vous amener à reconsidérer la fonction de DBA, ce sera bien souvent la volumétrie. On ne traite pas quelques giga octets sur un moteur relationnel comme on gère un parc de plusieurs péta octets répartis sur plusieurs technologies distinctes, géo distribuées, redondées, shardées, etc. C’est à ce moment qu’il faut se poser la question : comment industrialiser et automatiser tout ce parc pour qu’il devienne humainement gérable et observable ? Et la réponse se trouve bien souvent dans le code.

Voici quelques outils qui vous permettront de remettre en question votre environnement de DBA :

  • Python pour le code, il est très riche en modules et porté sur tous les environnements
  • La suite GitLab est un ensemble d’outils très puissants. Au-delà de la gestion de version que Git vous apporte, vous y trouverez des solutions de déploiements automatisés (CI/CD), une manière de travailler centralisée et beaucoup d’autres fonctionnalités encore pour la gestion de projet.
  • Kubernetes et Docker sont de fabuleux alliés dans le déploiement et l’hébergement de fonctionnalités que vous concevez.

Cette liste n’est bien évidemment pas exhaustive, mais elle permet déjà de se faire une idée sur les outils qui accompagnent le quotidien d’un Data Ops.

Rejoignez nos équipes