Bonjour et bienvenue dans cet nouvel épisode de Messages à caractère informatique et
Big Data Hebdo.
Aujourd'hui, c'est le ma-si-sam-bande ou le Big Data Hebdo de Saint-Néph.
Elles sont entourées de la merveilleute, elles piercent.
Bonjour à tous.
Est-ce que vous êtes en route ?
Bonjour.
Vincent, tu es là Vincent ? Tu te caches ?
Bonjour à tous.
Ah et Gérôme, tu te caches toi aussi derrière C'est la panne.
Bonjour.
On va faire un tour de table rapide.
Si vous êtes perdus, vous savez pas pourquoi on a nos camarades de Big Data Hebdo ici.
Si vous écoutez les Big Data Hebdo et vous comprenez pas ce gars à l'accent bizarre que vous parlez,
je vous remets au épisode précédent,
sans banter un massif de Saint-Huit Big Data Hebdo.
Donc petit tour de table, moi c'est Horace et on sale et je m'occupe de la partie de Frère et Cléver Cloud.
Et Vincent, qui tu es ?
Bonjour, je suis Vincent Hushling, je suis co-fondateur du Big Data Hebdo
et mon quotidien, c'est d'aider mes clients à construire et utiliser mieux la data Elia.
Miguel, Gérôme et toi ?
Bonjour, moi je suis co-animateur de Big Data Hebdo
et puis je travaille chez Zinnia comme professionnel, services constructants.
Parfait, Steven.
Bonjour, moi je suis Steven Le Roux, je suis ingénieur chez Cléver Cloud
et je m'occupe de l'équipe d'ingénierie.
Et pour finir Pierre.
Hello, moi je travaille sur la partie matériel et système distribué chez Cléver.
Et si vous savez louper l'épisode précédent, on va continuer à parler des fondations d'IVI.
Donc Vincent, laissez reprendre là où on a été arrêter l'autre jour.
Effectivement, on s'est arrêté l'autre jour.
Alors comme je disais, je me posais une question,
à la suite de cet épisode, me disant comment ça se fait,
il n'y a pas possibilité d'utiliser Doug Dibby avec fondation d'IVI.
Et donc ça c'est peut-être une question à laquelle on arrivera à répondre,
de pourquoi ce ne serait pas forcément une bonne idée.
Et pour venir sur ce sujet, l'autre jour on a vraiment détaillé comment fonctionner fondation d'IVI.
Alors moi j'ai plein d'idées suite à ça,
il faut vraiment que je prenne du temps pour essayer ça.
Parce qu'il y a vraiment des concepts passionnants de tout ce que vous nous avez expliqué.
Merci.
Par contre maintenant on va regarder un petit peu de la manière appliquée,
c'est-à-dire ce fondation d'IVI,
et comment est-ce que vous avez construit des offres qui sont un peu l'avenir de ce que vous voulez faire
en termes de gestion de données,
dans vos environnements.
L'histoire c'est pourquoi on peut qualifier ça de Building Block for Everything chez vous.
Et le produit sous-jacent chez vous c'est matéria.
Et quelle est votre vision autour justement de ce matéria pour pouvoir construire...
Alors la première intération c'est matéria cave,
mais j'imagine que vous avez d'autres idées par rapport à ça.
Peut-être avant de parler matéria on peut prendre l'ordre chronologique,
parce qu'il est assez important je pense au sein de Clever.
Comme on l'a dit on a construit des...
on a une boîte à outils,
du coup on a dû construire des choses pour faciliter l'accès,
le développement de couches applicatives.
Mais au final,
le premier cluster fondation qu'on a déployé,
c'était pour la nouvelle release de Warp,
donc une solution de time series qu'on utilisait massivement,
et on a dû déployer...
ça a été le premier cluster qu'on a déployé côté Clever,
c'est celui qui a subi le plus les plattres,
c'est des premiers déploiements à l'échelle de fondation,
mais on est super contents,
ça a changé notre vie opérationnelle entre Edgebase et fondation.
Aujourd'hui pour te donner une idée,
on a trois mois de rétention,
trois ou quatre mois de rétention dans ce cluster-là de télémétrie.
Et on a 50 terras dedans.
D'accord.
Non répliqués.
Enfin avant réplication.
Avant réplication, c'est-à-dire que foncièrement,
vous faites ça sur plusieurs localisations,
j'imagine, donc vous êtes répliqués.
C'est le même schéma de réplication,
parce qu'on avait classiquement avec de la DOOF,
du Edgebase, avec fondation,
c'est-à-dire trois instances localement,
et puis un Datacenter Distant,
où on se retrouve à nouveau avec les mêmes.
C'est le grand classique de ce qu'on a habituellement,
ou c'est un peu différent ?
C'est le truc assez classique.
En fait, dans le modèle de fondation,
tu as une mini-Q qui est Pôle,
et du coup tu as les trois machines qui pollent l'info.
Le truc vraiment notoire,
c'est qu'on a divisé notre nombre de machines par deux,
en prenant entre Edgebase et fondation,
on a divisé par deux le nombre de machines
pour une workload qui était plus grande.
C'est moins de CPU consommé,
ou c'est moins de mémoire, ou les deux ?
C'est vraiment un usage global,
on a vraiment divisé par deux
l'usage CPU RAM,
en passant sur quelque chose qui est monosrédé,
alors on se pose,
le fondation est monosrédé,
mais il fonctionne en distribué,
donc on triche un peu,
mais on est quand même,
les pertes qu'on avait,
on peut en parler,
chez nous le cluster Warp 10,
c'est 100 entre 120 000 écrits par seconde tout le temps,
Avec l'ancien cluster,
on montait à 300, 400 000 lectures par seconde en parallèle,
aujourd'hui quand on commence à scanner massivement,
on tape très facilement les 5-6 millions de lectures
sans incidence de prod.
Sur le même hardware ?
On a grédé un peu le hardware,
mais on a divisé par deux le nombre de machines.
Et alors ?
Vas-y je t'en prie vraiment.
Non non, je t'en prie, dis-moi.
Puisqu'on parle, là on va beaucoup parler plus des usages
et de la merde à laquelle on le fait,
un des gros projets que vous avez eu chez Clever ces dernières années,
ça a été la refonte de votre système de log que vous avez basé sur pulsar.
Alors il y a plein de choses qui font que pulsar était évidemment une très bonne idée,
notamment la capacité de remonter dans le temps,
de pouvoir rejouer, de pouvoir redérouler les choses.
Est-ce que dans FoundationDB, vous auriez pu construire ça,
dans FoundationDB,
ce « puits de log » ?
Oui, alors on...
Tu spoiles un peu ce dont je voulais qu'on parle,
mais en fait on est tellement content de l'opérationnel
et de la connaissance qu'on a obtenue de fondations,
qu'on projette moyen terme de venir changer le stockage de pulsar
pour du foundation.
Alors en fait, nous, l'intérêt qu'on voit, c'est d'avoir entre guillemets
une équipe opérationnelle foundation qui va s'occuper de n-cluster,
et après tout autre problématique data n'est qu'une couche stétlès par-dessus du foundation.
Et donc en fait, on pourrait pulsar à une très bonne séparation du stockage
avec BookKeeper.
Aujourd'hui, nous, on commence à taper des limitations
de BookKeeper et des limitations de ZK avec un usage pulsar,
notamment avec les logs et les access logs.
Et bien en fait, on commence à se dire qu'on aurait un intérêt très fort
pour venir mutualiser ses stacks et faciliter le truc.
On recrute d'ailleurs By the way sur ce genre de postes.
Aujourd'hui, BookKeeper, il stock dans du HDFS ou il stock sur BookKeeper ?
Non, BookKeeper, c'est lui qui stock directement.
Si il stock directement, il n'y a pas de sous-system.
Il a un stockage à lui ? Je croyais qu'il s'appuyerait sur du S3,
sur l'HCLA dans le mode cas.
Non, BookKeeper s'appuie sur du ROX DB en interne.
En stockage local.
Oui, d'accord. Il n'y a pas un composant supplémentaire un peu comme HDFS,
pardon, comme HBase, puisqu'on en parlait au bout de l'an dernier épisode,
lui stockait sur du HDFS.
Non, t'as pas d'indirection.
Si on parle de pulsar, tu peux stocker ton topic dans du S3,
pour avoir des topics avec beaucoup d'historique de données.
C'est un direction-là entre le monde chaud de BookKeeper et le monde froid de S3.
En fait, elle est gérée par le broker.
C'est l'interface, c'est le managed ledger qui est une interface
qui gère cette complexité-là.
Donc, en fait, BookKeeper, c'est juste du stockage chaud pour du pulsar.
Et aujourd'hui, on voit quelques limitations assez claires sur ce système-là.
Et nous, on a tout intérêt à mutualiser ces infrastructures-là
pour faciliter l'opérationnel et avoir un seul système, en fait.
Par contre, puisque tu en parles, tu sais, quand tu utilises du hashbase,
tu pouvais aussi passer en mode Mabridius, que ce soit pig ou autre,
pour aller directement accéder ta donnée sur HDFS,
est-ce qu'il te soulageait de l'accès hashbase qui était très à 8 en réel
avec des curseurs, des scannes, etc.
Et là, tu pouvais traiter massivement toutes tes données d'un coup,
puisque tu l'accéder au speed HDFS.
Et bien, dans pulsar avec Trino, tu peux faire quand même la même chose.
Tu peux utiliser le coordinateur Trino qui, par des workers,
va venir accéder directement au BookKeeper,
ce qui te permet de paralyser ton accès à la donnée.
D'accord. Oui, c'est le système de stockage, je crois.
Par exemple, dans un autre utilisateur de fondation,
c'est Wavefront qui font de la télémétrie pour du cloud native.
Ils ont directement du stockage chaud dans Fton, dans fondation,
et du stockage froid dans S3 pour de la time series.
En fait, c'est la laieur qui gère l'abiffurcation.
Fondation, c'est plutôt pas vraiment adapté forcément pour de l'analytique.
Tu dois un peu tordre le modèle pour faire de l'analytique sur fondation.
Après, ça marche bien.
Un Ousur Warp, c'est un usage très analytique qu'on a pour venir calculer la facture.
Par exemple, en fait, ça marche très bien.
C'est juste qu'il faut savoir que chaque transaction a une durée limitée dans le temps
et que tu ne peux pas balader un curseur sur trois heures de données.
Ton curseur est plutôt limité,
mais tu peux faire des choses orientées analytiques.
C'est juste que tu dois...
Il faut avoir en tête que la transaction ne dure pas longtemps.
Une transaction, c'est cinq secondes et ça peut toucher que dix méga de données.
Donc, c'est à toi de designer le système en fonction.
Ça sent le stockage plus efficace pour de la lecture de masse.
J'imagine que pour du clé valeur, tu ne vas pas avoir la même organisation
que un fichier parquet où tu as touché dans le bon ordre
pour faire une aggregation et par contre, tu n'as pas mal à écrire.
Si tes clés sont contigus, ça marche très bien le scan.
En fait, c'est ta représentation et c'est ton data modèle que tu dois optimiser
pour que les clés soient contigus et que tu lances ton scan.
Après, ça ne peut être aussi intéressant.
Par exemple, si tu veux taper si tu veux faire une dizaine de scans,
tu veux peut-être les répartir sur dix machines différentes.
Et du coup, pas avoir les netflix de clés.
Je pense qu'il faut sortir d'un paradigme tel que celui de parquet.
Si on devait faire ça.
Moi, première réflexion que j'ai en me disant si je devais faire ça,
je prendrais un format de sérialisation de données comme EUROW.
Je prendrais les groupes dans le registrement des colonnes EUROW
et je les mettrais à l'intérieur de la fondation.
Mais la toute, tu es en train d'agréger tes données
alors que l'idée de la base transnactionnelle
c'est d'avoir les données enregistrées une par une.
Jusqu'à un certain point.
Si tu veux faire de l'analytique.
Oui, je suis d'accord.
Mais tu es en train de reconstruire ton format parquet.
Si tu fais, tu es en train de te bloquer.
Oui, effectivement, la limite.
Ce qui me faisait dire ça tout à l'heure,
c'est que je pensais au modèle Cassandra.
On nous avait dit que ça marche bien avec un Spark et machin.
Et puis, en fait, pas forcément.
Mais c'est vrai que le clé étant trié,
si le stockage reflète ce tri,
j'imagine que c'est le cas.
Peut-être. Tu me corrigeras si je me trompe.
Effectivement, il y a moyen que ce soit plus performant
qu'un système où tout est réparti.
Oui, c'est bien d'ailleurs.
Pour aller dans le sens de ce que Jérôme vient de dire,
on est bien dans un cas de figure de clé lexicographique
qui sont avec un ordre de tri,
comme dans beaucoup de systèmes, finalement,
de cas vies distribués.
Et pas forcément au final.
Tu ne suis pas forcément d'accord,
parce qu'en fait, tu retrouves l'extraction du clé valeur,
tu la retrouves énormément dans le droit.
Moi, l'endroit le plus surprenant
où je retrouve un monde de clé valeur,
c'est dans PostgreSQL.
Si tu descends dans le moteur de stockage,
tu manipules des blocs de data.
Et ces blocs-là, en fait, c'est un tuple ID
qui correspond à une clé valeur.
Si tu regardes le moteur de stockage PostgreSQL,
comment il accède à ta donnée,
au final, c'est un accès clé valeur.
C'est juste que l'abstraction qu'on te fournit
sur le file système, c'est du bloc.
Mais du coup, par-dessus du bloc, tu recrées du clé valeur.
Donc, en fait, au final,
beaucoup de choses sont clé valeur dans notre monde.
C'est juste que ça dépend de la représentation.
Oui, beaucoup de choses sont clé valeur.
Et ça veut dire quand même que si jamais
qu'il faut, comme dans tous ces systèmes clé valeur,
ça va être hyper directif pour la suite de ta vie,
la manière de laquelle t'as défini ta clé au départ
du d'application, on se retrouve dans les mêmes sujets
que pour ceux qui ont eu la chance de faire un peu de design
dans Cassandre, par exemple,
où la définition de la clé avait un impact démesuré
pour la suite des événements.
Et si jamais ton use case changait un petit peu
le château de carte d'émoeuvre.
La grosse différence, c'est que Cassandre,
les clés n'étaient pas classés.
Et justement, ça a compliqué l'analytique.
Sauf à les chercher un bloc.
Ça a évité les scans efficaces.
On parlait dans l'épisode précédent de la record layer
et de Cloud Kit et de tout le cloud d'Apple.
En fait, la première version de Cloud Kit,
c'était sur du Cassandra.
Il y a même un papier de recherche qu'on peut retrouver
qui explique toutes les limitations
et tous les problèmes qu'ils ont tapés
en utilisant Cassandra pour stocking ça,
puisqu'Apple est un gros utilisateur de Cassandra de base.
Mais après, deux ans, deux, trois ans plus tard,
ils ont ressorti un autre papier,
c'est le fameux papier de la record layer avec fondation.
Ils expliquent en fait le gain qu'ils ont eu de passer
de Cassandra à fondation.
Et les deux papiers sont assez intéressants à lire
coup sur coup.
J'ai fait les college base, donc je connais mal Cassandra.
Mais le papier met en avant les différences
et c'est très agréable de lire les deux papiers
coup sur coup.
On a un peu divergé ce format de chiffre.
On a un peu divergé, oui.
Si on revient, tu nous as parlé tout à l'heure
du premier usage que vous avez eu
qui a été de faire ce swap
à Edge Base,
vers fondation DB, pour stocker la time series.
Et puis, j'imagine que ça, ça s'est bien passé pour vous.
Vous avez été très content de ce que ça fait.
Et vous êtes dit qu'est-ce qu'on pourrait faire d'autre
avec ce machin ?
En fait, ce qui s'est passé, c'est qu'en parallèle,
on a commencé à travailler sur la fameuse boîte à outils
qui vrapent les fonctionnalités fondation.
Je parlais dans l'épisode précédent d'un ORM.
En fait, on a une librairie qui vrapent toute la complexité
de manipuler du fondation.
Et du coup, ce framework-là,
il nous permet d'instancier des produits
multi-tenants de Serverless.
Et quand je dis Serverless,
c'est vraiment, on est dans cette idée-là que...
En fait, ce qu'on fait, c'est qu'on a virtualisé la base de données.
Donc, en fait, on a créé une notion de base de données logique.
Une base de données logique, c'est un espace de clé
réservé à un utilisateur.
Et dans cet espace de clé-là,
il va contenir des métadattas, la data, les index,
les statistiques, etc.
Et donc, en fait, ce qu'on fait, c'est qu'à chaque transaction,
on utilise très fortement le modèle transactionnel de fondation.
Et donc, en fait, entre guillemets, à chaque transaction,
on vient ouvrir cette base de données logique-là et on la manipule.
D'où le fait qu'on est vraiment Serverless,
parce que si un utilisateur n'utilise pas sa base de données,
il n'y a que l'empreinte disk qui est utilisée.
Et donc, en fait, à chaque requête,
c'est vraiment comme ça qu'on a construit notre framework.
Notre framework, c'est chaque requête,
tu vas venir faire un open de la base de données
et tu vas lire le header qui va te donner 2-3 infos.
Et puis après, si tu fais un store, si tu fais un scan,
si tu fais une suppression,
en fait, on reflète les clés-value,
la manipulation des clés-value.
Et après, à la fin de la transaction, on commit.
Et du coup, en fait, la base de données,
elle est logique dans le sens où elle est représentée
que à l'instant de la transaction.
Et donc, en fait, ça, c'est ce modèle-là.
Donc, on a repris le modèle de la record liar et d'Apple.
Et donc, en fait, c'est ce qui nous permet d'instancer
des mini-bases de données logiques
de façon complètement linéaire en fonction du cluster fondation.
Et donc, le premier produit qu'on a créé avec ça,
c'est le Materia KV.
KV pour clés-value.
Donc, je ne sais pas si Steven,
tu veux peut-être en parler ou ratio, d'ailleurs.
Sur quel aspect ?
La spécifie.
La spécifie produit ou...
La spécifie produit, je pense que c'est intéressant.
Et c'est un peu technique.
Pourquoi on a commencé par le KV ?
Parce que c'est aussi le plus simple pour...
C'est direct, comme je le disais, effectivement.
C'est à peu près direct.
Il y a quand même beaucoup de travail derrière,
parce qu'il n'y a pas que de clés-value derrière.
Il y a aussi des notions d'index secondaires,
des notions de query-planers,
on en parlera peut-être après.
De TTL.
Donc, tu as quand même des petites briques à mettre en plus.
Mais de toute façon,
toutes ces briques-là que tu construis progressivement,
tu en auras besoin pour les autres typologiques stockages,
que ce soit le SQL, le document ou autre.
Mais sur l'aspect primaire,
ça se transpose assez directement.
Et donc, c'est toujours plus facile de commencer par ça.
Ça se transforme assez vite en produit,
ce qui fait que tu as aussi une valorisation assez rapide de cette ingénierie.
Ce qui n'est quand même pas négligeable non plus.
Ça te permet quand même de tirer parti de toute la recherche que tu mets derrière.
Et de coup, en plus, on a des besoins,
nous, de gérer les sessions PHP,
qui peuvent être faites en Redis, par exemple.
Ce qu'on a fait, c'est que, du coup,
derrière matérie à KV, en tant que produit que tu peux consommer directement,
aujourd'hui, tu es capable de dire que les sessions PHP, en fait, elles reposent dedans.
Et donc, nous, ça nous est...
Et c'est une API Redis.
Vous exposez une API Redis compétite.
Exactement.
Qui tombe bien,
et que Redis devient compliqué à utiliser.
C'est une bonne idée finalement.
Vu que Redis, en tant que tel,
devient compliqué à utiliser dans un environnement de Cloud Provider.
Alors, d'une.
Et de deux, comme l'a dit Pierre,
c'est que nous, la DB,
elle est jamais matérialisée en dehors du moment où tu interagis avec.
Ça veut dire qu'en fait, une DB,
une petite DB, elle a une empreinte qui est hyper faible, hyper fine.
C'est juste les quelques bytes qui sont dans un cluster stocké.
Et ça, ce qui est très intéressant,
c'est que ça nous permet d'avoir à la fois des tout petits besoins,
que ce soit, par exemple, des besoins en termes de dev,
d'intégration dans lesquels tu prends un token
et tu vas avoir quelques jeux de données, mais vraiment très faibles.
En fait, ça, ça coûte zéro.
Et aujourd'hui, le fait de devoir instantier une instance permanente
pour avoir un jeu de test qui va te prendre du CPU de la RAM dédié
pour des petits besoins, c'est un peu pénible.
Et en plus, la mise à l'échelle de ça,
c'est-à-dire que si ton usage grandit et que du coup,
tu n'as plus de place sur ton instance,
tu dois aussi passer à l'instance supplémentaire,
faire une migration.
Donc, tu as toujours les contraintes de l'infrastructure,
là ou avec matériel, mais en fait,
tu es compatible avec le très petit utilisateur.
Mais quand tu tires l'usage,
c'est uniquement une gestion de quota
que tu vas toi en tant qu'utilisateur définir
pour ne pas s'atturer, ne pas plafonner
ou exploser ta consommation.
Mais, comme tu es sur un socle distribué nativement en dessous,
il n'y a peu de limites en termes de nombre de connexions parallèles,
de volume à héberger, etc.
Donc, c'est très...
J'ai convenu, mais c'est de l'anglais, n'est-ce pas ?
C'est très confortable pour un développeur
d'avoir des solutions de type serverless,
parce que tu te poses zéro question d'infrastructure.
C'est en ta compagne en fonction de ton besoin.
Et de votre côté,
comment est-ce que vous faites
pour vous prémunir d'une contention de ressources,
du fait que vous puissiez avoir, à un moment donné,
un pic de sollicitation
et éventuellement, peut-être garantir...
Comment est-ce que vous faites pour garantir à SLE
autour de cet entente qui est hyper mutualisé, finalement ?
Ça se fait par...
par principe déjà d'observabilité de la plateforme.
C'est-à-dire que quand tu vois tes charges, tes pics,
que tu apprends sur les saisonnalités de consommation de ton service,
tu sais que tu dois toujours prendre
l'équivalent de ta vague et le haut de ta vague,
à ton pic.
Donc après, c'est du capacity planning, classique.
C'est-à-dire que plus le service va monter
avec ses vagues de consommation,
plus l'une va tirer la vague du haut
et on va l'estimer.
Et ouais, c'est la problématique opération.
Non, non, mais Steven, je me doute bien que c'est ce que vous faites,
mais c'est plus pour les auditeurs
pour qu'ils se rendent compte que un service serverless,
il y a quand même de l'opération
pour garantir que service serverless puisse qu'elle est correctement...
Et c'est un truc qu'on a tendance un petit peu à oublier,
de se dire, pardon, de parler du diable,
mais pour vous, quand on utilise des lambes d'âme,
on dit, oh bien, ça répond tout le temps.
Ouais, il y a quand même du taf pour que ça répond tout le temps.
Donc vous n'imaginez pas que vous allez pouvoir refaire ça
dans votre garage très facilement.
C'est foncièrement, les gens ont tendance à pu mesurer
la quantité d'effort qui est nécessaire
pour pouvoir faire...
pour pouvoir faire... fournir ce genre de service à l'échelle.
Ça marche toujours bien avec deux utilisateurs.
Si tu...
Ouais, et puis si tu tires le trait,
t'as toujours des gens qui te disent,
ah ouais, mais bon, vous faites un passe,
mais moi, regarde, sur mon cube, je t'installe mon soft de passe.
Bien sûr. C'est exactement à ça que je pense.
Rien à voir. En fait, ce que consomment les gens,
c'est du service manager,
monitorer avec un interlocuteur, etc.
En fait, la question, et tu parles effectivement
de oui, ça marche dans ma cuisine avec deux personnes.
Bon, même sans parler de volume, c'est...
le jour où tu as un problème.
T'es prêt à aller mettre les mains dedans,
à creuser le sujet, à monter en expertise sur ce...
C'est ça que tu veux faire,
ou est-ce que tu n'as pas un autre métier vraiment qui t'attend à côté, quoi ?
C'est l'éternel sujet de...
J'utilise de l'open source, parce que ça va me coûter moins cher,
mais j'ai pas envie de devenir contributeur,
et donc, je n'ai pas envie de plonger
et de devenir hyper compétent sur le...
sur le frein, moi, en open source.
Et ça, c'est l'éternel.
Mais j'ai envie de être destrante tous les semaines,
de me veiller à 3 heures de matin,
de devoir arrêter de 3 deffes pour être très obs
de la solution que j'ai mis en place aussi.
Parce que c'est une autre partie que les gens ont de mal à voir suivant,
effectivement, tu peux avoir ton cube dans ton coin,
t'installer ton canatif et avoir une solution.
Fais, mais derrière, qui va opérer ce cube-là
en condition de production ?
Week-end, vacances, nuit, etc.
Et simplement, c'est parti là, c'est déjà un reality check.
Et tu parles du coup,
le truc, c'est que quand tu fais la somme des coups
pour être en capacité de production pour ton enjeu,
qui est ton métier, c'est-à-dire que ton compute,
tu dois avoir 5 personnes
pour pouvoir faire tourner l'orchestration,
ce qui est du ligne, etc.
pour avoir une gestion d'astreinte
et avoir des gens qui crâment pas en permanence.
Les bases de données manager, même topo,
et puis, si tu imagines avoir des services un peu plus haut niveau par-dessus,
en mode passe, etc. auto-gérée,
tu te rajoutes encore 5 personnes.
Donc là, tu arrives déjà à minimum 15, 20 personnes
juste pour faire tourner ça.
Et je ne te parle pas des interconnaiteurs,
des antidès d'eau, tout ça.
Donc ça va vite, ça va très vite en fait.
C'est une question de c'est quoi vraiment
le métier de la personne.
Si quelqu'un est en décembre,
tout ce que tu viens de dire,
ce n'est pas leur métier à la base.
Si ils sont prêts à investir
dans une équipe d'inventaine d'obs
spécialisé dans les différents briques,
pourquoi pas, sinon,
on voit possible l'intérêt des services manager.
Tu vois, petit aparté,
mais tu as toujours des gens qui pensent mieux
que toi, quelles sont tes contraintes
et quelle est ta vie, tu vois.
Et quand l'autre jour, j'ai posté sur Twitter
que, ben regarde, on a notre cluster cube
qui tourne et qu'on est en train de raffiner
pour livrer nos premiers utilisateurs avec,
il y a des gens qui sont venus
challenger, ce qui est bien,
et qui posent des questions.
Et en fait, dans une des questions,
il y avait, comment vous avez géré les méta, etc.
Nous, en fait, on refuse de mettre
du cluster RTCD pour plusieurs raisons.
La première, c'est une base de données lente
qui fonctionne mal, qui passe pas à l'échelle.
La deuxième, c'est qu'on a tenté
de contribuer pour assigner des trucs
et qu'on n'était pas du tout satisfait
du niveau des mainteneurs de la solution à l'époque.
Peut-être que ça a changé, mais j'en sais rien.
En tout cas, à l'époque, ça m'a convaincu
que c'était pas une bonne technologie à utiliser.
Et la troisième, c'est que si on commence
à cultiver des clusters ETCD en pagas y a côté,
c'est que moi, pour mes clients
et pour avoir un niveau de qualité suffisant
et que tu parles de SLA à juste titre,
j'ai besoin d'une équipe qui gère ça
et qui a donc les compétences opérationnelles
sur l'ETCD.
Ce que je n'ai pas du tout envie d'avoir,
je préfère avoir une très bonne équipe,
très compétente sur Foundation et un layer ETCD
qu'on développe parce qu'on a les capacités
de le développer et que ce n'est pas si cher que ça.
Et à ce moment-là, je consolide
avec une très bonne expertise opérationnelle
sur Foundation qui est une technologie
qui est bien meilleure que TECD.
Mais il y a des gens qui vont dire,
ah oui, mais du coup, vous faites de la prémature
optimisation.
Mais pas du tout, en fait, c'est même pas la question.
C'est un problème opérationnel pour faire
un service de qualité parce que si je fais ces faits-là,
j'ai automatiquement la gestion des backups,
des snapshots, de la restauration, etc.
Je gagne le forking de DB,
je gagne énormément de choses qu'on a développées
par le SDK qu'on a fait sur FoundationDB.
Ce que ne voient pas les gens,
mais peut-être toujours des gens qui te tirent des conclusions
sans avoir tout le temps de contexte.
C'est toujours formidable.
Je dois rappeler que la prémature optimisation,
c'est pas...
L'éviter, c'est pas attendre que ce soit le feu en production.
C'est pas prématuré que d'un arzine et des problèmes.
Et puis, c'est toujours des gens un peu consultant
qui, quand ils bossent, ils bossent sur une installation.
On est provider.
Tu sais que quand tu ouvres un service,
tu as des centaines et des milliers de clients
qui vont utiliser ton service derrière.
Oui, tu participes d'un problème.
Oui, donc en fait, tu sais que
si tu n'anticides pas de trois problèmes,
tu t'es sous l'eau premier jour.
Et on doit anticiper ça.
Et donc, c'est plus de la rationalisation
de stratégie de déploiement
que l'optimisation de performance en soi.
Et gestion de la main de la strainte, d'équipe de la strainte.
C'est de la honnête.
Oublier la gestion de cette équipe,
de planines, de nombres de personnes nécessaires,
de compétences de ces personnes-là, c'est...
Mais après, aujourd'hui, Claver, c'est entre 80 et 100 personnes.
Les gens nous posent toujours la question,
mais comment vous faites pour faire tout ce que vous faites
à vos nombres que vous êtes ?
C'est justement parce qu'on se pose des questions comme ça
et qu'on rationalise certains choix
pour ne pas courir derrière énormément de choses.
C'est pour ça que Pulsar, on essaie de l'amener
avec Fondéchaing qui remplace à la fois zookeeper et bookkeeper,
parce que ça va nous solutionner
l'aspect opérationnel à l'échelle
sur cette solution-là, que pour Kubernetes, c'est pareil, etc.
On se solutionne énormément de problèmes par des choix technologiques.
Et après, ça veut dire qu'il va y avoir un peu de maintenance
à faire sur les différents layers qui vont être au-dessus.
Mais finalement, d'un point de vue production,
je vais pas dire peu de travail,
à partir du moment où vous garantissez que ce qui est en dessous du layer
correspond bien à ce qu'il y a dans la simulation au départ,
que l'usage que vous faites dans le layer de ce qui est en dessous.
Alors comme vous disiez tout à l'heure, qu'en plus vos layers,
maintenant si j'ai bien suivi votre SDK Rust,
vous permet de les simuler, les inclure dans la simulation.
Donc vous vous trouvez dans une situation où au final,
vous avez une certitude que vous n'allez jamais avoir un changement
qui va tout casser.
Et surtout, ce qui est bien l'autre point bénéfique de ce modèle-là,
c'est que ce n'est pas forcément les mêmes ingénieurs
qui vont contribuer dans un système ou dans l'autre.
Par exemple, pour contribuer à notre SDK,
il faut avoir des connaissances en fondation,
il faut avoir des connaissances en multi-tenant de si,
en système distribué, en pas mal de choses.
Mais la couche au-dessus,
tu n'es pas obligé d'avoir cette connaissance-là.
Tu peux utiliser l'abstraction
qui t'est fourni pour construire des choses.
Et nous, pour le KV,
j'aime bien donner cet exemple-là,
on a une compatibilité REDIS.
Et donc en fait, on comprend le protocole REDIS nativement.
Et du coup, ce qu'on a fait par exemple,
tu vois, dans REDIS,
tu as un JSON qui te décrit l'aspect protocole.
Donc en fait, un JSON qui te permet
de décrire l'aspect communication TCP pur.
En fait, nous, ce qu'on a fait,
c'est que, ça nous a pris un peu de temps,
c'est qu'on a auto-généré le code
du parceur du protocole REDIS.
Et ça, tu vois, c'est des problématiques rustes,
pure de programmation, pure,
mais ce n'est pas des problématiques système distribuées.
Et du coup, le fait d'avoir cette séparation-là,
ça nous permet d'inclure et de scale
l'équipe d'ingénierie
sans qu'ils aient besoin d'être experts
des voitures dans les cas deST��
fléchpunkt, en formation jun.
Vous резemez à compter d'autre macros,
�� l'épidémie deють,
ou telle la глубocité

