Les bases de données sont un élément important chez monday.com, et en fait dans la plupart des entreprises qui travaillent avec et gèrent des données. Maintenir les bases de données en état de fonctionnement, tout en maintenant de bonnes performances et en aidant les développeurs lors de la création de nouvelles fonctionnalités ou de nouveaux systèmes, nécessite des professionnels qui connaissent et comprennent le mieux la base de données. Traditionnellement, il s’agissait d’administrateurs de bases de données.
Le monde change et être administrateur de bases de données n’est plus « cool ». Mais si je suis plus sérieux, la profession d’administrateur de bases de données a commencé à changer à mesure que les entreprises ont modifié leur façon de développer leurs produits, de les gérer et de se développer.
Du monolithe aux microservices
monday.com, comme beaucoup d’autres entreprises, a commencé avec un seul grand service qui faisait pratiquement tout (appelé monolithe). Au fil du temps, l’entreprise s’est développée, de plus en plus de développeurs ont rejoint l’entreprise et ont créé de nouvelles équipes. Le développement et le déploiement rapides sont devenus un véritable défi, tout comme la maintenance d’une grande base de code. Cela nous a poussés à passer (comme beaucoup d’autres entreprises) à une architecture de microservices.
L’architecture des microservices décompose tout ce qui se trouve dans l’application en éléments plus petits, gérés par différentes applications (et bases de données si nécessaire). Elle permet un développement et un déploiement beaucoup plus rapides, réduit les dépendances entre les équipes et constitue le seul moyen de suivre le rythme requis. Mais en quoi consiste ce développement rapide ? Juste pour vous donner quelques chiffres, nous déployons actuellement environ une fois par jour sur notre monolithe (qui ne contient désormais que des parties spécifiques de l’application), alors que le nombre total de déploiements de microservices est d’environ 30 à 60 fois par jour. Cela n’aurait jamais pu être fait sur une seule application monolithique.
Quel est le rapport avec les bases de données ?
Dans le monde du cloud computing et du DevOps, il existe une expression qui dit que nous devons traiter nos serveurs comme du bétail et non comme des animaux de compagnie. Le concept est que nous ne traitons pas chaque serveur comme un animal de compagnie (je me souviens d’une époque où chaque serveur avait un nom spécial et je me souvenais des noms, des adresses IP et d’autres informations sur chaque serveur). Aujourd’hui, avec le nombre croissant de serveurs (et principalement de serveurs sans état), nous voulons les traiter comme du bétail. Nous voulons les gérer comme un groupe de serveurs avec un rôle et des caractéristiques spécifiques, mais nous ne pouvons pas réellement prendre soin ou gérer chacun d’eux individuellement.
Dans le monde des bases de données, c’est un peu plus complexe, alors que Kubernetes et les applications peuvent facilement être sans état, les bases de données sont toujours avec état et ont des caractéristiques uniques. Cependant, la gestion de centaines de bases de données (nous avons actuellement plus de 200 bases de données relationnelles, y compris des répliques en lecture, plus quelques bases de données NoSQL, et nous en créons sans cesse de nouvelles) ne peut plus non plus être effectuée comme des animaux de compagnie. Et l’administrateur de base de données traditionnel n’a pas les outils pour les gérer comme nous le faisions par le passé.
Entrez DBRE
DBRE signifie DataBase Reliability Engineer, et c’est exactement la profession qui vient résoudre ces défis. Les principaux concepts sont similaires à ceux des DevOps : automatisation, libre-service, disponibilité, performance, surveillance, etc.
Je ne vais pas m’étendre sur ces points ici, mais si vous pensez à une petite équipe gérant un grand nombre de bases de données, vous pouvez voir que cela ne peut pas se faire de la manière traditionnelle, en se connectant à chaque serveur pour effectuer des opérations, ou même en écrivant des scripts pour faire ces choses. Nous devons voir les choses en grand ! L’automatisation ne se résume pas à un simple script que nous écrivons pour nous aider à effectuer une opération spécifique. C’est quelque chose que nous devons gérer en équipe, améliorer au fil du temps, et cela devrait nous apporter beaucoup de choses merveilleuses.
Les administrateurs de bases de données écrivent désormais davantage de code, et pas seulement de petits scripts Bash, mais des projets beaucoup plus importants (qui devraient être gérés dans un référentiel comme tout autre projet de codage). Dans ce cadre, nous souhaitons également proposer des options de libre-service. Si nous avons des microservices qui apparaissent tout le temps, pourquoi devrions-nous créer toutes les bases de données pour eux ? Nous devrions avoir un code d’infrastructure qui le créera pour nous avec les normes et la configuration exactes que nous souhaitons. Et si nous disposons d’un tel outil, pourquoi ne pas le proposer aux développeurs afin qu’ils puissent l’exécuter ?
Et maintenant, qu’en est-il des mises à niveau ? C’est pareil. Si nous avons une procédure standard pour les mises à niveau, automatisons-la. Et une fois qu’elle est automatisée, exposons-la comme une option en libre-service et laissons la responsabilité aux développeurs (ou au support, aux opérations, ou à qui que ce soit d’autre).
Des scripts de diagnostic ? Des alertes ? Autre chose que nous faisons régulièrement ? Tout cela revient au même et devrait être ajouté à notre boîte à outils.
Notre équipe
Notre équipe est responsable de toutes les bases de données des microservices qui composent le service monday.com. Dans le passé, l’équipe s’appelait « ingénieur de données » et avant cela, DBA. Mais DBA (comme je l’ai expliqué) ne représente pas tout ce que nous faisons, et nous ne sommes certainement pas des ingénieurs de données. DBRE est le rôle que nous assumons actuellement, même si nous n’en sommes pas encore là. Nous écrivons plus de code, plus d’automatisations et nous essayons de créer plus de solutions et nous en exposerons autant que possible en libre-service à l’avenir. Cette transition n’est ni facile ni rapide, mais elle est très stimulante et intéressante.
Ma préoccupation
Avec tous ces changements, j’ai une inquiétude. Au cours de mes 20 ans d’expérience en tant que consultant, j’ai vu de nombreux rôles changer et celui qui m’a le plus déçu a été la disparition des administrateurs système. Par le passé, de nombreuses entreprises disposaient de serveurs physiques et de salles de serveurs, et avaient donc des administrateurs système Linux/UNIX qui connaissaient les moindres détails du système d’exploitation. Avec le passage au cloud et à DevOps, il semble que ces connaissances se soient quelque peu perdues. J’ai vu des entreprises dans mon passé qui ont perdu ces connaissances et, si quelque chose se produisait ou si un serveur se comportait mal, elles en créaient simplement un nouveau pour le remplacer. C’est intéressant d’un point de vue opérationnel, mais des connaissances précieuses ont été perdues.
Avec le passage généralisé à DBRE dans le monde, j’espère que la même perte ne se reproduira pas. La connaissance approfondie des bases de données doit rester, avec des personnes comprenant les structures internes, le comportement et les mécanismes de la base de données, afin que nous puissions toujours comprendre ce qui se passe et résoudre les problèmes parce que nous les comprenons, et non pas simplement en changeant la classe du serveur ou en ajoutant une nouvelle réplique.
Et avec cela, je ferai de mon mieux pour continuer à comprendre et à rechercher comment les choses fonctionnent, et je continuerai à me mettre au défi, ainsi que l’équipe, de préserver les connaissances que nous avons acquises en tant qu’administrateurs de bases de données « à l’ancienne » alors que nous effectuons la transition vers les DBRE.