Bruno:
Je ne connais plus aucune stack qui ne contienne qu'une seule techno de bases de données. Avec une production de plus en plus intense de data et des usages de plus en plus spécialisés, les technos de BDD se sont multipliés. Et à mesure de cette diversification, les bases de données deviennent presque des services de back-end à part entière. Nouvelle tendance du marché, les bases de données multichémas. Mais alors, ces bases de données peuvent-elles tout faire ? La base de données devient-elle un back-end réellement complet ? Et surtout, que va-t-il rester au dev back-end ? Pour répondre à ces questions de convergence, je ne reçois pas Kirby, mais il s'y connaît en techno qui se transforme en une autre. Sylvain, bonjour.
Sylvain:
Bonjour Bruno.
Bruno:
Alors Sylvain, est-ce que tu pourrais te présenter pour les quelques personnes qui ne te connaîtraient peut-être pas ?
Sylvain:
Bien sûr, je m'appelle Sylvain Abodi, je suis aujourd'hui architecte base de données et infrastructure autour de la base de données.
Bruno:
Tu as toujours été sur des sujets de base de données ?
Sylvain:
Écoute j'ai fait ma master en école d'ingé sur de l'infrastructure et de l'architecture des SI comprenant la base de données et au final j'ai effectivement travaillé toute ma vie sur les bases de données.
Bruno:
Donc ça veut dire que tu as connu cette explosion qu'on voit maintenant des métiers autour de la data, tu as vu aussi arriver toutes ces différentes nouvelles technos de base de données et compagnie avant de creuser sur, ce sujet que tu m'as vendu de convergence des bases de données, est-ce qu'on peut se faire un petit rétrospectif sur cette ouverture des technos de bases de données qu'il y a eu ?
Sylvain:
Bien sûr, bien sûr. Alors moi, pour situer un peu, j'ai commencé à travailler juste avant l'arrivée d'Oracle 8i. Donc j'étais encore en 7.03. Donc ça date un petit peu. Et à l'époque, il n'y avait pas un passement tiers, il n'y avait principalement que du Oracle sur le marché et un peu de DB2 pour les gros systèmes. Mais fondamentalement, quand on regarde vraiment l'histoire de la base de données au sens large, on a commencé par ce qu'on appelait du NoSQL. Les toutes premières bases de données, c'était un peu vulgairement un fichier séquentiel indexé. Après on est passé sur du VESAM, des trucs un petit peu plus modernes avec différents égarements. Puis est arrivé le modèle relationnel vers les courants des années 70 avec tous les travaux de COI et des compagnies chez IBM. Avec justement la normalisation, le modèle relationnel, les différentes formes normales qui ont été découvertes. Je ne sais pas si découvertes, c'est le bon terme, mais elles ont été formalisées. Et du coup, après, le modèle relationnel a régné en maître et sont réapparus des besoins de stocker de la donnée de manière un peu plus performante, de stocker de la donnée parfois en n'ayant pas forcément besoin du côté transactionnel, en n'ayant pas forcément besoin du côté acide. Donc vraiment que les données ne soient pas totalement durables, ce n'est pas grave si on les perd en cours de route. Donc c'est des besoins qui sont réapparus ou qui sont apparus diront certains, qui ont l'arrivée du premier des mouvements de nos SQL avec les premières, c'était du clé-valeur et document store qui arrivaient assez rapidement derrière, puis après ça en suivit tout un tas d'autres choses, y compris donc les stockages en colonne, les bases données en forme de graphes et ainsi de suite.
Bruno:
Est-ce que pour toi il y a eu du too much ? Est-ce qu'on est allé trop loin ?
Sylvain:
Oui, la réponse est évidemment oui ce qui se passe c'est que le milieu de l'informatique on pourrait croire que comme on travaille dans la tech on est des gens qui avons quand même un certain niveau d'instruction, on pourrait croire que les gens prennent des solutions rationnelles, je pense qu'on est un millier ultra motonnier ça fonctionne à l'hype l'informatique ça fonctionne à l'hype mais quel que soit le niveau, que ce soit au niveau de l'infra, il y a eu l'hype Docker, l'hype Kubernetes il y a eu l'hype NoSQL, il y a eu l'hype à un moment sur, tu avais un framework JavaScript qui sortait toutes les semaines, à chaque fois c'est le dernier truc sorti ça hype tout le monde, faut pas oublier au final quoi qu'on fasse ça reste des outils un outil ça s'utilise à bonnes esions, Et moi, aujourd'hui, je donne un exemple, je ne donnerai pas le nom de la boîte, mais elle a existé. Dans la partie too much, il y a quand même des gens qui se sont imaginés refaire des échelles de compta en MongoDB parce que ça va plus vite. Bon, je ne veux pas être méchant, mais la compta, il n'y a rien de plus normalisé au monde. Il n'y a absolument pas besoin de dénormalisation pour faire de la compta. En plus, la compta, si tu perds une écriture, tu peux aller au tribunal. Donc, l'acidité, ça n'a aucun sens. Pourtant, ça a existé. Il y a clairement du too much il y a des gens qui s'emballent.
Bruno:
Et donc toi tu perçois que les bases de données sont en train de de reconverger c'est quoi le au delà du signal c'est quoi pour toi la nécessité aujourd'hui pour les bases de données de reconverger.
Sylvain:
Alors aujourd'hui pour moi il y a deux nécessités la première nécessité elle est purement économique pour les entreprises pour une entreprise aujourd'hui si vous avez 15 systèmes de bases de données vous êtes obligé d'avoir 15 experts Personne ne peut être expert en 10 systèmes de... C'est pas possible. Moi, j'ai essayé. Ça m'a pris plus de 15 ans de devenir expert sur MariaDB et vaguement expert sur Oracle. Mais c'était il y a tellement longtemps que je le suis plus. C'est impossible. On peut être expert sur 2, 3 secteurs, grand maximum à mon sens, et pas plus. Aujourd'hui, quand on regarde la liste, déjà juste les types de bases de données, en OSQL, NewSQL, modèle relationnel total, on doit être à 15 ou 20 types différents. On ne peut pas être expert dans tout. Or, il y a les entreprises, plus grosses évidemment, elles ont besoin, elles vont utiliser ceci, cela, du colonard, du machin, du document store. Ça veut dire aussi qu'elles sont obligées de multiplier les ressources. Puis après, tu multiplies le ressource, puis tu tombes sur ton SLA parce que tu dois être en 24-24-77, ce qui t'appelle Booking, et tu te retrouves à avoir... T'es obligé d'avoir une équipe d'admin où t'as 200 personnes tellement t'as de système dans tous les sens, et qu'il faut que t'aies une rotation 24-24-77, 365 jours par an. Donc financièrement, c'est pas tenable.
Bruno:
Oui, mais dans cette logique de convergence, on conserve quand même du SQL, du NoSQL, on reste quand même sur des formats de base de données qui sont variés, même si t'as qu'une seule techno. Est-ce que tu peux être expert MariaDB et dresser aussi bien les sujets relationnels que les sujets NoSQL alors.
Sylvain:
À mon sens oui à mon sens oui alors après ça va dépendre, pour MariaDB je peux répondre, après je sais que Guillaume parlait de Postgre qui avait en matière de convergence Postgre je connais beaucoup moins, je connais les grandes lignes de leur fonctionnement, je tends à penser quand même que contrairement à Oracle, Postgre et MariaDB sont des stacks techniques qui sont elles aussi très évolués mais qui sont quand même plus faciles d'accès pour tout le monde, et notamment pour l'administration et je pense que je vois pas de problème majeur aujourd'hui à être un expert MariaDB qui fait à la fois, du NoSQL, du SQL, de la base de données en graph, du stockage colonard c'est pas un énorme problème en soi. Après, Je vais quand même nuancer mon propos. La convergence, c'est bien, mais c'est bien pour des usages assez généraux. Si on a un usage vraiment extrêmement poussé, par exemple, une base de nangrave, vous faites du néo-forgy et vous utilisez vraiment à fond le graphe, il n'est probablement pas possible d'avoir, la qualité de ce que vous trouvez dans ce produit-là sur un produit comme MariaDB avec un moteur de stockage en graphe qui existe au-delà.
Bruno:
C'est un peu comme utiliser du React pour te faire tes applications mobiles, ou utiliser du natif il y a certains contextes ou rester sur du natif c'est plus intéressant.
Sylvain:
Bien sûr justement c'est intéressant que tu dis ça parce que la réflexion que je m'étais faite et la proposition d'épisode elle venait du compilé de Guillaume Rongier et du début de son épisode vous étendez le sujet, mais elle vient aussi du fait que je réécoutais cet épisode après avoir lu un document une étude qui vient du MIT qui a été publiée par Stonebreaker et Pavlo Alors pour ceux qui ne sauraient pas, Stonebreaker c'est un des fondateurs de Postgre.
Bruno:
Il connaît un peu le sujet.
Sylvain:
Il a à son actif 4 moteurs de base de données différents, plus un operating system orienté base de données. Donc le mec, en plus d'être une sommité tout court dans le monde informatique, il sait de quoi il parle quand il parle de base de données. Et justement, il avait fait un papier il y a 15 ans, je crois, où il parlait justement des problématiques de lecture de base de données. Où au passage, il dézinguait MapReduce, parce que quand l'hype s'est répandue, Google l'avait déjà mis à la poubelle. Comme quoi la high tout ça, ça date pas d'aujourd'hui et aujourd'hui il refait une étude qui est un peu un panorama et, il remarque une chose c'est que les bases données il y aura toujours besoin de spécialisation donc un document store un key value, il y aura toujours des utilisations spécifiques il dit pour autant, il remarque qu'au fur et à mesure du temps absolument toutes les bases données ont fini par intégrer des choses qui viennent du modèle relationnel énormément d'entre elles ont amené des transactions il y en a plein qui ont amené de l'acidité il y en a qui ont commencé à amener justement de la structuration en plus, et en fait aujourd'hui il y a un certain nombre de bases qui sont pas des bases données relationnelles au début qu'on peut quasiment utiliser comme des bases données relationnelles aujourd'hui, et sa réflexion en fait dans la, conclusion de son papier. C'est dire ok c'est bon pour l'innovation on aura toujours besoin de centres de produits différents, c'est aussi grâce à ces innovations que le sql s'est enrichi comme le rationnel ce qu'il est aujourd'hui parce que si on n'avait pas eu des documents store aujourd'hui je pense qu'on n'aurait pas gison en natif dans les bases de relationnel ça n'existerait pas tout simplement il dit par contre ce qui est dommage c'est que à chaque fois c'est des choses des moteurs qui sont en dehors alors qu'il ya déjà 10 20 30 40 ans de travail sur des moteurs existants qui sont extensibles et, Ils ne donnent pas d'exemple, mais un Postgre est totalement ouvert au plugin, un Maradb est totalement ouvert au plugin. Oracle, c'est Oracle, donc ils sont ouverts à ce qu'ils font. Donc on n'en parlera pas plus, et SQL Server, c'est la même chose. Mais bon, pour rester sur le monde Postgre et Maradb, c'est des bases qui sont très fortement extensibles, et ce depuis très longtemps. Donc en fait, cette histoire de convergence, elle est déjà en place. Enfin, je veux dire, si on prend Maradb, je vais te donner trois exemples. Il existe un moteur en OSQL il est possible de bypasser la couche SQL pour attaquer directement le stockage en crude, il existe un moteur de stockage en graph et il existe un moteur de stockage en colonne alors le moteur de stockage en graph en colonne sont accessibles par la couche SQL par contre c'est pas un dérivé mais tu vois t'avais déjà une forme de convergence.
Bruno:
Alors j'entends ce que tu dis sur le fait qu'il y a déjà 30 ans de travail sur ces moteurs là On pourrait prendre le vieux dicton qui.
Sylvain:
Dit que.
Bruno:
C'est dans les vieux pots qu'on fait les meilleures soupes, enfin bref, il y a plein de déclinaisons, vous captez l'idée. Est-ce que, malgré tout, tu vois, quand même, dans notre monde de la techno, on sait aussi qu'il y a un moment, il faut savoir jeter un vieux système. Il y a cette plus ou moins légende urbaine comme quoi le cœur des systèmes financiers sont encore des applications en cobol et que ça leur coûte un fric fou à maintenir, parce que c'est des technos qui sont trop anciennes. Je ne pourrais pas confirmer ou infirmer si c'est vrai ou pas.
Sylvain:
Pour pouvoir penser dans le monde bancaire, c'est de moins en moins vrai.
Bruno:
Voilà. Parce qu'il y a un moment, quand même on jette ces vieux trucs donc j'entends que, le coeur de beaucoup de bases de données sont des trucs qui sont hyper anciens sur lesquels il y a beaucoup de gens qui ont bossé et qui sont hyper fiables, mais est-ce qu'essayer de les triturer pour essayer d'en faire forcément quelque chose qui s'adapte à des nouveaux usages, est-ce que c'est vraiment, en sincérité est-ce que c'est vraiment le meilleur choix.
Sylvain:
Je sais pas si c'est le meilleur c'est un des choix possibles il n'y a que deux choix possibles le choix c'est soit on fait tout chacun de son côté soit derrière on essaie d'intégrer après on peut partir d'un côté et revenir de l'autre, on n'empêche pas l'autre, je vais dire aujourd'hui on a l'exemple je prends l'exemple tout con avec, InnoDB qui est le moteur de stockage par défaut en MariaDB à la base c'était un stand alone à la base c'est un produit qui s'appelait InnoBase qui était tout seul dans son coin et le mec se dit putain, MariaDB, à l'époque c'était MySQL encore ils se sont dit ça a l'air vachement cool comme produit en fait on va porter parce qu'en fait innobase ils étaient surtout fort sur la partie stockage mais sur la partie sql en haut dessus c'était ils étaient un peu moins fort alors que maraday c'était l'inverse à l'époque ils avaient que maïsame stockage en gros il avait dit bon enfin fichier on met des verres on s'en fout on verra plus tard et il avait travaillé sur l'optimizer et toute la partie justement interprétation du sql avant le stockage et en fait les mecs se sont dit bah si on joue à les deux on va faire un truc qui dépote ce qui est le cas d'ailleurs. Et c'est marrant parce que l'histoire du moteur de stockage ColonStore de Maradb, c'est exactement la même chose. ColonStore, au départ, s'appelle InfiniDB. C'est un projet stand-alone qui était basé, je crois, sur du MySQL, je ne sais plus combien, c'est un truc assez vieux. Et il y a des gens qui se sont dit, ouais, mais en fait, on pourrait juste en faire un moteur de stockage pour Maradb. Comme ça, on aurait des tables stockées en colonne et on pourrait y aller. Finalement je pense que ça c'est plutôt une bonne voie c'est à dire que développer, après on va pas sentir il y a quasiment aucun type de base de données qui va disparaître par contre la plupart aujourd'hui sont utilisés parfois enfin pas à mauvais escient mais parfois un peu comme solution de simplicité un peu détournée alors que, pourrait être utilisée autrement ils ont tous des adaptations de niche mais le modèle relationnel Aujourd'hui, c'est enrichi partiellement, je dirais aujourd'hui, quand tu veux traiter du zone, tu n'as plus besoin d'aller chercher un document de store. D'ailleurs, je prends un exemple tout con. Aujourd'hui, si tu as un client, une application MongoDB, tu peux la linker sur DemareDB. On sait, avec Maxcale, on a mis un interpréteur. Ton client MongoDB, il est persuadé qu'il parle dans ce MongoDB. En réalité, derrière, c'est une table basique, modèle relationnel, où t'as une clé, et en face, t'as ton document JSON qui est stocké dans la table. Et donc, du coup, de l'autre côté, t'as un client SQL qui pourrait tout à fait venir lui parler aussi. Donc, insérer des données, faire un transfert comme ça.
Bruno:
Mais tu vois, je reviens sur... Tout à l'heure, tu parlais de l'hype. On en parlait aussi un petit peu avant de commencer l'enregistrement de cet épisode. Il y a... Alors, effectivement, il y a une hype qui est indéniable dans notre secteur ça n'arrête pas sur tous les sujets, il y avait un avantage d'avoir toutes ces technos de base de données c'est que, ça te faisait une petite barrière à l'entrée c'est à dire que si tu voulais faire du NoSQL il fallait que tu te crées un nouveau service avec ta base de données à côté si tu voulais t'ajouter un élastique ça te représentait un coup de pointe tu avais une barrière à l'entrée, entre guillemets plus ou moins naturelle si on dit que demain avec MariaDB tu peux faire aussi bien du SQL que du NoSQL que du graph que je ne sais quoi, On se dirige vers une capacité à ce qu'il y ait plus de gens qui fassent n'importe quoi aussi avec les technos. C'est-à-dire que comme c'est juste là, tu flippes un switch et tu commences à faire de la merde pour dire les choses crûment.
Sylvain:
Effectivement, ça c'est le revers de la médaille. Le gros avantage, c'est aujourd'hui, en admettant qu'on fait converger et qu'on a tous les outils, l'avantage d'avoir une convergence sur MariaDB ou Postgre ou d'autres, c'est que t'as finalement un seul coeur qui travaille, enfin un seul moteur on va dire, donc du coup pour tes admins c'est un peu plus simple parce que ils ont juste à connaître MariaDB et puis c'est un peu plus facile pour tout le monde, t'as un seul point d'entrée pour tout le monde parce que finalement MariaDB c'est d'un point de vue applicatif ça reste une IP import et puis vas-y, effectivement par contre le revers de la médaille après j'ai envie de te dire, j'ai envie de le comparer au bricolage tu sais, moi il n'y a rien qui m'empêche d'acheter tous les outils et de tenter des trucs à la maison et de faire absolument n'importe quoi, ça reste une boîte à outils qu'il faut utiliser à bon escient mais à ceci dit c'est aussi vrai aujourd'hui j'ai envie de te dire avec les software as a service et tout ce qu'il y a dans le cloud, il n'y a rien qui t'empêche de claquer un MongoDB en 3 clics de souris chez AWS.
Bruno:
Ou GCP.
Sylvain:
Et de faire la même connerie en plus tu vas l'héberger et tu vas la payer peut-être encore plus cher que si tu le fais sur ton instance de dev chez toi.
Bruno:
Dans ces sujets de convergence à quel point est-ce que les choses peuvent être mélangées est-ce que je peux avoir une base de données avec une table hyper, structurée à l'ancienne sur un moteur inodb et puis à côté, du graph qui se balade est-ce que c'est quand même des bases à part est-ce que je peux avoir même une table avec des données hétérogènes, Alors.
Sylvain:
Pour Postgre, je ne sais pas, ça va trop loin, pour MarlDB, je peux te répondre, ça se passe au niveau de la table, chaque table peut être stockée de manière différente, donc dans une même base de données, dans un même schéma, tu peux avoir une table où tu as du JSON, qui est une table d'un ODB par ailleurs. Donc, tu as ton JSON, tu as tes fonctions natives, JSON, tu travailles dessus et compagnie. Tu peux avoir une table qui est formée en colonne. La table d'à côté, c'est du graphe. Tu peux avoir de tout. Et techniquement, tu peux les lier entre elles dans la même requête si tu as besoin. Ça ne pose pas de problème. La MariaDB, l'architecture interne de MariaDB, donc avec cette API qui a historiquement, d'ailleurs, c'est très rigolo parce qu'on va y revenir après sur l'élection du code. En fait, l'API qui permet d'avoir des moteurs de cache, techniquement, c'est l'API de plugin. Quand ils ont développé l'API de plugin il y a des développeurs qui ont dit, menti, même si t'es pas d'accord on va l'étendre et tous les moteurs de stockage sont considérés comme des plugins de la base, c'est comme ça qu'on en est arrivé justement à cette notion de moteur de stockage, et du coup l'API ils ont codifié l'accès aux données avec un certain nombre de choses pour accès aux données on a besoin de faire comme ci, comme ci, comme ci comme ça, comme ça, et ton Aplugin il répond à ça, il est enregistré comme moteur de stockage et puis c'est parti, donc oui, pour répondre à la question oui.
Bruno:
Alors ok alors ma deuxième question avant de revenir à celle qui a émergé suite à ta première réponse, donc oui on peut avoir des tables de format différent est-ce qu'il faut ou est-ce qu'il vaut mieux essayer de, nous en tant qu'informaticien on a un côté un peu très parfois on est très cartésien on veut que les choses soient bien rangées, est-ce que pour des raisons de performance ou je ne sais quoi ou juste de best practice il vaut mieux quand même éviter d'avoir une base avec des tables de format trop variées.
Sylvain:
Alors en termes de best practice, purement technique et performant non pas spécialement il faut quand même faire attention aux limitations des moteurs de stockage que certains sont quand même malgré tout pas transactionnels dans ceux que j'ai cités non ils sont tous transactionnels mais il existe aussi des moteurs de stockage non transactionnels ou des moteurs de stockage qui peuvent être plus longs donc ils risquent de ralentir un peu certaines choses, donc il faut quand même faire un peu attention sur ce qu'on fait mais techniquement il n'y a pas de. Il n'y a pas de limitation particulière. Après, l'idée globale, de toute façon, c'est quand vous travaillez sur du maire ADB, on va dire, soit vous êtes sur une application OLTP qui peut avoir quelques besoins périphériques autres. Donc, vous allez avoir 90% de vos tables qui vont être en INODB, qui est le moteur OLTP de base. Et puis derrière, vous allez peut-être avoir une table en MyRox parce que vous avez besoin d'enregistrer justement les parcours de clic chez quelqu'un et les parcours de clic sur le site. Et vous n'avez pas envie que ça réécrit vraiment très très vite. Donc là MyRox est fait pour ça on parle de convergence d'ailleurs MyRox c'est RoxxDB qui tourne une instance RoxxDB qui tourne en dessous avec une surcouche pour la rendre pour la rendre transactionnelle acide et tout, non mais tu pourras te dire le sujet de la convergence il sort pas de n'importe où il y a une vraie idée derrière, voilà aujourd'hui on va dire quand même par contre on va pas se mentir même s'il est possible d'avoir des tables au format, colonne là je conseillerais quand même d'avoir une instance dédiée à colonne store quitte à avoir quelques tables parce que colonne store c'est qu'on va stocker les colonnes donc des grosses tables, on peut avoir besoin de tables de dimensions à côté, qui vont être en IODB il n'y a pas de soucis, mais par contre je ne conseillerais pas d'héberger la table colonne store là où les tables, où on a tout l'historique pour faire les trucs au sein d'une base OLTP là quand même en termes d'architecture on est sur deux fonctions très différentes, donc c'est quand même mieux de les séparer sur deux machines différentes, c'est un peu plus simple.
Bruno:
Ok l'autre point c'était du coup sur ces moteurs de stockage qui deviennent des plugins au même titre que n'importe quel plugin sur Maria est-ce que ça veut dire qu'il y a eu cette même logique aussi côté au niveau de l'interpréteur parce qu'au final t'adresses pas forcément une table graph en SQL en tout cas moi j'aurais pas ce réflexe là mais du coup ça veut dire que ton, Ça veut dire qu'aujourd'hui, avec du Maria, tu peux adresser une table graph en SQL à l'ancienne.
Sylvain:
Oui.
Bruno:
Ou adresser une table relationnelle avec une requête en JSON ?
Sylvain:
Aujourd'hui, à moins d'installer un plugin spécifique, donc je te disais le plugin NoSQL qui fait du crude, t'es obligé d'essayer que le SQL. Il n'y a pas d'autre chose. Et t'accèdes à tous tes moteurs en dessous via du SQL.
Bruno:
Mais donc, si tu veux que t'installes un plugin pour te faire ton adressage en crude, est-ce que ça veut dire que la partie adressage aussi est devenue un plugin et du coup, il reste quoi dans Maria ? Tu veux dire de manière native ? La question me paraît de con, mais...
Sylvain:
Non, non, non. De manière native, il y a toute la partie interprétation et optimisation du SQL en fait jusqu'à la génération du plan d'exécution des requêtes tout ça c'est le coeur du serveur et ensuite. Ce que les gens appellent l'expring plan qui est le plan d'exécution version visuelle pour nous comprendre ce qu'il fait en fait ce plan là lui il est transmis justement à la couche d'API qui va le traduire, il y a une petite surcouche au dessus de l'API parce que t'as l'API qui est l'ensemble des fonctions mais t'as aussi une couche au-dessus qui s'appelle le Handler qui va prendre un plan d'exécution et qui va le traduire parce qu'en fait un plan d'exécution il te dit tu vas accéder à cette table là par cet index là avec telle stratégie sauf que telle stratégie ça peut vouloir lire 250 000 lignes il va pas lui envoyer juste la ligne au moteur stockage il va dire au moteur stockage tu ouvres telle table, tu prends tel index tu te mets à telle position, tu parcours ça tu fais tant de temps de next c'est ce genre de choses qui sont faites, donc le coeur du serveur qui est entre la partie haute qui gère les connexions et le plugin c'est vraiment toute la partie, je transforme le texte SQL en un arbre binaire je crée mon plan d'exécution à partir de ça et je le feed à l'exécution à l'équipe XQN engine le plugin crude vient se mettre sur le côté et il crée un port qui permet de parler directement au code execution engine avec des ordres de type little link, insertez le donné mais un jour ça, délai de ça.
Bruno:
Ok, j'avoue. Sur... Attends, c'était quoi ma question ? Ouais, c'était surtout ces plugins qui sont ajoutés. Mon analogie, c'était... Tu connais le projet Can It Run Doom ?
Sylvain:
Ça me dit quelque chose.
Bruno:
C'est en fait, c'est un petit groupe, je crois que c'est sur Reddit que ça a commencé. L'idée, en fait, c'est sur tout appareil qui a un écran, est-ce qu'on peut lui faire tourner Doom ? Et donc, ils arrivent à faire tourner Doom sur énormément de devices aujourd'hui.
Sylvain:
C'est assez impressionnant c'est pas eux qui ont fait tourner Doom dans Minecraft ?
Bruno:
C'est pas impossible il me semble ou en tout cas ceux qui ont réussi à le faire l'ont très clairement posté dans le Reddit il me semble avoir.
Sylvain:
Lu quelque chose comme ça.
Bruno:
Ma question en fait c'est est-ce que parce qu'en fait Maria et compagnie donc on le sait c'est des projets open source ces plugins sont avant tout apportés par la communauté j'imagine avant d'être portés par Maria Corporation directement, est-ce que c'est pas un peu cette même optique en fait les gens qui se disent « Tiens, moi, je fais beaucoup de graphes. Quand j'étais petit, j'aimais bien Maria. Essayons de marier ces deux mondes. » Est-ce que cette convergence, ça ne part pas un peu d'une espèce de challenge technique de se dire « Tiens, et si ? », Au-delà d'un vrai besoin métier.
Sylvain:
C'est tout à fait possible. Justement, l'avantage de Maa, c'est que comme il est open source et qu'il a justement cette interface de plugin qui le rend très ouvert, on a déjà effectivement, il y a cette capacité de n'importe qui de créer un plugin qui vient s'intégrer. Et effectivement, des plugins, on en a qui viennent de différents horizons. Le dernier rajout, c'était le Vector Search qui a été refilé par AWS à la fondation de Maradébé. Avant, on avait eu la transparent data encryption, donc l'encryption des données sur disque, qui avait été refilée par Google, si je ne dis pas de bêtises. On a eu les groupes commit qui avaient été filés par Meta, en 5.5, c'était un peu plus. C'était soit des parties de code, soit des plugins qui ont été donnés par les entreprises. À côté, si je ne dis pas de bêtises, au QGraph, effectivement, c'est des gens qui se sont dit, tiens, on ferait bien du graph dans la base de données. Ça pourrait être sympa il y a un moteur qui s'appelle Connect qui permet de se connecter à des sources, hybrides, on se connecte à tout et n'importe quoi pour le coup c'est fantastique, vous pouvez connecter à des fichiers CSV, des fichiers Excel des bases de données au rack on se connecte à tout et n'importe quoi et là c'est un gars qui est un passionné et il s'est fait son moteur de stockage et à chaque fois qu'il a une nouvelle idée il la rajoute dedans.
Bruno:
Et on peut se connecter.
Sylvain:
À tout et n'importe quoi c'est fabuleux.
Bruno:
C'est aussi la richesse de ces projets open source tu as une espèce de mais du coup la question c'est est-ce que, est-ce que j'entends le fait que ça te simplifie ça peut potentiellement te coûter moins cher même si je reste encore un peu dubitatif sur le fait qu'il te faut une seule et même personne, pour te gérer ton Maria sous prétesse que tout est sous Maria tu as quand même un.
Sylvain:
Au bout d'un moment, il faut quand même pallier en fonction des CLF. Tu es obligé d'avoir plusieurs personnes, parce que si tu veux faire du 24-7-7, 24-7-7, tu peux faire ça sur une personne. Dans tous les cas. Mais aujourd'hui, je le vois... Je n'ai plus trop une perspective client. Ça fait quasiment 10 ans que je travaillais avec MariaDB. Mais je vois, quand j'étais client, donc avant, aujourd'hui, groupe Fram, je veux dire, on était deux. On était 2dba dans la boîte alors il y avait une équipe 6admin qui pouvait suppler un peu de temps en temps mais on était 2dba et on gérait on avait un oracle, un sql serveur et je parle juste de la prod, 57 maradb je crois ok alors après il n'y avait pas de truc très violent c'était soit de l'application asynchrone soit du galera et que du inodb partout il n'y avait pas grand chose de foufou mais pour autant enfin voilà, maradb après c'est comme toutes les bases d'années une fois qu'on a fait le nécessaire pour que ça ronronne normalement ça a plus de raison de tomber à tout.
Bruno:
Si tu l'utilises avec des schémas hyper variés il y a quand même il faut quand même des gens côté Ops après aussi qui sont capables de superviser ou de suivre un peu ces usages.
Sylvain:
Oui oui alors après justement c'est là où je pense que si on fait cette démarche là d'avoir vraiment, le one size fits all version MariaDB je pense qu'on est obligé d'avoir des DBA mais on est obligé d'avoir aussi du DevOps à côté on peut pas, là pour le coup on peut plus avoir la vieille dichotomie les développeurs d'un côté les DBA de l'autre et puis ils se regardent dans le chien de faïence par dessus leur écran, on est obligé d'avoir des DevOps qui vont venir justement rendre la chose un peu plus facile.
Bruno:
Est-ce que le fait d'avoir un Maria qui peut faire les deux c'est pas aussi l'occasion d'arrêter de faire les deux ma question étant, de ma perception, peut-être que je me trompe mais j'ai l'impression qu'il y a encore beaucoup, même encore en 2024, il y a encore beaucoup de projets qui utilisent du NoSQL alors qu'ils ont des données qui sont extrêmement relationnelles et que, le faire avec un bon Inodb ça fonctionnerait potentiellement mieux.
Sylvain:
Oui, je pense qu'il y a un certain nombre de cas d'usages d'une OSQL qui pourraient être tout à fait portés dans une base, en Maria ou autre. Là-dessus, je ne suis pas sectaire, mais je pense qu'il y a un certain nombre d'usages qui sont faits aujourd'hui d'une OSQL qui sont totalement normés. Après, je n'ai pas regardé, mais justement, je repensais au grand jour du XML avant que le JSON existe. Il s'est passé un truc phénoménal. Au début, on avait le XML, c'était cool. Après, il sont venus le XSS pour faire joli, mais ça, on n'en parle pas. Et puis, un jour, il est apparu un truc très rigolo. les gens se sont dit, bon bah c'est super sympa on a des data qui s'autodécrivent mais elles s'autodécrivent mais elles ne sont pas capables de dire si elles sont correctes. Donc on va sortir le fichier XSD, le fichier qui te dit comment doit-elle structurer ton fichier XML pour qu'il soit au bon format. Et je ne sais plus si ça existe dans le JSON, il me semble avoir lu que les JSON Definition Schema existaient quelque part, et du coup c'est le problème de la donnée qui s'autodécrit ça s'autodécrit mais comment un système externe, il faut qu'il ait la connaissance de la description du truc il peut pas lire les champs et deviner si le champ est bien normé ou pas, donc après on peut s'amuser quand on insère dans un jison mettre des règles de gestion avec des contraintes tel champ doit exister, tel champ doit exister avoir tel type, on peut s'amuser à faire ça on commence.
Bruno:
À se diriger vers du relationnel à l'ancienne.
Sylvain:
Le problème c'est que la donnée autodécrite au bout d'un moment elle a ses limites, et le truc c'est qu'un système quand tu lui files tu lui dis je vais t'envoyer du JSON et puis dedans il y a plein de clés valeurs parce que fondamentalement c'est ça c'est une notation qui permet de faire du clé valeur, des familles de clés valeurs avec éventuellement de la profondeur si tu utilises les array et compagnie, des documents inclus parce que tu peux inclure un JSON dans un autre JSON tu peux aller à plein à des niveaux X de profondeur, le problème c'est bon bah c'est super mais, Tu peux donner un oncle qui a un sens pour un humain. La machine, que ça s'appelle Toto, Rent the Car, ou mon véhicule, elle ne comprend pas la différence. Pour elle, c'est une chaîne de caractères, il n'y a pas de sens. Si tu veux lui donner un sens, tu es obligé d'avoir un fichier qui décrit. Et si tu donnes un fichier qui décrit, tu figes. Et si tu figes, c'est de ne les structurer.
Bruno:
Donc on y revient.
Sylvain:
Donc on y revient. Mais après, ceci dit, on peut tout à fait recevoir un JSON avec un XSD. Il est intégré dans une table. Enfin, je veux dire, il y a plein de manières de faire. soit tu le splits directement, tu le splits avant et donc ton ordre insère à déjà ta structuration, soit aujourd'hui un truc qui est sympa dans un ADB, tu l'insères dans ton JSON et tu as des colonnes qui vont faire le parsing et qui vont faire l'éclatement pour toi automatiquement. Et du coup tu as inséré ta donnée en semi structurée et tu retrouves ta donnée structurée dans les colonnes supplémentaires qui se calculent automatiquement.
Bruno:
J'étais en train de poser une question dans ma tête qui était, est-ce que l'avenir des bases de données, ce ne serait pas un énorme saut où moi, en tant que service, je t'envoie mes données et la manière dont tu les stockes ne devrait même plus me concerner. On va au-delà du service manager je te file une donnée et juste quand je te la demande tu me la rends mais en fait ça correspond à une OSQL ou du, document store en fait, je t'envoie un fichier après tu le stock et puis quand je te le demande tu me le restitues en fait après.
Sylvain:
En fait ça correspond un peu à toutes les bases nées quand tu réfléchis.
Bruno:
Même si ta donnée est structurée de manière complètement, complètement déstructurée moi j'ai une info je la récupère.
Sylvain:
Je te la donne.
Bruno:
Sans me soucier du moindre schéma et après peut-être que la base de données serait capable de dire j'ai un schéma qui se dégage à l'usage je vois que.
Sylvain:
Je shift.
Bruno:
Mon stockage mais en fait c'est peut-être.
Sylvain:
Là le truc c'est effectivement que tu auras une première étape de stockage qui consiste à faire du full ce qui m'a l'aise, ce qu'on est déjà capable de faire, aujourd'hui dans une ODB tu crées une table où tu as un ID et un champ un champ type texte ou blob et tu fais bien ce que tu veux dedans c'est passé pas ça peut se faire ça va se passe aussi tu peux le faire dans plein plein de formats différents par contre après de dire il ya un schéma qui se dégage c'est vrai qu'il faudra voir derrière des outils qui sont capables d'analyser le truc et de voir le schéma, Et dans tous les cas, le problème, c'est-à-dire qu'il faut que tu... Enfin, si tu veux l'automatiser complètement, c'est-à-dire que toi, tu ne sais pas le truc, c'est-à-dire qu'en fait, il faudra intégrer une intelligence artificielle dans ta base qui parse les données de ta table et qui dit « Ah, mais en fait, il y a toujours tous ces champs-là, machin, là, là. » Ça, c'est la liste de tout ce qu'il y a en permanence. Mais après, le problème, c'est qu'est-ce que tu fais ? Si tu le transformes. C'est-à-dire qu'il faut que tu continues à transférer tes données de l'une à l'autre. et de toute manière toi tes requêtes tu t'envoies du chez Malès, tu vas aussi demander du chez Malès en retour donc en fait quel intérêt je suis d'accord.
Bruno:
C'est pour ça que je construisais la question dans ma tête et puis en même temps je me disais ouais mais en fait c'est plus ou moins un peu ce qui se fait et puis est-ce que ben voilà, donc je te partageais une question.
Sylvain:
Non terminée.
Bruno:
Qui effectivement aurait peut-être.
Sylvain:
Après il y a peut-être des gens qui auront d'autres réponses, peut-être que ça peut avoir effectivement alors je pense que ça peut avoir un intérêt par contre, si tu insères de la donnée non structurée en Scheme LS et que derrière tu as des gens qui veulent faire de l'exploration de données, et là effectivement ça peut être intéressant ça me fait penser à un outil sur lequel je tombe il n'y a pas longtemps qui s'appelle Koyori GPT et en fait tu formalises des requêtes en langage naturel et normalement il te génère, du SQL derrière le truc c'est derrière il faut quand même le tuner un peu parce que lui il faut qu'il aille explorer le schéma de la base qu'il aille comprendre les choses donc je pense qu'aujourd'hui cet outil ne fonctionne que sur de la donnée totalement structurée pour autant on pourrait tout à fait imaginer, que t'es une deuxième partie de l'outil justement qui travaille sur du SchemeLS pour extraire de l'ordre justement de ton SchemeLS et qui permet justement en langage naturel d'aller faire de l'exploration de données sur cette partie plus structurée ça pourrait s'imaginer j'aime pas euh.
Bruno:
On a parlé effectivement des plugins. Pour ceux qui ne le savaient pas, tu es déjà venu sur le podcast il y a deux ans à peu près. Et tu m'as proposé ce sujet-là suite à l'écoute de l'épisode 184 que tu as évoqué un petit peu tout à l'heure avec Guillaume Rangier, où il évoquait, il prédisait le fait qu'il allait avoir de plus en plus de codes, qui allaient se rapprocher. Le code allait se rapprocher de la base de données dans le cadre de ce traitement.
Sylvain:
Effectivement.
Bruno:
Dans ces sujets de convergence, toi, c'est aussi quelque chose que tu vois arriver, qu'on met de plus en plus d'intelligence ou de logique, entre guillemets, métier, dans la base de données directement ?
Sylvain:
Alors, le mouvement architectural, techniquement, c'était l'inverse. Extraire la logique de la base de données. Parce qu'au début, effectivement, on a fait, on a dit, intégrons les traitements lourds au plus proche des données. Comme ça ça évite les alertes aux compagnies donc c'est comme ça qu'on a eu le plsql chez oracle avec, ces trucs qu'on a connu enfin tous ceux qui ont bossé sur a connaissent un les packages les fonctions et procédures et tout le compagnie le problème c'est que ça crée du vendeur lock-in parce que battre on l'engage sur oracle c'est le plsql chez maradb c'est l'esql psm chez postgre je sais pas comment s'appelle et chez est-ce que le serveur c'est transac sql chacun son langage ils sont pas compatibles entre eux maintenant pour l'histoire ma db à on a un moteur d'interprétation plsql donc on sait faire tourner du plsql sur ma db mais bon ça c'est une particularité ma db suite à une demande d'un client qui voulait migrer c'est pas l'idée c'est pas de dire voilà l'idée c'est qu'on pourra faire converger et faire intégrer du code justement quand on va se détacher que l'on n'interprétera plus des langages propriétaires donc ça c'est une première chose qui avait été un peu faite par oracle mais bon ça reste du vendeur lock-in quand parce qu'il y a fort longtemps, on pouvait déjà intégrer des classes Java sous forme de procédure stockée dans Oracle. Il y avait une première idée. L'idée, c'était, si tu as une classe Java... Peut-être qu'en fait, ta classe Java, tu peux la porter ailleurs. Tu n'es pas obligé de la faire tourner que dans... Java, c'est du Java. Ça a été fait en partie. Même si ce n'est pas que pour ça, c'est en partie portable sur tous les systèmes. Aujourd'hui, justement, l'idée, c'est comment est-ce qu'on peut faire ça ? Alors, Maradébé répond en partie à l'histoire. C'est que dans Maradébé, tu peux créer des fonctions. Alors aujourd'hui, il n'y a que des fonctions, mais tu peux créer des plugins aussi. En fait, les plugins et les fonctions qui sont dites user-defined functions. C'est ni plus ni moins que des librairies partagées compilés donc c'est des points SO compilés avec les flags de partage c'est à dire qu'aujourd'hui on peut les écrire en C c'est ce que je fais mais on peut les écrire en Go ou en Rust si on connaît, Donc on peut déjà faire tourner du code dans MariaDB, parce que la librairie est intégrée dans MariaDB. Pour l'instant, c'est limité à une fonction. En fait, si tu fais un select, ça tape une fonction et elle fait des trucs et dit oui ou non. Ça va pas plus loin. On pourra probablement faire des choses un petit peu plus évoluées, je pense, à l'avenir. Avec un plugin approprié, je pense qu'on pourrait créer des procédures stockées qui font des choses et qui te renvoient de la donnée et compagnie. Parce que la fonction elle prend quelques paramètres, elle te renvoie une valeur scalaire et puis basta. Mais aujourd'hui on a déjà un premier niveau où on peut déjà le faire.
Bruno:
Et toi t'as l'impression que ça va se généraliser que ça va augmenter ? T'es en phase avec ce que disait Guillaume ?
Sylvain:
Ça va se généraliser non parce que ça va rester limité à certains besoins parce qu'aujourd'hui tout le monde n'a pas besoin de la performance que va apporter l'exécution du code dans le noyau de la base. Je veux dire je pense pas que Booking en ait besoin. on va pas se mentir, Booking pour présenter sa home page c'est de la donnée statique, ils s'en foutent c'est un petit peu vulgaire voilà, mais c'est l'idée, par contre après effectivement quand on a des besoins vraiment de très très grosses performances. Il pourrait être plus intéressant parce qu'aujourd'hui on a beaucoup de choses où en fait on s'aperçoit que le batch tourne sur une machine et en fait il appelle les données via le réseau, il les récupère, il les travaille il les renvoie, effectivement comme disait Et Guillaume, si on réfléchit un peu en termes de performance et d'efficacité, on est à la rue. Ça n'a pas de sens d'extraire les données, de les travailler, de les renvoyer dans la base. Si c'est pour les renvoyer, si c'est les travailler pour les renvoyer à un autre système hétérogène, oui, ça a du sens de les poules. Mais si c'est pour les faire de la base de données, pourquoi extraire les données ? Autant les travailler directement en interne pour s'éviter tout le bazar ? Ça c'est partiellement faisable. Aujourd'hui c'est faisable qu'avec des langages propriétaires, donc ADB, C-SQL, PSM, PLSQL. J'ose espérer que bientôt on pourra le faire avec d'autres langages. D'ailleurs, à ce titre-là, MySQL est un petit peu plus en avance que nous, puisqu'ils ont ouvert la possibilité d'écrire des procédeurs stockées. En javascript ils ont un intertracteur javascript qui était intégré dans MySQL, donc javascript c'est un langage qui est indépendant du moteur et ça je pense que c'est encore un signe qu'il y a quelque chose en fait encore une fois ça a du sens, pour moi aujourd'hui ça n'a pas de sens justement, et du batch de travail de données où on match des données pour les passer pour les préformater, pour les précalculer de la base vers la base elle-même, aujourd'hui aujourd'hui c'est les ETL qui extraient de la base qui te les ramènent dans la même un talent qui te fait ça c'est une horreur, non parce qu'aujourd'hui on a moyennement le choix si on a envie d'être un peu libre et de pas être totalement bloqué par le vendeur, mais c'est dommage mais.
Bruno:
Donc dans cette logique que tu présentes aujourd'hui, en tout cas dans un environnement MariaDB t'es obligé d'écrire un plugin, tu peux pas le faire sous forme d'une, procédure stockée ou d'une fonction que tu écrirais de manière un peu plus fluide, on va dire.
Sylvain:
Pas encore, effectivement. C'est une feature request qui est ouverte. C'est une feature request qui est ouverte où on dit puisqu'on peut faire des fonctions, pourquoi est-ce qu'on pourrait pas aller plus loin à voir carrément... Et justement, c'est une feature request qui est en discussion, parce qu'elle est ouverte, mais bon, elle n'est pas... Il y a des réticences. Le fait que MySQL ait rajouté la possibilité d'ouvrir du JavaScript, justement je trouve ça génial parce que ça enfonce un coin phénoménal dans l'outil en disant bah on peut le faire en fait c'est peut-être pas notre priorité mais on peut le faire et ça serait bien qu'on le fasse à mon sens.
Bruno:
Est-ce que j'ai fait un épisode il y a quelques temps sur le GraphQL, qui était un truc que je que j'avais pas.
Sylvain:
Forcément creusé.
Bruno:
À ce point là mais donc c'était un super épisode, je ne vais pas prendre le temps de chercher je ne me souviens plus du coup de l'inviter mais je mettrai un lien bien évidemment dans les notes, est-ce que du coup si on imagine un monde où j'ai toutes mes données dans un MariaDB dans tous les formats qui sont, envisageables, je pourrais en fait me passer d'un back-end parce qu'en fait je pourrais adresser mon MariaDB directement en GraphQL et accéder du coup juste aux données dont j'ai besoin et avoir du coup toutes mes fonctions sous forme de plugin ou autre. Aujourd'hui, l'accès en GraphQL à une base Maria, c'est possible ou c'est pas encore...
Sylvain:
Non. Pour l'instant, l'accès, c'est vraiment SQL. Ou alors, tu installes le plugin dans leur socket qui t'ouvre un socket pour faire du crude. On pourrait imaginer quelqu'un qui crée un plugin pour que tu puisses attaquer la base donnée en GraphQL. Ça pourrait s'imaginer. Après, je t'avoue qu'il faudrait que je creuse un petit peu plus au sujet du GraphQL pour voir le niveau de difficulté ou d'utilité. Mais bon, sachant qu'on peut stocker des bases sous forme de graphes avec le moteur OQ-Graphes, Techniquement, on devrait pouvoir, en théorie. Mais par contre, je pense qu'il faudrait le réserver, attaquer en GraphQL des bases qui sont en IDB. Il faudrait voir comment on traduit de l'un à l'autre.
Bruno:
Mais tu vois, aujourd'hui, avec tous les API Gateway qui sont souvent mis en place, et tu vois, on a fait un autre épisode sur les micro-frontes, tu vois, en fait, ce concept de GraphQL est hyper intéressant. Quand tu es un microservice et compagnie, tu fais ton API Gateway qui va être capable d'aller taper sur différents microservices et toutes tes données, en fait si je te pose la question c'est que, on en avait parlé un peu en préparation de cet épisode, moi je suis plutôt d'origine back-end, je vois une vraie complexification du front qui devient un métier à part entière, pour ceux qui me découvrent dans cet épisode là spécifiquement, sachez que moi quand j'ai commencé à développer dans le monde du web le front c'était de l'intégration HTML donc c'était vraiment pas du dev, donc si on me dit que maintenant dans le front il y a de plus en plus de logique métier parce qu'en fait les applications maintenant sont hyper taffées et hyper complexes, et que maintenant on va rapprocher du code aussi des bases de données il va nous rester quoi en fait dans le back-end tu vois petit peu petit j'ai l'impression qu'il y a une espèce de alors est-ce que c'est une disparition du métier ou un changement du métier je sais pas, mais il y a peut-être une question à se poser en fait est-ce que le back-end a encore de l'intérêt ?
Sylvain:
Il y a deux manières de répondre. Je vais répondre plutôt sur la partie rapport au métier de dev back-end. Le métier de dev back-end, il est amené à évoluer comme le métier de... Parce que le premier métier qui a évolué au départ, c'était le front. On ne va pas se mentir. Comme tu dis, au début, c'était de l'intégration HTML. Puis est arrivé le HTML 2.0, puis c'est arrivé après les CSS, les machins, jusqu'à avoir full JavaScript et compagnie. Donc aujourd'hui effectivement le métier du front s'est complexifié puisque, beaucoup de la logique métier est sortie du back-end pour remonter vers le front, à mon avis c'était une erreur alors c'était une erreur dans le sens où on aurait dû demander au dev back-end de continuer à coder la logique métier parce que c'est, le métier le dev back-end tu codes de la logique métier oui.
Bruno:
Mais c'est dans une dans une dans une ancienne construction des applications.
Sylvain:
De se.
Bruno:
Dire que la logique.
Sylvain:
Métier elle.
Bruno:
Va être côté front mais aujourd'hui t'as les applications front la logique métier elle va être côté back mais aujourd'hui les applications front sont quand même tellement taffées, tellement complexes que t'as nécessairement de la logique métier qui est intégrée dedans bien sûr.
Sylvain:
Bien sûr alors du coup après on a un autre problème qui dérive, c'est que pour moi. Même si maintenant, ça tend à changer, la distinction dev front-end-back-end ne devrait pas exister. Je te l'ai dit tout à l'heure hors-life, pour moi, un dev, il devrait être capable de toucher à tout, même s'il a une spécialité. Je veux dire, on ne peut pas être vraiment un bon dev, à mon sens, si on n'a pas la connaissance de toute la stack. Je ne parle pas d'être expert de toute la stack depuis le proxy qui se trouve juste derrière le firewall de l'entreprise jusqu'au hardware en dessous. Mais il faut avoir la connaissance du fonctionnement de tout, à mon sens, pour être un bon dev éviter de faire des trucs qui mettent les autres dans la pannelle en termes de design et pour le coup, pour moi, la séparation front-end, back-end, quand on parle des architectures X couches tu as toujours la couche prestation, la couche persistance et en dessous de la couche persistance, c'est la couche métier où tu as les règles, ces règles-là devraient pour moi être développées, non pas par les développeurs front-end, mais par les développeurs back déjà parce que eux, c'est en admettant qu'il y a des développeurs un développeur qui va être plus spécialisé sur le développement d'un règle métier, parce que je suis désolé aujourd'hui coder des interfaces, coder la persistance donnée et tout ça, c'est en train de devenir effectivement un métier très spécialisé avec des trucs hyper techniques qui sont compliqués et ça demande pas du tout la même manière de réfléchir à la manière de coder d'un règle métier.
Bruno:
Alors, attends, je suis un peu ambivalent sur ton propos, parce que d'un côté je suis d'accord et d'un côté je ne suis pas d'accord. Alors peut-être qu'il faut que j'essaie de mieux le définir. Donc ce que tu nous dis, c'est que la distinction dev front-dev back ne devrait pas exister. Alors j'aime bien le propos un peu clivant, tu t'en doutes, ça en fera un extrait vidéo pour le podcast. Est-ce que ce que tu veux dire, c'est que tout le monde devrait être full stack, auquel cas j'aurais tendance à ne pas être d'accord avec toi ? Ou est-ce que ce que tu dis, c'est que il faudrait qu'en fonction de ce que tu fais tu sois capable de le faire aussi bien en front qu'en back, et que du coup t'es des devs métiers et des devs interface ou des devs persistance voilà.
Sylvain:
Je suis plus sur cette partie là pour moi effectivement tout le monde devrait être capable d'être un développeur full stack potable j'ai bien potable.
Bruno:
Ouais parce qu'aujourd'hui c'est quand même vu le niveau de complexité des technos mais je dis.
Sylvain:
Juste potable c'est à dire que t'es capable de développer un truc qui fonctionne. Est-ce qu'il fonctionne bien, assez performant en compagnie ? Est-ce qu'il est beau ? Est-ce qu'il est propre ? Non. Mais tout le monde, pour moi, un dev, il devrait être capable de coder l'intégralité du truc. Évidemment, il aura ses points forts, parce que si c'est un dev qui est plutôt orienté métier, règle métier, un dev qui est plutôt orienté, justement, tout ce qui est interface et compagnie, chacun aura son point fort, son point d'expertise, justement. Mais c'est là où j'en venais sur le côté de la culture générale. Pour moi, aujourd'hui, il est anormal qu'un développeur qui développe une application type OLTP ou même l'application mobile, parce que l'application mobile, je suis désolé, la plupart des données qu'elles stockent, c'est de la donnée structurée, il n'est pas normal qu'ils disent « bon, le chemin de base de données, je n'y connais rien ». C'est ton boulot de stocker les données et de les récupérer, c'est le but d'une appli en fait, c'est nécessaire. Donc tu devrais savoir le faire. Est-ce que tu dois être expert dedans ? Non, pas obligatoirement. Mais au moins savoir le faire et comprendre que stocker des données structurées, ce n'est pas un crime. C'est pas grave. Ça se fait, il y a des manières de le faire, il y a des manières de réfléchir. Et moi, c'est un autre truc qui me pose problème. Parce qu'aujourd'hui, il y a des gens, et je lisais encore ce LinkedIn aujourd'hui chez des personnes que je connais, des gens qui sortent d'études, et d'études en informatique. L'algorithmie, manifestement, n'ont pas trop leur truc. L'organisation des données, bon, sur un gros gison avec plein de clés valeurs dedans, c'est cool. Ils ont appris quoi ? Moi, ça me pose problème. Justement, un bon développeur, ça c'est... J'ai perdu son nom, c'est un gars que je suis pas mal sur LinkedIn, je crois que c'est... Je le retrouverai. Qui est CTO d'une entreprise. Il le dit assez clairement, il dit un bon dev, c'est pas un mec qui est expert dans un langage. Il dit c'est quelqu'un qui est capable d'organiser ses pensées, d'organiser son travail. Et justement, il dit le métier du développeur, de développement en réalité, c'est de transformer des idées et des phrases en français, donc en langage naturel, en code qui fait ce que décrivaient ces idées. C'est un traducteur. Ça, c'est un traducteur. Donc après, tu vas avoir tes points forts. Comme tout le monde.
Bruno:
Ce ne serait pas Rudy, par hasard ?
Sylvain:
Si, c'est Rudy Onfroy. J'aime beaucoup son point de vue sur les développeurs.
Bruno:
Il est venu sur le podcast aussi.
Sylvain:
Je ne suis pas étonné. Je suis très d'accord avec son point de vue sur les développeurs.
Bruno:
Et donc, Si on remet sur cette question, la disparition du métier de back-end. Alors du coup, j'entends ton propos sur le métier back-end, mais est-ce que, au final, avec juste une application, on va dire React, exécutée chez le client, et une base de données, on serait aujourd'hui en mesure d'avoir une application, un service complet, quitte même à avoir plusieurs bases de données. En fait, c'est aussi un truc, une réflexion que je me faisais en préparant cette émission, sur une ancienne expérience, j'avais effectivement plusieurs technos de base de données qui coexistaient et j'en étais arrivé à un stade où au final mon environnement élastique était devenu presque un microservice à part entière, que j'avais pas forcément besoin de mon bac pour l'adresser directement en fait tu vois il y avait quand même, un ensemble de features et de fonctionnalités qui faisaient que le truc était consommable en stand alone sans passer par donc voilà la question est-ce que le concept de back-end peut avoir, peut disparaître en allez on va dire 2030 ou.
Sylvain:
Non je pense pas parce que fondamentalement le métier de développeur back-end il va juste entre guillemets évoluer, tout le monde même si on a la possibilité tout le monde n'intégrera pas du code dans la base parce qu'on aura toujours des gens qui restent bloqués à différents stades de l'évolution d'architecture, et puis il faut avoir le besoin de le faire mais je pense que, l'intégration justement quelle que soit la forme, que ce soit des plugins que ce soit des librairies, ça peut être plein de formes mais je pense que justement l'intégration de ce code quel que soit le langage dans la base ça deviendra le métier du développe Ça fera partie du métier de développeur back-end. Tout comme continuer à écrire des batchs en ceci ou en cela, ou d'écrire des fonctions qui permettent de répondre justement à un appel d'API pour du microservice. Un peu plus structuré.
Bruno:
Ok. Canon, merci beaucoup Sylvain pour toute cette discussion.
Sylvain:
Je t'en prie.
Bruno:
Cette découverte de la convergence des bases de données. J'aurais deux dernières questions pour toi, qui sont les questions rituelles du podcast. La première, c'est est-ce qu'il y a un contenu que tu souhaiterais partager avec l'ensemble des auditeurs ?
Sylvain:
Alors un contenu, ben ça tombe bien, je l'ai apporté ce que je continue à lire en venant, je suis retombé sur un livre qui n'est pas tout jeune. Que je te présente ici, qui s'appelle Clear, d'un écrivain qui s'appelle M. Kloetzer, qui est un écrivain français. Et en fait, c'est une critique du monde corporate, pour faire simple. En gros, ça reste un petit côté un peu fantastique, mais grossoir, c'est l'histoire de deux consultants d'une firme mondiale qui s'appelle Clear, qui sont chargés de régler les problèmes d'image de l'entreprise dans le monde. Mais Clear, en fait, c'est une méga corpo, on ne sait pas ce qu'elle fait, on ne sait pas ce qu'elle vend, on n'en parle jamais dans le produit mais par contre on parle justement de la vie des personnes ça aborde les notions de plafond de verre, ça aborde la notion de burn-out ce genre de choses canon.
Bruno:
Donc on mettra bien évidemment un lien en description et dernière question peut-être que t'as peut-être pas changé depuis mais Sylvain est-ce que tu es plutôt espace ou tabulation ?
Sylvain:
100% tabulation 100% tabulation.
Bruno:
Très bien, merci beaucoup Sylvain merci beaucoup Bruno et merci à tous d'avoir suivi cet épisode jusqu'au bout, voilà, les bases de données sont en train de changer j'aime bien effectivement cette image utilisée par Sylvain qu'en fait il y a des cycles d'architecture peut-être que comme moi on vous a appris qu'il faut le moins d'intelligence possible dans la base de données et que ce n'est là que pour stocker de l'information, mais il semblerait que c'est en train de changer on va mettre de plus en plus d'intelligence aussi dans nos bases de données peut-être au détriment du bac donc si vous êtes dev bac, il faut peut-être commencer à chercher et j'aime beaucoup ce que tu as évoqué sur cette notion de dev métier dev interface il y a quelque chose d'un peu, peut-être intéressant à creuser, en tout cas vous l'avez entendu ici en premier sur Rift TD si jamais ça devient un truc, on saura d'où ça vient. Voilà, merci à tous je vous remercie aussi de continuer à partager ce podcast autour de vous n'hésitez pas à mettre un commentaire 5 étoiles sur votre application de podcast préférée je vous souhaite une très bonne fin de semaine je vous dis à la semaine prochaine et d'ici là, connaît bien.