Maintenant, c'est trop vagable,
parce que ça rend hâte de se sonovrir

et j'ai incité le!
Église de compter dans une carnetide,
mais là du basse du بدpan,
Et pour une petite boîte comme nous, parce qu'on reste petit, quand même comme boîte,
bah en fait c'est tout bénéf.
Avant de revenir sur les challenges autour de votre boîte à outils et de ce que vous
avez pu faire en termes d'intégration, je voudrais revenir un tout petit peu sur les
usages dont on parlait à l'instant.
Aujourd'hui dans votre gamme de produits, vous avez des bases de données manager, donc
on peut récupérer une instance PG.
On peut récupérer, j'ai pu une MySQL, on peut récupérer plein de choses.
Demain, est-ce que vous pouvez imaginer que vous ne déploirez plus une PG classiquement
comme vous la faites, mais que vous déploirez un layer qui s'appuie sur foundation DB.
Est-ce que c'est un truc que vous imaginez ou est-ce que pour vous c'est encore ou très
prématuré ou à non sens, parce que tout ne peut pas être fait dans un mode serverless ?
J'ai envie de te dire que c'est pas forcément notre choix, c'est-à-dire que nous on prépare
l'avenir avec des solutions complémentaires en termes de serverless, mais c'est pas nous
qui allons décider si c'est un choix ou l'autre, c'est plutôt le client final, l'utilisateur
et parfois le mode instantier il est aussi très rassurant, très prédictible en termes
de prix et tu vas voir des gens qui vont préférer payer plus cher, mais la même chose tout le temps
avec une instance qui te garantit des ressources etc.
Donc techniquement, technologiquement, si tu me poses la question, j'ai envie de te dire
que demain le serverless peut quasi tout gérer, je ne vois pas de limitation à comment on pourrait
faire les choses, puisque après c'est qu'une problématique d'orchestration, même la notion
de cache, d'index etc. tout ça se résout.
Tu as des gens aujourd'hui qui quittent le cloud pour reconsolider on-prem, donc
j'ai pas de boule de cristal.
Tout le droit des moments d'égardement, tu sais.
Non mais moi je crois dans donner des options au client il y a effectivement
des raisons objectifs, subjectifs particuliers qui font que certains clients
va préférer une solution ou une autre.
Nous on crée les socles de technologie, on crée les produits qui vont avec.
Je pense pas que
que tout le monde va partir sur les serverless, je pense qu'il va y avoir des gens qui vont
continuer avec le même modèle d'instance dédié, même sur la partie redis par exemple,
nos instances redis ne vont pas disparaître parce qu'il y a des matériaux à caber,
et vont être complémentaires.
Il y a autant de use cases de raison que de boîte, donc c'est bien de donner les soirs.
Et c'est pas parce que tu as deux produits que tu peux pas créer des interactions, tu vois non,
là on est en train de, on a pas mal avancé sur la compatibilité redis,
mais en fait on peut imaginer les trucs rigolos, on en avait discuté avec un client qui voudrait
par exemple qu'il ait une vraie redis en leader et une matérie à en follower.
On peut faire des trucs un peu rigolos ou en fait il peut se dire qu'il peut faire du...
Ta base de QA qui sert une demi heure par jour pour passer les tests,
tu l'as fait dans une matérie à, parce que tu sais que tu vas l'allumer,
tu vas avoir un nombre de transactions dessus très limitées.
Par exemple un usage qu'on a dans fondation, tu as une solution de backup qui est extrêmement
efficient où tu peux restaurer à la transaction près le backup.
En plus de ça, tu as la capacité de changer le préfix de clé.
Nous on peut cloner des bases de données logiques puisqu'on peut cloner et bouger
des préfixes de clé.
Tu vois par exemple une entreprise qui veut avoir son environnement de dev avec
je dis n'importe quoi g-2, les données de g-2 de prod mais qui est effacée tous les jours,
bah en fait pour nous, on l'a pas fait encore mais c'est des choses qu'on imagine pouvoir
faire et ça c'est quand même assez pratique à utiliser, c'est de l'usage et c'est super intéressant.
Ça ouvre des possibilités et c'est toujours une bonne chose d'avoir plus de possibilités.
Tout ce qui est shadow db, forking de db, tout ces trucs là sont super.
Ceci dit, ils vont corriger si je me trompe mais finalement le fait d'avoir du
à la demande ou pas c'est aussi une question de facturation, c'est-à-dire tu peux avoir le
même système technique qui serait server-overless et puis avoir, parce que clients préfèrent
ce mode là, un mode, comment dire, un forfaitaire où ils payent un montant fixe et puis peut-être qu'il y a des
jubéchines qu'on pourra faire des trucs comme ça.
De toute façon, on cléveur à vocation à être déployé on-premise dans les data centers,
donc en fait on va devoir déployer par exemple, tu vois, ce qu'on appelle un cluster matéria,
il sera commandé entre guillemets, tu vois, chez clients ou chez nous et en fait tout a été
conçu pour faire ça, c'est-à-dire que tu vois, s'il y a un utilisateur à un moment,
veut un cluster dédié matéria, il peut le demander, il peut le nous le demander,
s'il veut un cluster matéria on-prem, on n'en a pas encore mais on ne empêche de le faire.
Et on avance dans cette direction là.
Ouais, c'est-à-dire qu'après il y a la différence, je veux du vrai parce que
je veux être sur 100% de la comptabilité et de la compatibilité où j'ai pas besoin et...
Ça risque après de poser un souverain sur la capacité, je repense au parallèle tout à l'heure de dire
vous avez plus... pour Wharpten, qu'est-ce que vous avez fait ? Vous avez fait un layer
qui permet de récupérer des appels de l'API HatchBase et de les écrire dans Foundation ou est-ce
que vous avez changé dans Wharpten pour qu'il puisse y avoir un driver, enfin entre guillemets.
Driver, le jeu. Non, non, driver.
Driver ? Ça risque d'être driver.
Un driver Foundation DB pour Wharpten. Pourquoi je pose cette question ?
Parce que de mémoire, l'une des contraintes de Wharpten c'était de pouvoir avoir accès à l'instant
à HatchBase et d'installer les coprocesseurs qui faisaient que Wharpten ne pouvait pas tourner
sur n'importe quel HatchBase. Alors le coprocesseur était surtout lié à une histoire de suppression
qui, la suppression dans HatchBase était un sujet très compliqué, c'est-à-dire si tu voulais
faire un dealit sans TTL, c'était l'enfer sur terre en termes opérationnels, c'est-à-dire
moi je me souviens avoir vu passer des dealits sur un cluster HatchBase et genre tu perds,
tu vois, tu as ta courbe d'écriture et puis elle est divisé par deux parce que tu as eu
un petit pic de suppression, tu vois, qui est en train d'être digéré et c'était surtout lié à ça.
De mémoire, les développeurs de Wharpt ont changé le driver de la base et il y avait 3-4 classes
qu'il fallait changer, donc la modification se faisait bien. Donc le sujet de Wharpt est un peu à côté
de tout ce qui est construit à côté du SDK, c'est-à-dire qu'il y a l'univers Wharp et l'univers
matéria SDK entre guillemets. Et donc l'SDK, nous, pour le KV, on fait de la partie, on est compatible
Redis, mais en fait, comme on manipule le data model, en fait on peut fournir autre chose et tu vois,
par exemple, on travaille aujourd'hui avec un client qui a du Dynamo et qui est Lock-in sur du Dynamo.
Et en fait, on est en train de travailler avec lui sur le fait de fournir une compatibilité Dynamo
dans le KV et comme c'est le même data model que tu exposes à travers deux protocoles,
en fait tu peux taper en Redis ton espace de clé Dynamo et donc ça c'est un truc qu'on est en train
de travailler avec eux, c'est vraiment un aspect migration et éviter d'avoir du Lock-in Dynamo.
Après Dynamo, tu peux avoir un peu de complexité sur les histoires de clé, d'index secondaire,
de choses comme ça qui peut être un peu pénible à gérer, mais sinon c'est vrai que Dynamo,
c'est un clé valeur au départ finalement.
C'est très simple, ça m'a fait beaucoup rire parce que les développeurs de l'ailleur chez nous,
en fait ils ont fait Redis, donc tu vois, ils ont fait la compate avec les 600 commandes Redis
et puis à un moment, ils allaient voir la Doug de Dynamo et il a fait, mais du coup il y a douce truc à faire.
Enfin ça va être...
Ouais, les primitives et dynamo sont très très courtes, il n'y en a pas d'étonnes.
Ah tu pourrais nous faire avec...
On s'implique, tu as un peu de filtrage qui rende...
Ouais, un peu de ridicule...
On est à 3% des capacités, on virtualise la base de données et qu'on l'instantcie par transaction,
on hérit des problématiques de transaction de FDB avec des DIMEG et compagnie,
avec Dynamo on est largement en dessous, donc en fait on n'a pas de problème.
Et c'est assez rigolo de voir, après Dynamo est vieux, enfin...
Mais oui c'est un vieux produit qui aujourd'hui, pour plein d'usages,
permet de faire des trucs qui marchent très très très bien.
Il y a encore des projets qui démarrent avec Dynamo aujourd'hui.
Donc...
Ah bah je ne pousse à fond, parce qu'en plus, c'est un vendor locking.
Et bientôt la fin du vendor locking.
D'ailleurs la question, parce qu'on parlait de vendor locking,
je me lance sur MatériaDB, je ne vais pas le retrouver chez un autre cloud.
Aujourd'hui, qu'est-ce qu'on offrait comme garantie, surtout que...
Je vais aller dire, si je suis un décideur, me verrouiller avec Amazon,
j'aurais jamais vraiment tort, alors que me verrouiller, je suis un petit acteur de Bretagne.
Mais justement, si je ne te verrouille pas, on est protocole redis.
Si tu n'aimes pas ça, tu peux t'installer dans un cluster redis classique sans problème.
Demain on fera la compatibilité Dynamo, mais tu peux toujours retourner
chez ton géant transatlantique favori si ça te plaît pas.
La idée même d'être de faire de compatibilité avec le protocole standard,
c'est qu'il n'y a pas de vendor locking.
Et que tu peux refer la mention d'un autre provider ou un premier,
c'est d'utiliser d'autres technologie, même si tu n'es pas redis,
tu n'en as pas le temps de faire un recul de recul et de l'actualité.
Donc la compatibilité du protocole fait que les protocoles deviennent vraiment
se quitter à sûr que derrière, tu peux partir à une certaine amplémentation de ce protocole,
la dont matérieux, amplément de redis, amplément de dynamo.
Et toi, si ça te va, c'est très bien.
Si ça ne te va pas, ou même le restant c'est clair, parce que pourquoi pas,
mais tu vas avoir ton instance de dieu parce que ce truc là de server les,
tu finis par, tu vas savoir que tu vas payer x euros par mois,
parce que tu prends une instance classique et tu n'as pas fait cet exemple dans plus d'un plus cher streaming
que tu as fait, tu sens les impôts de redis, de matérieux à une instance redis,
tu n'appliques pas le modulo que tu migres à te donner,
tu n'appliques pas continuer à marcher comme ça devrait.
Juste man, on n'est pas un vendor lock-in, on n'est pas des tout de vendor lock-in,
c'est que on aime se donner les chouaneaux clients.
On est même dans l'une des prochaines tâches qu'on va faire côté KV,
et alors les devs de mon équipe se hurlent, c'est de pouvoir récupérer un backup au format redis.
Tu vois, par exemple, parce que nous on a un backup fondation,
et on a un backup fondation du SDK, du machin, du truc, donc tu vois, quand on veut fournir
le backup, pour pouvoir faire le temps, qui puisse le réimporter dans sa redis,
tu vois, le format redis n'est pas très documenté sur cette partie là,
tu vois, il n'y a pas beaucoup de gens qui s'amusent à réécrire le format redis de backup,
tu vois. Je suis un peu fou, j'ai décidé, parce que Lya, si tu ne parles pas de Lya,
tu es un gonasse quand même, et je me dis, je ne suis pas mauvais en base de données,
je me dis, tiens, j'ai fait une vector DB, parce que c'est pas marrant.
Donc, est-ce que je pourrais implémenter ma vector DB, la déployer dans un scaler chez vous,
et avoir un accès, et dans ce scaler, je mets mon layer, je mets mon layer fondation,
et avoir accès au cluster fondation, sans passer par les layers que vous avez déjà développés.
Alors, aujourd'hui, on est les seuls utilisateurs de notre cluster fondation,
mais il n'y a pas de... enfin, il n'y a pas de société de consulting fondation,
n'y a pas d'hébergeur cloud qui fournit du foundation DB as a service.
Malgré tout, la communauté demande d'avoir ce genre de truc si un jour on nous dit,
« Bah, on vous... »
Quelqu'un a besoin d'un cluster fondation dédié, foundation DB dédié,
bah en fait, on pourrait se dire qu'on le fournit en tant qu'un adonne,
et de toute façon, pour être clair, on doit aller nous dans cette direction-là,
en tant qu'hébergeur et pour industrialiser.
C'est-à-dire que nous, notre but, c'est qu'en fait,
tu commandes ton cluster matéria-wendlich et tu l'actives le mode matéria, tu vois.
Et au final, nous, on doit aller vers là.
Alors aujourd'hui, on le dépose en hand-sibel et compagnie,
mais comme c'est notre volonté, en fait, d'industrialiser cette partie-là,
ça a pas répondu à telle question.
Oui, si, si, si.
Parci du...
Juste pour faire une précision par rapport à ça, c'est aujourd'hui,
quand je vais demander une matéria-kv,
c'est un cluster qui est manager par vous, qui est mutualisé.
Je n'ai pas une matéria-kv qui est sur un cluster foundation dédié.
Ça ne fait pas partie des choses que je vais avoir.
Ça coûterait un peu cher.
Après, tu peux nous le demander.
Je me doute, je me doute, je me doute bien sûr.
Ça sera très cher, mais...
Mais par exemple, tout à l'heure, Pierre parlait de clevercloud,
à vocation à pouvoir aussi s'installer un premise,
un premise chez un gros client,
là, il pourrait avoir un moment titre sur une matéria-kv,
mais le cluster sur lequel la matéria-kv offre public tournoiordi,
c'est un cluster mutualisé par construction.
C'est d'ici que si tu as un tout petit truc, tu vas payer presque rien, etc.,
c'est parce que tu es sur le cluster massivement multi-tenant.
Par contre, si je comprends bien, si tu offres ton service de fondation d'EB
sur lequel le client peut mettre un service,
sans l'aïeur ou l'aïeur à mettre par le client,
si je me l'ai compris, ça sera forcément un cluster pour le client,
au dédié au client.
Parce que si tu nous as dit l'épisode précédent,
que en termes de gestion de droit, c'est à accès ou pas accès.
Oui, là, ils sont en train de travailler.
Il y a des travaux pour ajouter de la vraie tenance d'en fondation.
C'est d'ailleurs Snowflake qui est un énorme sponsor de ce sujet-là
justement pour pouvoir fournir une couche d'identification, de chiffrement.
Tout ce que nous, on a dû recréer dans le SDK,
qu'il soit directement géré dans fondation.
Aujourd'hui, la contribution chez Snowflake,
c'est un peu compliqué.
Des fois, il développe des « proof of concept » dans la version open source.
Et ce n'est pas forcément totalement mergé upstream tout le temps.
Du coup, nous, on n'a pas voulu encore l'utiliser,
mais en tout cas, la communauté avance dans ce sens-là.
Donc, oui, c'est si on...
Nous, on maîtrise les gens.
Le SDK explique et gère la multi-tensancie pour nous.
Tu as par exemple pour Warp qui n'est pas inclus dans notre SDK.
Mais en fait, on a un cluster dédié parce que c'est plus simple.
Mais si un jour quelqu'un a besoin d'un cluster dédié,
on serait ravi de...
Ouais, mais tu vois, c'est lors d'une discussion...
Un grand nombre de grandes responsabilités, tu vois par contre,
parce que faut...
Voilà, c'est bien sûr.
Mais lorsque l'on discutait tout ça,
tu disais que ça reste un système distribué
qui complique et à bout de strapé,
sur lequel votre investissement, tout le monde n'est pas capable de le faire,
votre investissement que vous avez eu sur le produit.
Donc ça veut dire que moi demain,
si j'ai un usage qui fit super bien avec Fondation DB,
qui peut être très bien couvert en développant Alleyer,
je pense que si quelqu'un me propose de faire tourner le Fondation DB pour moi,
le calcul sera vite fait.
Mais on a des demandes de ça.

On a des demandes donc qu'on avance encore un peu sur...
Mais je pense que le produit est pas encore suffisamment diffusé.
Il n'y a pas encore suffisamment de gens qui ont compris
quel usage il pouvait couvrir avec.
Pourquoi ce serait un produit qui fit très bien?
On voit bien, ceux qui l'utilisent sont des gens qui ont des tailles monumentales
et donc qui ont une capacité d'investissement autour du produit qui est super importante.
C'est gentil de parler de tout comme ça.
Je vais revenir à cette vieille anecdote que j'avais eu un jour
de quelqu'un qui m'avait dit quand j'avais une petite boîte de consulting
et on ne faisait que de la data.
En face de vous, on a des gens qui font 20 fois votre taille.
Je leur ai dit, oui, mais il y a combien de gens dans ces boîtes-là qui font de la data?
Au final, vous vous rendrez compte qu'ils ne sont pas beaucoup plus gros que nous.
Au final, je ne sais pas combien vous avez été à vous intéresser au produit chez Clever Cloud,
mais il est vraisemblable que beaucoup de gens de très gros qui se sont investis dessus
n'ont pas forcément beaucoup plus de monde que vous.
On est toujours surpris de la taille des équipes qui sont hyper pointues.
Qui sont exactement ce que j'allais te dire.
On n'est pas très surpris de ce genre de choses-là.
Quand tu discutes avec les équipes opérationnelles ou les développeurs
d'autres ou grosses boîtes sur lesquelles tu dis,
« Waouh, il doit y avoir une armée mexicaine sur le soleil ».
Tu t'aperçois que des fois, tu es plus que eux.
Et en fait, s'ils sont trop nombreux, ça sera moins efficace et ce ne sera pas mieux.
Oui, c'est exactement ça.
C'est des gens très très capés, très très bons, vraiment très très bons et excellent.
Ils sont très peu.
Et c'est pour ça que des fois, on nous pose la question,
« Est-ce que vous avez les reins pour le faire, est-ce que vous êtes assez solides ? ».
Mais en fait, les gens qui posent ces questions-là ne savent absolument pas comment ça se passe dans ces boîtes-là.
Parce que vraiment, tu as peu de monde, c'est des équipes avec des gens très très bons.
Mais ils sont très très peu.
Et puis voilà, et vaut mieux une petite équipe hypercomité sur le produit qui se dédit à ça,
que des gens qui font ça parmi 50 autres sujets.
Pour aller dans ce sens-là, moi je peux raconter une anecdote qui est super rigolote.
On n'a pas parlé de l'histoire de fondation, mais je vais la faire très courte.
En gros, fondation, c'était une boîte, ça a été racheté par Apple,
c'est passé close source et après, c'est redevenu open source.
Ah oui, c'était rapide.
Les fondateurs sont partis et il y a certains fondateurs en fait de fondation,
donc vraiment les gens qui ont fondé la techno, se fondé de simulateurs,
qui ont été embauchés chez Spanner.
À Google.
Donc chez Google.
Parce que du coup, tu te dis, dans ton CV, tu as écrit fondation,
tu peux aller taper à peu près n'importe quel boulot dans nos très low level,
justement dans ces fameuses équipes qui sont un peu petites.
Donc Spanner, c'est la base de données phare de chez Google,
tout le monde en parle et compagnie.
Ils ont jamais réussi à faire, enfin ils ont travaillé sur Spanner pendant 2 ou 3 ans.
Ils ont jamais réussi à mettre en prod leur travail, leur MR.
Parce qu'en fait, ils n'avaient pas de simulateurs et ils n'avaient pas la capacité de faire du testing.
Et donc en fait, il y avait une vraie peur de l'impact d'un tel dev.
Et donc en fait, ils sont retrouvés coincés à faire du dev pour rien,
qu'ils n'ont jamais réussi à mettre en prod.
Et en fait, ça les a tellement soulé qu'ils sont allés monter une autre boîte à côté
pour faire du testing automatisé.
Parce qu'en fait, ils se sont rendu compte qu'il y a des boîtes.
Aujourd'hui, on est...
Alors c'est un peu frimeur de dire ça, mais avec le simulateur,
on fait des choses un peu mieux que Google d'un point de vue base de données.
Et c'est agréable de se dire que ce n'est pas forcément parce qu'il y a 40 000 personnes
dans une boîte qui travaille...
Enfin Google, c'est combien d'ingénieurs ?
90 000 ou 100 000.
J'avais un jour en Dix-Pen-Eurs.
Et j'avais entendu un jour parler notamment par exemple chez Apple
sur des produits logiciels que les équipes autour de trucs de feature d'IOS ou de macOS,
c'est 10 personnes.
Ben c'est 10 personnes.
Je pense qu'ils sont une quinzaine fondation sur chez Apple.
T'imagines ?
Nous, on est 6.
On est un tiers.
Il y a un tiers.
Et du coup, en fait, le truc, c'est qu'on dit 80 000 ingénieurs,
mais ce n'est plus les mêmes ingénieurs qu'à l'époque non plus.
Google a vraiment changé.
C'était une boîte d'ingénieurs, ça devient une boîte de consulting.
C'est pour ça qu'en fait, on n'en plus la maîtrise technologique sur certains domaines.
Il y a Spanner, les M.R. et leur entre plus.
Il y a plein de produits de Google où tout est en train de partir en Inde,
parce que la main, maintenant, se coûte moins cher.
Et du coup, ce n'est plus les ingénieurs qui ont conçu ces systèmes-là.
Maintenant, ce sont des ingénieurs qui maintiennent à feu doux.
Mais ça ne va pas être les mêmes.
C'est pour ça que moi, quand t'as Thales qui me dit t'inquiète,
regarde, on a Spanner et on va l'opérer nous-mêmes.
Ouais, je suis désolé, mais les ingénieurs Thales,
ce n'est pas les ingénieurs qui ont construit Spanner.
Et à l'époque, pour gérer Spanner,
c'était 50 000 ingénieurs en temps réel tout autour de la planète en permanence
qui étaient capables de prendre ces systèmes-là en temps réel, etc.
Moi, quand on dit qu'il y a 100 ce qui arrive,
je ne suis pas du tout inquiétant.
Des bruits que j'ai en interne de comment ça se passe.
C'est assez popcorn.
Ouais, ouais.
Et puis, je pense que l'intégration au chausse-pied,
je rêverais qu'on puisse un jour parler de tout ça.
J'aimerais pour terminer cet épisode qu'on regarde un petit peu
les différents usages que vous voyez.
Et puis, notamment, on a peu parlé de sujets data.
Donc, il y a peut-être un petit sujet autour de comment on peut faire de data avec ça.
Et puis, je sais aussi que chez vous, chez Clever,
vous avez ce sujet du Function as a Service qui est Serverless.
Compute Serverless.
Est-ce qu'il n'y a pas un truc là-dessus ?
Je prends le côté autre usage et je passerai la main à un PZ sur l'aspect data,
parce qu'il est en train de faire des trucs pas mal.
Effectivement, il y a l'usage matéria en tant que DB Serverless,
mais il y a énormément d'autres usages qu'on est en train de construire dessus.
Un des premiers, c'est du KMS, du Key Management System, en API Vault.
En fait, on s'intègre aux écosystèmes existants.
Et le but pour nous, c'est de dire qu'on a une bonne gestion,
encore une fois, transactionnelle, des gestions de secret pour les utilisateurs.
Et ça veut dire que l'interaction qu'ils ont avec le système
leur garantit l'écriture du secret, des clés, etc.
Donc on a fait une API Vault implémentée sur la même mécanisme, sur le même SDK.
C'est pas brandé matéria, parce que sinon à la fin, tout s'appelle matéria.
Mais c'est un cloud service KMS qui est transverse à Clever
et qui en train de chip avec le client qui est sponsor du sujet.
Je vais pas dire qui c'est, mais venez me payer un coup, puis on en parle.
Et du coup, ce truc-là est très intéressant et on est aussi en train de développer des usages
purement internes dans un premier temps, et on ne va pas aller en détail dessus,
mais qui nous permettent de gérer le logiciel d'orchestration avec une gestion des états.
Ce qui est très important parce qu'on a un logiciel de gestion,
de déploiement, des applications, des VM, etc.
qui est du pure logiciel distribué.
Ça veut dire que si on arrache une AZ, il continue de fonctionner continuellement, etc.
Là où tu déploies de l'open stack, tu as le rôle open stack, mais tu te fais arracher,
il n'y a plus un qui marche.
Et donc pour faire ça, on avait besoin de gérer les états.
Aujourd'hui, c'est quelque chose qui est dans les...
C'est un nouveau logiciel.
On a 14 ans d'existence et on est parti de ces 14 ans d'apprentissage
pour développer les futurs 20 prochaines années.
Il y a avec des nouvelles primitifs qui vont permettre de faire de l'affinité,
de l'anti-affinité, etc.
Donc vraiment des trucs très très intéressants.
Et pour faire ça, on avait dû une besoin d'être
d'une logique de logiciel distribué et d'avoir du coup une gestion des états là-dedans.
Aujourd'hui, ça s'est fait en mode R&D sur du zookeeper,
parce que c'est ce qui te permet avec une notion de quorum,
d'avoir tes élections, tes gestions de master, etc.
d'avoir tes watch.
Et donc là, l'idée, c'est de reprendre ce qu'on a fait là-dessus
sur FoundationDB en tant que metastore de l'orchestration générale.
Gros sujet pour nous, mais très important parce que c'est aussi ce qui nous permet
de passer à l'échelle sur les déploiements avec des très bonnes performances,
mais tout en ayant la résilience sur une topologie totalement distribuée.
Et de gagner le simulateur et de gagner plein de choses en fait.
Et quand tu gagnes le simulateur sur ton coeur de métier et ton orchestration,
c'est quand même top.
Sur l'aspect data, Pierre, je te propose d'évoquer un peu
ce qu'on est en train de faire, les députés matérieurs.
Oui, alors du coup, on parlait de cette base de données logiques
dans le SDK qui est instantiée à chaque transaction.
En fait, quand je dis base de données logiques, c'est vraiment une base de données
avec un Header, des data en fonction des tables, des indexes et compagnies.
Et en fait, on travaille actuellement sur la gestion des indexes.
Donc, vous savez qu'en fait, une query SQL avec des indexes,
et vous avez le query engine qui va dire, voilà, je vais chercher dans les indexes
et puis du coup, ça va donner un résultat qui va me permettre
d'aller chercher la bonne donnée en fonction des indexes.
Mais en fait, nous, c'est ce qu'on est en train de faire.
Donc le SDK aujourd'hui, il est très clé valeur parce qu'en fait,
notre premier cas d'usage, c'était le matériacavé.
Mais pour faire d'autres choses, en fait, on est aujourd'hui en train
d'intégrer un query engine.
Donc pour les gens qui viennent de l'écosystème Java,
on a un query engine qui est pluggable, il y a Apache Calcite,
qui marche très bien, qui est leader dans ce domaine-là.
En fait, il y a un équivalent dans le monde russe qui s'appelle Data Fusion,
qui est dans la fondation Apache.
Et donc aujourd'hui, on est en train de travailler sur le support des index
dans Data Fusion et donc on est en train de travailler là-dessus.
En fait, l'idée, c'est de gérer le cycle de vie de quand tu envoies une requête,
il faut aller scanner l'espace de clé qui correspond aux index
et de venir chercher la bonne donnée.
En fait, on n'avait pas envie de coder ce système-là qui va gérer les Nscans
aux Nsindex, réagriger les résultats et après faire le scan complet.
En fait, on l'a codé une fois, ça a été très pénible
et j'ai jamais réussi à faire merger ma paix, d'ailleurs,
pour être totalement franc.
Et donc en fait, ce qu'on fait, c'est qu'on délèque cette responsabilité-là Data Fusion.
Et comme Data Fusion est extrêmement extensible,
en fait, on travaille sur le support de rajouter dans le plan physique
des queries Data Fusion la gestion des index.
Et du coup, nous, on a implémenté les bonnes interfaces
et donc on est en train de complément déléguer le plan d'exécution
de la base de données logiques à Data Fusion.
C'est assez rigolo, en vrai.
Et en fournissant des table providers à Data Fusion pour pouvoir remapper
vos structures physiques avec...
C'est ça.
...c'est ça.


...c'est ça.

En vrai, ça nous donne...
...en fait, on se gagne gratuitement grâce à ça,
notamment à AeroFlight, le fait d'exposer...
Ouais, parce que voilà, Data Fusion sort du format RAW,
donc quelque chose qui est tout à fait transportable de mémoire à mémoire.
En fait, c'est assez rigolo parce qu'on a fait des choix technologiques
où en fait, par exemple, la donnée qu'on encode, c'est de l'avro.
C'est-à-dire, en fait, dans le SDK, on fait de l'avro.
Donc, en fait, on sérialise la donnée en avro.
Ça nous permet d'avoir la gestion des schémas et l'upgrade des schémas, etc.
On a dans le futur le Data Fusion qui va comprendre de l'avro
et du coup qui va nous permettre de le convertir en ARRO
et du coup de faire du calcul ARRO.
Et à partir de ce moment-là, une fois qu'on a Data Fusion,
bah en fait, on est capable de se brancher sur l'écosystème Data Fusion.
Ça veut dire, on gagne une intégration GraphQL,
on gagne une intégration AeroFlight,
on gagne plein de choses en fait à partir du moment où on a le Quarantine.
C'est assez compliqué d'intégrer Data Fusion dans ce modèle-là
parce que Data Fusion, c'est un modèle plutôt orienté analytique,
tu vois, c'est utilisé pour un flux d'ata et compagnie.
Mais en fait, ça nous débraille tellement d'usages dans notre base de données logique
qu'en fait, le gain est vraiment phénoménal.
Et en plus, on travaille avec la communauté Data Fusion.
Donc en plus, on fait des PR.
Donc ça, c'est chouette.
Et puis tu gagnes avec la vectorisation.
Demain, si on veut faire du distribuer sur le Coerie,
bah on pourra aussi, il y a plein de choses qui découlent de ça.
En fait, le cas d'usage qu'on a, il est très simple.
Donc on a un modèle KV, donc du clé valeur,
mais en fait, les clés valeurs, elles ont un TTL.
Donc on a un index qui est posé sur le fait si tu as posé un TTL ou pas.
Tu as t'imagines ton KV, tu prends trois tables, enfin trois colonnes, clé valeur TTL.
C'est comme ça que les... à peu près c'est représenté.
Bah comment tu gères l'expiration de ta clé TTL ?
Bah en fait, tu as besoin de chercher dans un espace de clé qui contient TTL,
qui elles sont les TTL expirés pour les supprimer.
Et bah en fait, c'est ça, le moteur de query, on a besoin que nos développeurs de l'aieurs
soient capables d'exprimer un select étoile où l'air TTL est expiré.
Et en fait, c'est un cas d'usage tout bête, mais ça nous demande quand même un peu d'ingénierie,
tu vois, pour le rendre le service, c'est le rentrer dans le SDK.
Donc c'est ce qu'on est en train de faire avec la communauté d'ailleurs d'Atafusion.
Cool !
Et du coup sous-simulateur.
Et pour finir, tu...
Pardon, vas-y.
Non, du coup, c'est plutôt chouette ce qu'on est en train de faire.
Mais ça nous donne une base de données assez rigolote où en fait,
on a une base de données Avro avec du data fusion et Serverless.
Ça donne un truc assez rigolo avec la gestion des schémas, avec la multi-tenante-sims.
Et c'est assez rigolo.
Et dans laquelle on intègre des mécanismes de triggers,
ce qui permet du coup sur des événements comme création d'une entrée,
une modification, suppression de différents types de triggers que tu peux définir,
sur lesquels tu peux appeler ensuite des systèmes extérieurs,
dont le FAS.
Et donc ça veut dire que tu peux te faire un backend dans lequel sur modification ou
sur interaction avec ta donnée, tu as du compute qui vient s'ajouter de manière dynamique là-dessus.
Et le trigger, il est dans le laïeur.
C'est bien ça, on est d'accord.
Il est même dans le SDK, parce qu'en fait c'est le SDK qui va
qui va rap cette complexité là, comme ça les devs de laïeur,
tu vois ils ont pas besoin de s'embêter avec ça.
Bon messieurs, j'ai l'impression qu'on pourrait faire une série d'épisodes.
Avec le troisième épisode.
On aurait pu faire trois épisodes.
Parce que si on ne nous arrête pas, on en a encore pour cinq heures.
On rouvre la boîte de Pandore à chaque conversation.
Oui, parce qu'on peut parler de la gestion des schémas.
J'ai cru que tu allais te dire.
Non merci, c'était passionnant.
Moi j'ai appris, c'est assez génial ce genre d'épisodes où tu apprends énormément de choses.
Moi ça a été vraiment une redécouverte de ce produit fascinant.
Et puis bravo pour le job que vous avez fait en termes d'intégration,
pour ce que vous avez fait sur ce SDK.
C'est toujours intéressant au-delà du produit, dans ces premiers essais,
de voir comment on a, comment est-ce que vous l'avez appréhendé
et comment est-ce que vous en avez fait votre quotidien.
Voilà.
Si des gens veulent travailler dans ce sujet-là, on recrute.
Et si des gens veulent coder sans le SDK,
alors on n'a pas rendu open source, mais on réfléchit à ce truc-là,
mais des gens peuvent prendre la librairie d'Apple qui fait 95%
de ce qu'on fait.
Vous pouvez l'utiliser en Apache 2, la licence.
Merci de ton organisation Vincent.
Merci à nos deux animateurs du jour.
Que t'aies un plaisir.
C'était un plaisir.
C'était un plaisir.
On mettra dans les show notes des épisodes partout où est-ce que vous pouvez
nous suivre, nous retrouver.
C'est évidemment des grands classiques.
Si vous êtes des auditeurs, des podcasts respectifs,
vous savez déjà tout ça, mais on mettra ça pour rappel.
Et je pense que de toute façon,
nos chemins se recroiseront à nouveau, messieurs,
parce qu'on a encore plein de choses à évoquer ensemble.
Je pense qu'il y a plein de sujets.
Chers auditrices, chers auditeurs,
si on espère que vous avez passé un bon moment à écouter cet épisode,
vous avez eu autant de plaisir à l'écouter que nous en avons eu à l'enregistrer.
On se retrouve dans un prochain épisode.
À très bientôt.
Merci beaucoup.
Au revoir.