DataOps en 2022 : le NoOps est-il devenu une réalité ?

0:14 Bonjour à tous, j'espère que vous m'entendez bien. Je suis Anne-Elisabeth Caillot, je suis Customer Engineer Manager chez Google Cloud France. Déjà, merci à tous d'être là. Moi, je suis ravie en tout cas d'animer aujourd'hui ce meet-up Tech.Rocks autour du DataOps et puis autour de cette question, le NoOps, y est-il devenu une réalité? Alors, pendant ce meet-up, on va bien sûr revenir rapidement sur les enjeux, le pourquoi du DataOps, comment se met en place finalement cette méthodologie agile et collaborative autour de la gestion de données, comment elle se matérialise et puis comment finalement les technologies cloud ont aussi un peu libéré ces possibilités afin justement d'aller faire le point, d'aller chercher où nous en sommes en 2022 et puis de voir si finalement on a un peu atteint une maturité aujourd'hui suffisante en termes d'outils, en termes de technologie, en termes aussi d'organisation pour atteindre le no-ops. On verra d'ailleurs finalement est-ce que le no-ops est une vérité et la réalité du data-ops.

1:18 On ira vraiment creuser ce sujet-là de façon pragmatique. Et justement, pour avancer sur ce sujet assez passionnant, on partagera notre vision chez Google Cloud de ce sujet. On aura aussi la chance de s'appuyer sur les expériences et le retour terrain de nos invités aujourd'hui, Back Market et Tinyclues, pour mieux comprendre cette méthode, comment ils l'ont implémentée, ses impacts et ses challenges. Alors, sans tarder, du coup, pour rentrer assez dans le vif du sujet, du coup, j'ai demandé à nos intervenants de se joindre à moi sur scène et je les remercie déjà. Donc, on aura la chance d'avoir Mike et Aidane, qui est chef technologie officer et chef product officer chez Tainiki. Bonjour Mike. On aura aussi Florian Valeye, Data Engineering Manager chez Back Market. Et puis, Johan Picard, notre responsable de la practice data chez Google Cloud. Alors déjà, merci à vous, messieurs, d'être là aujourd'hui et puis de nous partager vos visions, expériences et puis le SunLearn sur le Data House.

2:21 Pour recadrer peut-être vite fait aussi un peu le format d'aujourd'hui, on va commencer par à peu près 30 minutes de présentation par Johan au départ et puis ensuite on aura Florian et Mike qui nous partageront un peu d'informations d'ailleurs sur leur société et puis voilà comment ils ont appréhendé ce DataOps. Et puis après on aura aussi vraiment une bonne vingtaine de minutes de Q&A. Donc on est vraiment là pour répondre à vos questions, vos interrogations. Donc n'hésitez vraiment pas à utiliser la plateforme et la section Q&A à droite du chat pour poser vos questions, pour voter. Voilà, on sera à plaisir de les relayer et d'y répondre au mieux possible. Voilà, pour rentrer tout de suite dans le vif du meet-up, je vais te passer la main à Johan pour commencer tout de suite la démystification du DataOps et du NoOps. Let's go! Merci Anne-Elisabeth. Et en effet, démystification, c'est vrai que dans le titre DataOps en 2022, le NoOps est-il devenu une réalité? Il y a deux buzzwords en deux courtes phrases, ça fait beaucoup. Donc je vais m'attacher dans cette première partie à essayer d'éclaircir un peu ce que ça veut dire, en tout cas notre vision, nous Google, ce qu'on attache un peu derrière ces mots, et essayer de clarifier un peu tous ces termes-là, qui peuvent en effet faire un peu buzzword, ça fait couler beaucoup d'encre, il y a plein d'articles sur le NoOps, qui forcément, enfin, on n'est pas tous d'accord d'ailleurs.

3:34 Donc au moins donner notre vision à nous, et ce que je pense aujourd'hui du NoOps en 2022. Je vais commencer très simplement par partir de la base, à savoir de la data et les cas d'usage de la data aujourd'hui, qui sont multiples et variés. Je pense que tout le monde a compris que la data pouvait apporter de la valeur énorme pour leur business, quel qu'il soit, qu'on fasse de l'analytique avancée avec des cas d'usage avancés comme vous voyez là. Je pense que de plus en plus même de métiers maintenant sont pitchés directement par les consultants ou se documentent par eux-mêmes et comprennent à quel point la data pourrait les aider au sein de leur business propre, on va dire. Ce qui génère énormément, énormément de cas d'usage pour les plateformes de données sous-jacentes. Et puis même, sans aller finalement dans les cas d'usage les plus avancés, les plus AI ou les plus prédictifs, ne serait-ce que prendre des décisions basées sur de la data, faire de la BI, du reporting, ça reste le cas d'usage principal de la data aujourd'hui et il continue d'être important, voire même de plus en plus important. Si on regarde ce qui est un peu catastrophique, qui je trouve est assez impactant, dans les 50 dernières années, la durée de vie moyenne, d'une entreprise a été quasiment divisée par deux. Si ça continue comme ça en 2025, elle aura vraiment été divisée par deux.

4:36 Donc prendre des décisions rapidement, prendre des décisions qui sont informées et exécutées rapidement, devient de plus en plus important, même sans partir dans l'AI et dans les cas d'usage les plus sexy, on va dire. Et ça, fatalement, ça peut créer une petite rupture au sein des entreprises aujourd'hui. On a d'un côté les data analysts qui portent tous ces cas d'usage-là et qui, eux, ont un métier où ils doivent explorer, ils doivent itérer, ils doivent faire un florilège de cas d'usage, un backlog. qu'on a vu qui est assez intense et qui se base sur une plateforme de données qui elle est opérée par des gens qui ont des incentives qui sont un peu alignés différemment. La plateforme data, leur travail eux c'est plutôt de faire une plateforme qui est stable, qui peut passer à l'échelle, qui est performante pour tout le monde et donc les incentives d'un côté d'innovation, de création et d'exploration ne sont pas forcément alignés avec l'équipe de plateforme, l'équipe data qui eux ont plutôt des incentives de stabilité et de productivité on va dire. Et donc ça, cette dichotomie, on va dire, ce problème-là, il est très courant et c'est un peu le quotidien, on va dire, de la plupart des équipes de plateforme data, de réussir à faire une plateforme qui est stable, qui est fiable, qui est performante, mais tout en rendant possible quand même des expérimentations rapides et l'agilité pour les équipes

5:43 les plus utilisatrices et analystes. Et ce problème, il est complexe. Il est complexe, pourquoi? Parce qu'on cherche ici à optimiser finalement deux équations qui sont vraiment aux antipodes l'une de l'autre. D'un côté, la plateforme IT, de l'autre côté, la rapidité business, qui sont dans des référentiels totalement différents. Et donc, les organisations traditionnelles des entreprises n'étant pas prêtes, pour aller dans cette direction-là, on a cherché à trouver des approches qui vont aligner ces deux équations-là au plus possible, et un nouveau paradigme, on va dire, de travail. Et ces approches-là, c'est ce qu'on appelle l'approche DataOps. Donc il peut y avoir différentes définitions. La plus consensuelle des définitions du DataOps, c'est vraiment d'essayer d'aligner ces deux équations-là, de la data et du business, pour réussir à faire des cas d'usage, et de faire ça de façon industrielle, et de faire ça de façon récurrente et automatisée. Et en gros, ça va se... basé sur deux grandes familles de pratiques, pour passer de l'idée AHA au catching, à récupérer la valeur de ces cas d'usage-là. Il y a deux grandes familles de méthodes qui sont utilisées dans le DataOps. Il y a d'abord des méthodes agiles, qu'on ne présente plus, pour unifier le business et le développement, mais aussi et surtout des méthodes du DevOps, pour faciliter la barrière entre le développement et les opérations, mais cette fois-ci appliquées à la data.

6:57 Et c'est la somme des deux basées sur une data platform qui font aujourd'hui ce qu'on appelle le DataOps. C'est la définition la plus à élever. J'aimerais juste me concentrer un tout petit peu sur ce qui va nous intéresser plus ici, cette partie DevOps associée à la data, qu'est-ce que ça veut dire? Et surtout, qu'est-ce que ça veut dire pour nous, chez Google? Vous le savez ou vous ne le savez pas, chez nous, on a ce qu'on appelle des S-Series. Chez Google, Google Cloud, ou en tout cas l'entité en général, on a créé ce modèle, ce framework-là, qui est le modèle du S-Series. Et en gros, c'est notre implémentation, pleine d'opinions, c'est notre version de DevOps. Quand on nous dit DevOps, nous on comprend S-Series, c'est comme ça qu'on a choisi de l'implémenter. Donc si on devait le faire en informatique, la classe S-Series implémente l'interface DevOps. Donc c'est comme ça qu'on le voit. Et d'ailleurs, il n'y a pas que nous qui faisons ça maintenant, Facebook, Apple, Amazon, la plupart des entreprises maintenant ont des S-Series, vraiment, qui est finalement une façon de faire du DevOps. Et nous, on fait du S-Series aussi pour la data. On a des data S-Series qui vont faire du DevOps à la data, et donc participer à cet écosystème de data. Et donc, le SRI a énormément de responsabilités.

7:59 Je vais vous dire. pas avoir le temps ici d'aller dans tout ce que doit faire un data SRI, mais en gros, en gros smile, le SRI est responsable de définir des SLO, de définir des métriques, du monitoring, de faire du capacity planning quand ça fait sens, de faire du change management, mais voilà, aussi un aspect très culturel d'infuser ça au niveau des équipes métiers. Je vais passer un peu très rapidement là-dessus, mais il y a juste peut-être... Une chose que j'aime beaucoup dans la pratique SRI et que je ne retrouve pas forcément chez tous nos clients ou globalement dans l'industrie, c'est que les SRI fonctionnent très simplement avec un système de SLI et SLO qui ne sont pas forcément implémentés, alors qu'ils sont implémentés dans le monde du DevOps, qu'ils sont implémentés dans le monde de l'applicatif, mais qui, je trouve, tardent à gagner en maturité un peu dans le monde de la data. En gros, très simplement, les SRI, conjointement avec les utilisateurs finaux, vont définir pour tout cas d'usage data, pour toute plateforme data, un ensemble d'indicateurs qui peuvent être... Tout dévarié, par exemple, le nombre de requêtes qui doivent s'exécuter en moins de 10 secondes, le niveau de remplissage de telle colonne, un indicateur de qualité sur la donnée, un indicateur de fraîcheur de la donnée, un indicateur de disponibilité de la plateforme,

9:05 tout un ensemble d'indicateurs qui sont vraiment focus, concentrés sur l'utilisation qui va être faite de la plateforme et définie conjointement avec les utilisateurs. Et puis une fois qu'on a défini ces indicateurs-là, on va leur mettre des objectifs. D'accord? D'accord? Donc, maintenant que j'ai défini, par exemple, que le temps de réponse de mes requêtes est important, je vais leur mettre un objectif. Je veux que 10% de mes requêtes seulement prennent plus de 10 secondes. D'accord? Et ça, on en fait un objectif, on en fait un contrat. D'accord? Et on en fait un objectif. fait ce qu'on appelle un erreur budget. Donc si on prend par exemple 100% de disponibilité et qu'on définit une disponibilité à 99% pour mon entreprise, j'ai un erreur budget de 1%. Si je vous le matérialise un peu plus clairement, cette pratique-là du SRI, je vous le fais comme ça en étapes. Imaginons que la disponibilité de la plateforme soit l'objectif qu'on veut ici avoir. Et par exemple, on a un objectif que la plateforme soit disponible pour les utilisateurs. 19,9% du temps. On a ce SLO-là. On va définir l'erreur budget en prenant 100% moins cette cible-là.

10:06 Par exemple, ici, on a le droit d'avoir 0,1% de non-disponibilité. On peut le voir comme ça. Ce qui fait environ 43 minutes par mois, si on fait le calcul. Et on va constamment, au fur et à mesure du temps, monitorer, et donc le monitoring est clé, il faut les bons outils pour ça, la disponibilité de ma plateforme, et évaluer en permanence où je me situe par rapport à cet objectif-là. Et en fonction de ça, on va avoir trois décisions à prendre. Si le budget est dépassé, donc que j'ai déjà dans ce mois-ci été non disponible pendant plus de 43 minutes, dans ce cas-là, j'arrête. J'arrête de faire des nouvelles releases, j'arrête d'innover, j'arrête de finalement faire des nouveaux cas d'usage et de continuer à mettre de l'instabilité dans ma plateforme et je me concentre vraiment sur la disponibilité de ma plateforme et sur le fait qu'elle continue à fonctionner bien et qu'elle ne soit pas indisponible. Si j'ai encore un peu de budget, que la plateforme a été indisponible que pour 20 minutes par exemple, dans ce cas-là, j'ai encore de la marge, je peux pousser des nouvelles releases, je peux mettre à jour, je peux développer des nouveaux cas d'usage qui risquent d'impacter cette disponibilité-là, mais c'est dans mon budget. Mais le pire des cas finalement, ce n'est pas que le budget soit dépensé, il est fait pour ça.

11:07 Le pire des cas, c'est quand le budget n'est absolument pas dépensé. Ce mois-ci, ma plateforme a été disponible 100% du temps. Ça veut dire que je n'innove pas assez, ça veut dire que je ne prends pas assez de risques, que je ne pousse pas assez de nouvelles futures et que je ne suis pas assez agile. Et donc il y a un équilibre à trouver par rapport à ces erreurs budget là et qu'on peut appliquer à tout. Là c'est la disponibilité mais on peut éventuellement appliquer la même chose avec des silos de qualité de données. Je veux par exemple que dans cette colonne là, là, soit remplie à 90% du temps. Ou alors, je veux que mon indicateur de qualité moyen, qu'on peut définir ensemble, soit toujours au-dessus de 4 sur 5, par exemple. Donc, on peut définir des indicateurs par rapport à l'utilisateur, par rapport à ce qui est important pour eux, les monitorer en permanence, créer un budget d'erreur par rapport à ces objectifs-là, les monitorer et s'assurer de les consommer le plus possible pour avoir un équilibre. Et donc là, on a enfin une équation qui marche pour tout le monde entre la stabilité et l'innovation. Donc c'est juste un des aspects du SRI et du DevOps appliqué à la data ici. Il y en a beaucoup d'autres, mais je pense que c'est déjà un grand pas en avant quand on commence à penser comme ça. Et donc finalement, est-ce que c'est aujourd'hui l'état de l'art?

12:09 Est-ce que c'est le mieux qu'on puisse faire finalement? Est-ce que le DataOps avec du SRI à la place du DevOps, c'est l'état de l'art, c'est le graal, on va dire, des plateformes data? Oui et non. C'est déjà une pratique qui est très avancée, que tout le monde ne fait pas, et d'ailleurs, il n'y a pas d'urgence à le faire, c'est en fonction des impératifs de chacun. Donc c'est déjà quelque chose qui est très avancé, mais ça peut ne pas suffire à lui-même. Notamment si ma plateforme de données sous-jacente n'est pas prête pour ça. Si les opérations de ma plateforme sont trop lourdes, si finalement tout mon budget est consommé pour juste garder les lumières allumées, et que dès que j'ai un problème, ça me prend des années ou des mois à le résoudre, fatalement si ma plateforme n'est pas à la hauteur du modèle que j'ai mis par-dessus, si j'ai les meilleurs pilotes du monde mais que mon véhicule se déplace lentement, je vais avoir du mal finalement à vraiment faire marcher ce modèle-là. Et donc ce modèle-là, il est en train d'évoluer finalement. Il est en train d'évoluer parce que faire une... Tourner une plateforme de data, c'est compliqué. C'est compliqué pour plein de raisons. Ce n'est pas parce que les gens qui le font ne sont pas bons, loin de là. C'est parce que déjà, le marché est gigantesque. Une plateforme de données, c'est un peu ça.

13:11 Donc ça, c'est juste le panorama de tous les outils data, de tous les players dans le monde de la data en 2020. Il y en a moult, il y en a des dizaines. Et les plateformes de données, il faut qu'on arrive à les construire à partir de tout ça. Et puis tous ces produits-là ont des cycles de vie différents, des niveaux d'intégration différents, des niveaux de maturité différents. Faire tourner une machinerie avec tout ça, c'est complexe. Surtout quand la plupart de ces outils-là ont un peu tous ces problèmes-là. Une plateforme de données, les opérations qu'on doit pouvoir gérer autour, de façon la plus automatique possible, certes, mais ça va être la disponibilité, comme on l'a dit, ça va être le provisionnement des ressources, ça va être le tuning des performances, la mise en place du monitoring, le déploiement, la configuration. Ça prend énormément de temps, finalement, d'administrer une plateforme data. Et c'est pour ça que de plus en plus d'entreprises cherchent des solutions à ce problème-là pour rendre possible DataOps de façon la plus élégante possible. Et de plus en plus de gens, maintenant, vont vers le cloud ou réfléchissent au cloud comme une des façons d'optimiser ça. Et c'est vrai que le cloud, intrinsèquement, dans sa forme la plus simple, optimise déjà beaucoup la partie déploiement, la partie avoir des ressources plus facilement, c'est tellement beaucoup plus facile sur le cloud, monitorer tout ça.

14:18 Le cloud apporte beaucoup en termes de flexibilité, d'agilité. Il y a une bonne partie des tâches qu'on a vues juste avant qui sont lissées par le cloud, mais ce n'est pas non plus la réponse à tous les problèmes. Ce n'est pas un graal, ce n'est pas quelque chose qui va résoudre tous ces problèmes de data platform. Si maintenant l'infrastructure est illimitée, le budget, lui, n'est pas forcément. Et donc, il faut continuer à monitorer ça et à optimiser non plus le déploiement, mais vraiment le coût des instances. Il reste encore beaucoup à faire sur la disponibilité des machines, la configuration, etc. Ça facilite grandement la vie d'un DevOps ou d'un DataOps. Par ailleurs, ce n'est pas la réponse à tout. Et chez nous, on a notre propre cloud, du coup, Google Cloud, la plupart des produits Google tournent sur Google Cloud. On a essayé de résoudre ça. en allant un cran plus loin finalement dans le cloud, et non pas seulement en faire une plateforme pour mettre à disposition des machines, même des services managés, mais d'aller dans le plus possible dans l'abstraction totale de la plateforme, et de faire ce qu'on appelle du serverless, encore un buzzword de plus, mais finalement l'idée qui est derrière ça, c'est de rendre la plateforme la plus invisible possible pour que mes équipes,

15:20 utilisatrices, mes analystes, soient le plus autonomes possible et ne réfléchissent jamais en termes de machines, de performances, mais vraiment utilisent la plateforme qui va passer à l'échelle toute seule en fonction de l'usage et finalement qui va être facturée à l'usage le plus proche. Ce qui reste pour beaucoup d'ailleurs, des fois les plateformes d'attaque, quand elles ne sont pas dans ce modèle-là, doivent refacturer l'usage qu'en effet aux utilisateurs, ça peut être complexe aussi. Et donc nous, on est à fond dans le serverless, chez Google en interne, et donc fatalement aussi chez Google Cloud pour nos clients. Et le serverless, c'est encore un mot qu'on associe du coup au noops, et je vais y venir, mais j'ai envie de débunker ce terme un peu de serverless qui peut être confusant. Je me rappelle au salon du Big Data, on avait un stand à l'époque où les stands étaient encore autorisés, et quelqu'un était venu me parler et me dire, maintenant que vous faites du serverless, est-ce que vous allez arrêter avec le data center? Et alors là, je me suis retrouvé un peu con, je ne savais pas quoi répondre à ça. Non, pas du tout, bien sûr que non. L'idée c'est d'abstraire la complexité de l'infrastructure pour l'utilisateur, c'est pas bien sûr qu'il y a des serveurs dessous pour faire tourner tout ça. Donc la question m'a pris de court, mais en même temps je la comprends, serverless c'est bizarre comme terme, il n'y a pas de serveur.

16:23 On essaie ici de modéliser que c'est facile à gérer, mais... Ça me déplaît, c'est confusant et puis en plus c'est bizarre. C'est rare de définir quelque chose parce qu'il n'est pas. On ne fait jamais ça. Typiquement, moi, je suis humain, je ne suis pas wingless. Donc, serverless, c'est un terme qui fondamentalement me dérange, peut poser problème et confusion. Et en plus, on ne définit pas quelque chose parce qu'il n'est pas. Et donc, les gens... On cherchait des nouveaux termes par rapport à ça et essayer de lier ça un peu au DataOps, est apparu le terme de NoOps, d'accord? En mode, on ne fait plus du DataOps, maintenant on fait du NoOps, parce que la plateforme, elle est serverless, elle est autogérée, elle est autoscalable, elle est auto-administrée, et donc finalement, maintenant, on fait du NoOps. Mais ça, ça me pose problème aussi un peu. Je pense qu'aujourd'hui, on n'y est pas du tout. Et je pense que fondamentalement, il y a un problème, c'est que si on remplace le DataOps par le NoOps, on enlève toutes les bonnes pratiques que j'ai dit avant, qui elles n'ont rien à voir avec la technologie. Définir des budgets d'erreur, s'aligner avec les business. Finalement, si on définit le DataOps par l'ensemble de bonnes pratiques pour que ma plateforme tourne, je n'ai pas envie de m'en séparer de ça.

17:29 Le DataOps reste important. Et le NoOps finalement donne un peu l'idée qu'on n'a plus besoin de faire ça et que la technologie a résolu tout ça, ce qui aujourd'hui n'est pas le cas. Donc je n'aime pas NoOps non plus, et puis en plus c'est encore un exemple de définir quelque chose parce qu'il n'est pas, ce qui me paraît tout aussi bizarre. Donc finalement, on est trouvé un peu coincé, on n'a pas trouvé finalement de terme un peu mieux, donc on est resté sur serverless et on continue à parler de serverless. Si vous avez un nouveau terme, je prends, mais pour l'instant on va se satisfaire de celui-ci et s'assurer de faire du data ops, mais en utilisant... au maximum le serverless. C'est ça, je pense, aujourd'hui, l'état de l'art, la chose la plus avancée qu'on peut faire. Et ce serverless-là, ce n'est pas un mythe, ce n'est pas Star Wars, ce n'est pas de la science-fiction. Le but, c'est vraiment d'automatiser au maximum la plateforme sous-jacente pour libérer le maximum de temps aux DevOps pour qu'ils puissent justement s'assurer d'avoir des budgets qu'ils peuvent tenir. Et ce truc-là, ce n'est pas de la magie, ce n'est pas de la science-fiction. On a plein de clients, même des clients historiques. Là, Tiny Clue et Back Market vont parler qu'ils sont des clients et des utilisateurs très avancés, très matures.

18:34 Mais même dans les industries les moins matures, on trouve des gens qui sont capables d'en bénéficier. Par exemple, on a un retailer français traditionnel qui a monté une plateforme de données Google Cloud qui est de bout en bout et serverless. Il ne gère pas une seule machine, ça scale tout seul. Et puis au-delà de ce retailer-là et de cette plateforme-là qu'ils ont mis en place, on a des clients plus traditionnels comme Renault par exemple qui avaient un énorme data lake en prem et qui ont choisi de passer au serverless sur le cloud et juste pour illustrer un peu ce côté un peu faciliter les opérations on ne va pas les enlever, on ne va pas faire du no ops mais faciliter les opérations ils ont une plateforme de data qui est entièrement serverless et qui est alimentée à partir de l'IoT de leurs différentes usines, de leurs différents capteurs de leurs différents véhicules pour plein de cas d'usage que je n'ai pas déroulé ici mais un point qui est important et triste aussi lors de la première vague du Covid il y a deux ans maintenant, ça aussi c'est triste, vous voyez en bas à droite l'impact que ça a eu sur la plateforme. Pendant la première vague, ils ont dû fermer leurs 15 usines européennes pour protéger leur collaborateurs comme beaucoup d'autres industries. Et vous voyez en bas à droite, usine arrêtée égale plus de données à IoT égale consommation de la plateforme qui est instantanément descendue à même pas 5% de ce qu'elle était à charge nominale.

19:42 Et ça, ils l'ont fait tout seuls. Ils n'ont pas eu à décommissionner des machines, ils n'ont pas eu à faire aucune tâche d'OPS pour que ça arrive. Ils ont éteint la machine, plus de données qui arrivent, la plateforme scale down à quasiment zéro, les coûts scale down à quasiment zéro instantanément. Et quand ils ont réouvert les usines, que les collaborateurs sont revenus, On a redémarré les chaînes de production. La plateforme est remontée à charge automatiquement. D'accord, et ça c'est un exemple et on peut faire ça sans compromettre sur les performances ou la sécurité. On a des clients comme HSBC qui ont aussi des plateformes serverless qui leur permettent de faire ce qu'ils faisaient avec leur cluster jadis en 10 heures maintenant en 30 minutes dans un contexte qui est hautement régulé. Et donc finalement, est-ce que c'est ça? Est-ce qu'on parle de no ops, de data ops, de serverless? Comment ça marche tout ça? Moi je pense qu'aujourd'hui, la chose la plus avancée qu'on puisse faire, et je ne dis pas qu'il faut y être demain sinon on a raté, mais la chose la plus avancée aujourd'hui qui existe, et en tout cas que je vois implémentée, c'est comme ça qu'on fonctionne chez nous, chez Google en interne, c'est de faire du data ops et d'implémenter des bonnes pratiques qu'on pourra dérouler pendant les questions et on va voir comment d'autres le voient.

20:43 Mais de faire du data ops, d'avoir cet alignement entre les DevOps et les business users avec des mécanismes, le SRI en est un, les budgets d'erreur en sont un, mais des mécanismes pour aligner tout ça, le tout sur une plateforme qui laisse le plus de temps justement de se poser ces questions-là. Si on est la tête sous l'eau à essayer de maintenir la plateforme, on aura du mal à mettre en place ces méthodologies-là. Et donc je pense qu'aujourd'hui, le no-ops, on n'y est pas, ce n'est pas forcément un but en soi. Peut-être que la technologie, et on y travaille en vrai, se simplifiera encore plus, le monitoring sera encore plus automatisé, la définition de S&I sera encore plus automatisée. Nous, on commence à sortir des outils où le monitoring est drivé par des SLO. Donc on va écrire des SLO business et le monitoring va entièrement se faire par rapport à ça et non plus en termes de CPU de performance. Donc on y va doucement. Je pense qu'aujourd'hui, le no-ops, c'est surtout un buzzword, c'est surtout quelque chose pour faire couler de l'encre, que le data-ops est loin d'être mort et qu'au contraire, il faut qu'on aille de plus en plus vers le data-ops, mais que si on veut s'outiller le mieux possible pour être capable de faire du data-ops, il faut une plateforme qui suive, d'où le serverless.

21:47 qu'on propose nous et que d'autres, d'ailleurs, le serverless a le vent en poupe aujourd'hui. La plupart des éditeurs et des cloud providers commencent à sortir des fonctionnalités serverless pour venir enrichir leur plateforme. Super, merci beaucoup, Johan, pour cette première introduction. Et puis, je crois que c'est Florian qui va prendre la main, justement pour nous parler concrètement de comment vous avez mis ça en place, et puis un peu de Back Market aussi, et les différents acteurs avec lesquels vous travaillez. Bonjour à tous, merci Anne-Elisabeth. Je suis Florian Baleille, je suis Data Engineering Manager chez Back Market. Prochaine slide, s'il te plaît, Johan. Tout d'abord, présenter Back Market. Back Market est une place de marché qui met en relation des consommateurs avec des reconditionneurs. On a été créé en 2014 avec trois fondateurs et nous sommes aujourd'hui 600 employés qui travaillent avec 1500 marchands. Qui sont répartis dans 16 pays, donc principalement l'Europe et les États-Unis. Notre mission, tout simplement, c'est de rendre inutile l'achat du neuf, en proposant des services ou des devices reconditionnés.

22:54 Prochain slide. Je suis Data Engineering Manager au sein de Back Market dans le BIO. dans le bureau technologique, qui est une partie technique de back market, et plus principalement dans une tribu qui est la plateforme. Le data engineering se retrouve entre trois principales équipes, data collect, data prepare et data serve, et nous sommes directement en liaison avec des producteurs de données. Et des consommateurs. Donc, de la partie où on va collecter de la donnée brute pour la cheminer et prendre des décisions dessus, côté consommation. Donc, trois équipes différentes avec trois missions différentes. La première, Data Collect, de découvrir et de récupérer de la donnée brute en provenance de différentes sources. Nous avons Data Prep qui est plus autour de la préparation de la donnée, comme son nom l'indique, avec la classification, la gouvernance et la sécurisation. Pour différents cas d'usage. Et enfin, la DataServe, qui est une équipe qui est dédiée à servir et à exposer la bonne donnée au bon endroit pour le bon usage, donc en respectant les contraintes légales. Prochaine slide.

23:57 Donc ça se décline d'un point de vue architecture et d'un point de vue plus particulier DataOps dans l'équipe au travers de trois équipes avec des stacks différentes. Donc principalement, nous avons deux cloud providers, AWS et Google Cloud Platform. Donc AWS chez Data Collect et Data Prepare et Data Server repose principalement sur Cloud Platform. Sur les usages et les provenances de sources de données, nous avons toutes les API externes, donc principalement des données qui vont en provenance de Zendesk, Google Analytics, pour exemple. Et nous utilisons Airbyte comme connecteur qui va être... va nous permettre de capter cette donnée. Toutes les autres données sont en provenance interne, donc principalement la base de données du site Internet Back Market, mais ça peut aussi être de l'événementiel du fichier. Donc toutes ces données sont acheminées côté prépa et reposent principalement sur différents services. Managé et principalement serverless, hormis la partie Delta Lake, qui est une solution technique open-sourcée par Databricks pour faire et créer deux principales catégories de données.

24:58 La catégorie bronze, qui est la catégorie de données. qui est toute l'historisation des données, et la partie silver, qui est toute la préparation compressée, prête à servir de multiples usages. Sur côté DataServe, nous avons Snowflake et BigQuery qui permettent de construire la partie Gold, qui est une donnée plus orientée business pour les consommateurs au sein de Back Market. Nous avons aussi certains systèmes de catalogues comme Castor qui nous permettent de documenter, de partager les définitions de ces data assets au travers de Back Market. Donc, ce n'est pas seulement une architecture, le Data Hub, c'est aussi des principes d'équipe. Nous, il y a trois principes en dateur. Le premier est Build and Run. Nous avons une architecture cloud native complète, c'est-à-dire que nous construisons l'infrastructure, l'application dessus, pour répondre à des cas de business. Nous déployons des stacks dédiés de chaque équipe pour répondre à différents usages. Nous avons une orientation de production first mindset, car il est très important pour nous de savoir que la valeur qui est apportée, c'est la valeur d'acheminer ces données de bonne qualité vers les consommateurs et également d'apprendre par un feedback positif, un retour positif de cette plateforme, comment agir et comment fournir d'autres fonctionnalités.

26:07 Donc principalement plus une approche produit, c'est-à-dire que chaque équipe a une stack et cette stack est un produit avec des fonctionnalités propres qui vont répondre à différents cas d'usage. Donc, on a une orientation très équipe, dans le sens où une équipe fait des décisions techniques et a l'autonomie et la responsabilité de sa stack, la déploie et maintient l'évolution et apprend à la... à maintenir et à faire des évolutions sur cette infrastructure. Il y a un aspect assez important aussi, c'est le multirégion, c'est-à-dire que chaque équipe et chaque stack peut se déployer autant en Europe qu'aux US que d'autres plaques géographiques avec une configuration dédiée, c'est-à-dire avoir une approche globale plateforme, mais avec des spécificités locales. Tout ça, nous avons aussi au travers de ces différentes équipes des best practices, ce qui est très important, ce qui va devenir la glu pour s'assurer que toutes les équipes travaillent bien ensemble avec le même objectif d'apporter de la valeur. Nous utilisons principalement de l'infrastructure Ascode, notamment Terragrunt et Terraform, qui va nous aider à déployer ces services managés ou ces différents providers.

27:09 Au travers de différents cloud providers ou solutions technologiques. C'est très important d'avoir une approche module, c'est-à-dire qu'on va avoir des modules qui vont se déployer dans différents écosystèmes avec des configurations propres. Il y a aussi une spécificité qui est que chaque équipe, chaque membre d'équipe peut déployer sa propre stack. Si je suis dans l'équipe Data Prépar, je peux déployer ma stack comme une stack de pré-production, ou de production et faire mes tests avant d'avoir un cycle de release complet. Nous sommes aussi très fervents du côté pyramide testing, on l'applique dans l'infrastructure, c'est-à-dire qu'on teste de manière unitaire notre composant pour qu'il marche bien au niveau de son module lui-même. On teste les multimodules qui fonctionnent bien ensemble et également des scénarios de tests complets qui sont plus fonctionnels avec des entrées et des sorties. Donc je rentre de la donnée, je vois mon système et à la sortie j'attends principalement que tout soit bon. pour éviter d'introduire des régressions, donc c'est des tests de non-régression pour fiabiliser la plateforme suite à de multiples évolutions.

28:11 Dernier slide. Donc principalement, j'ai récupéré ton slide, Johan, et j'ai essayé de voir, moi, qu'est-ce que c'est la classe Data Engineer chez Back Market, comment on l'implémente. Et en fait, je pense que c'est de l'héritage multiple, dans le sens où le premier, ce qui est cœur, c'est le software engineering. Nous, le Data Engineer et le Data Ops est un software engineer qui a des manifestes, en fait, et qui suit un manifeste d'équipe, donc autour du software craftsmanship, dans le sens où on produit un code de qualité et d'équipe avec toutes les best practices du software engineering et de trouver le bon outil qui font le bon travail. On a aussi une approche très égoïste programming. On est là dans une équipe pour apprendre et délivrer de la valeur ensemble. Donc, on a vraiment cette fondation qui est de dire on fait les décisions ensemble, mais on a l'autonomie et la responsabilité du DevOps dans le sens où je construis, je design et je le mets en production. On a aussi cette partie infrastructure as code qui nous aide énormément à pouvoir manipuler différents providers avec un même socle et une même infrastructure qui est définie avec du code, donc avec du test, du review, du pair programming, toutes les bonnes pratiques qui sont issues aussi du software engineering.

29:16 Il y a également la partie monitoring et alerting. Je pense que c'est très important d'avoir un cycle de retour pour prendre des actions et pour trouver ce qui va améliorer, c'est les retours autant d'un point de vue consommateur que d'un point de vue de la plateforme à elle seule. Et le dernier pilier qui est très important, c'est les data concepts. Le data engineer doit comprendre les mécanismes sous-jacents des services qu'il manipule. Donc, on peut citer la haute disponibilité ou la scalabilité d'un point de vue technique, mais également des notions plus transverses, plus business ou plus architecture de gouvernance, comme le data mesh. Donc, ça, c'est des choses qu'on surveille principalement dans les équipes pour qu'on ait ces trois piliers qui nous permettent de faire du data engineering avec des plateformes qui sont dédiées à chacune des équipes. de chez Back Market. Merci beaucoup Florian pour toutes ces informations. Mike, je te passe la main pour la suite. Ça marche. Un peu plus d'informations sur la version Tiny Cloud. Ça marche, merci beaucoup, je suis ravi d'être là.

30:19 Je vais parler un petit peu de ce qui est Tiny Clues, de comment on a structuré notre système et pourquoi on a pris ces décisions, et ensuite des rôles d'AttaOps, qu'est-ce que ça veut dire chez nous, et de manière à avoir une perspective, par un aspect très proche de celle de Florian, par un approche un petit peu différente, et de pouvoir avoir un dialogue ensuite sur ces sujets. Je vais faire un slide, s'il te plaît. Donc, qui est Tally Close? Tally Close est un outil SaaS à destination des marketing qui met le deep learning dans les mains du customer marketing, c'est-à-dire un département marketing qui fait des campagnes marketing, que ce soit par email, par push, par Facebook, Customer Audience, et un tas de choses. Donc, on les aide à faire des meilleures campagnes et donc à augmenter le revenu par campagne, à trouver des opportunités de revenus, c'est-à-dire des sujets sur lesquels ils n'adressent pas dans leur plan marketing et donc d'optimiser leur plan marketing. Et enfin, de lutter contre l'opt-out. Vous savez que dans toutes les communications, nos clients respectent l'opt-out et ils doivent finalement, de leur point de vue, pousser des produits.

31:28 Pour répondre à leurs objectifs. tout en ne détruisant pas la valeur de leur base et donc en ayant un taux de TAP qui reste relativement faible. L'entreprise, on est à peu près 70, 35 à 40 dans l'équipe technologique et on a des gros clients qui sont des gros retailers ou des grosses sociétés du voyage. C'est nos deux grosses verticales. Comment on fait ça? Et ça, c'est notre particularité, c'est qu'on récupère les first parties de tous nos clients, que ce soit les logs d'achat, les logs d'interaction, que ce soit les logs d'interaction, les pages views, des emails logs, des push logs, le catalogue produit et puis la base CRM. Donc, ça fait pas mal de données qu'on doit gérer, manipuler, fois le nombre de nos clients. Et par-dessus ça, on a nos modèles prédictifs, qui est le corps de l'expertise de Tannic News, qui calcule finalement des propensity scores, des propensity d'achat, des propensity de churn pour chacun des utilisateurs. Et le produit final, ce sont des audiences, des listes d'utilisateurs qu'on va pousser sur les canaux que nos clients vont...

32:38 On va en tirer. Désolé pour les anglais, c'est pour la mise en place. Voilà. Tu veux bien le projet en salle, Johan, s'il te plaît? Je vais revenir un petit peu sur notre architecture et comment on est arrivé là. Tu parlais, Johan, tout à l'heure du serverless. C'est clairement un parti pris. Moi, je suis arrivé chez Danny Clues il y a presque trois ans. On a toujours été cloud natif parce que l'entreprise s'est créée au moment où le cloud existait déjà. Par contre, on avait une approche plus cloud basics, DVM, des clusters ECS sur la AWS. Ou des clusters Kubernetes pour certains des composants. Moi, je viens d'un monde où, il y a quelques années, on gérait des clusters à loop avec 250 notes et des gens qui allaient dans les machines pour les upgrader. Ça nous prenait peut-être la moitié de notre temps. Donc, j'ai bien... Souris quand tu parles du chemin, Johan.

33:41 Et finalement, en étant cloud native, on peut quand même se perdre dans ces chemins-là. Souvent, on oublie que dans du cloud native, je peux faire un peu tout ce que je veux à différents niveaux de la stack. Et suivant le niveau où je vais le faire, je vais devoir avoir un coup de DevOps qui est différent. Et donc rapidement, on avait pris un pari de dire, en fait, il y a plein d'endroits où notre cœur de métier, c'est de créer des modèles prédictifs, créer une plateforme de données scalable, etc. Ça serait un autre métier. Comme on est une équipe tech d'environ une trentaine de personnes, on n'arrivera pas à la scaler pour finalement gérer. 150 clients fois 10 à 15 flux de données qui arrivent chez nous de manière quotidienne. Et donc, on a fait le pari du serverless. Un mot là-dessus, souvent, Dans mes expériences passées, on regarde le coût de manière un petit peu biaisée, c'est-à-dire que si on regarde le coût des infrastructures, évidemment, on peut trouver que le coût d'un serveur d'Est, ça va être plus élevé.

34:42 Ce qu'on oublie de compter là-dedans, c'est l'opportunity cost, c'est-à-dire le temps que je vais mettre à faire cette chose-là, c'est du temps que je ne vais pas utiliser pour délivrer de la valeur pour mes clients ou faire un nouveau use case ou développer une nouvelle fonctionnalité de mon produit. Et ce coût, c'est probablement le coût le plus important. plus que la différence de prix entre mon service interne AVM et mon serveur NAS. Et l'autre chose, c'est qu'on ne peut pas être un expert partout. Je parle d'une expérience personnelle, on a commencé à déployer, on avait un cluster presto dans notre infrastructure précédente, On a fait des erreurs d'implémentation de cluster presto, donc on a eu des données qui étaient réappliquées dans plusieurs zones. Un use case dont on n'avait pas besoin, ça nous a coûté plusieurs dizaines de milliers d'euros pour le coût de data transfert qu'on aurait pu éviter si on avait fait tout ça en l'as. Donc voilà, trois leviers qui ont bravé cette décision finalement. L'expérience d'avoir la moitié de la bande passante utilisée pour faire

35:47 de la maintenance de machine, le fait qu'on sous-estime le coût d'une opportunity cost et que le serverless nous abstrait de ça, et ne pas sous-estimer le cœur d'expertise. Le cœur d'expertise de Danny Glue, c'est de construire des modèles. Des modèles prédictifs sur les données de l'ASPARCI des clients. Et concrètement, notre infrastructure, elle se présente sur ce diagramme. Donc, on a les données qui arrivent de nos clients, soit par du cloud storage, soit par du SFTP qui est proxyé sur du cloud storage Fuse. On a des cloud functions qui vont uploader les données dans BigQuery. Et ensuite, tout le layer de manipulation, de transformation de données, on utilise un outil qui s'appelle dbt, qu'on orchestre via Compose. Et donc tous nos workflows de gestion de données et ensuite tous nos workflows de training, de scoring, de création des tables d'analytics sont orchestrés par Composer, mais grosso modo en faisant des fonctions DBT à plusieurs niveaux.

36:48 Et enfin, pour la partie training et le scoring, un appel sur Vertex. Alors, ça ne s'appelle plus AI, mais c'est la même chose. Ça, c'est des plateformes à l'AG. Nous, on utilise des images telles sur Faux pour construire nous-mêmes. C'est là notre cœur d'expertise. Et pour aller même plus loin, on essaie finalement de construire ces modèles et ensuite de les déployer sur BQML. Pour la même raison finalement de dire, moi si je dois scorer tous les utilisateurs de la FNAC, je ne veux pas avoir à m'occuper de savoir comment je vais avoir à scaler ce cluster finalement pour y arriver. J'aimerais dire, voilà l'image de Miserflow, fais-moi une prédiction sur tous les utilisateurs de la FNAC pour la probabilité d'acheter tel produit. Et l'AG de Victory va me faire ses scores et avoir un response time qui est complètement, qui est pour le coup même pas linéaire, qui est complètement presque bandé dans le temps. Voilà, je vais passer sur le prochain slide. Comment on s'organise et qu'est-ce que ça veut dire DataOps chez Tanné 12?

37:52 Alors, il se trouve qu'on avait un rôle depuis très très longtemps, depuis l'entreprise a 10 ans, il y avait un rôle DataOps chez Tanné 12 depuis tout ce temps-là. Finalement, en un moment où les outils n'existaient pas vraiment. Et donc, le job de DataHox, c'était un job d'interaction avec nos clients. Donc, dans ton diagramme, Johan, finalement, c'est le lien entre le business et la partie technique. Finalement, ils disent, je vais regarder les données que je vais recevoir de mes clients et essayer de faire rentrer ces ronds dans les carrés à diffusion. Et donc d'organiser des workshops avec nos clients, faire en sorte de faire un petit peu de normalisation de données, et puis évidemment tout le support de ces data pipelines. Data pipeline, c'est comme un tuyau de plomberie, de temps en temps ça fuit, il faut rattraper les données, il y a des données qui vont changer, nous on voit le cas souvent chez des clients où le schéma de données change, Donc, on va y venir, ça fait partie des évolutions, on arrive à détecter ces choses-là, mais il y a quand même des opérations à faire là-dessus. Et évidemment, c'est le bras technique qui interagit avec les clients.

38:58 Dès qu'on a des clients, on a des questions sur« c'est bizarre, je vois ça, c'est l'équipe d'Adobe qui va répondre à ces questions». Et tout à droite, on a une équipe qui est finalement composée de data engineers et de DevOps qui correspondait presque plus au scope de DataOps, tel que tu l'as défini, les co-speakers. puisqu'on développe des nouveaux pipelines et on est responsable en prod de les troubleshooter, de vérifier que tout se passe bien. Un point très important, et on va y revenir, j'imagine, dans la partie... en CQLA, c'est que dans des data pipelines, l'importance de ce que c'est qu'un data test, quel est le contrat d'entrée et de sortie, est hyper important. Et c'est une pratique où on a besoin à la fois d'avoir du data engineer et du DevOps pour pouvoir faire du bon boulot. Évidemment, il y a toute la partie support de cette infrastructure. Alors, elle est beaucoup plus simple dans le monde serverless qu'on a choisi que dans notre monde précédent où on gérait les clusters Kubernetes. Mais on a du composer autoscalé, on a du...

40:00 du data flow et on a du big query où on n'a finalement pas grand chose à faire. Mais cette équipe intervient en tant que tir 3 sur tous les problèmes potentiels qu'on peut avoir chez des clients. Et enfin, pareil que chez Back Market, on a un gros focus sur la partie infrastructure as code qui nous permet finalement de gérer un scope beaucoup plus large de technologie avec beaucoup moins de gens puisqu'on a des modules qui nous permettent de répliquer différentes choses. Donc il y a tout un socle de terraformation et j'ai rajouté un deuxième point. Ce qu'on a découvert, et on va y revenir dans le changement de culture entre DevOps et Data Engineering, c'est que finalement la CI dans les pipelines de données est vraiment différente d'une CI de software, et donc c'est une pratique à part. Et vous allez me dire, je n'ai pas parlé de la colonne du milieu, donc ça c'est un nouveau rôle chez Tannic Loose, qui est une évolution de notre rôle de data ops, c'est finalement, comme nous on fait des pipelines prédictifs, on a eu besoin de séparer les deux métiers, de vérifier que la donnée est là, est disponible,

41:01 et qu'elle est consommable. Et ensuite, la deuxième partie, qui est de dire, nous, on a nos moteurs prédictifs, il y a plein de paramètres, que ce soit du hyperparameter tuning, des paramètres qu'on est capable de configurer dans notre système, de regarder ce qui se passe et pourquoi la qualité des prédictions a pu baisser à un certain moment. Et donc, ce support de pipeline prédictif, c'est une troisième fonction qu'on appelle Applied Data Science, qui s'assoit vraiment entre les deux mondes. C'est-à-dire qu'il y a des outils qui sont créés par... l'équipe de Data Engineering pour les supporter. Et c'est une équipe qui arrive en support de l'équipe d'Addaox en entier problème chez l'équipe. Super. Merci beaucoup à Mike. Merci beaucoup Florian et Joanne. On va peut-être passer tout de suite sur la partie Q&A parce que je vois qu'il y en a déjà un peu dans le pipe, si je peux dire. Et puis, on avait aussi des sujets sur lesquels on voulait échanger. Il y en a une qui a reçu pas mal de votes. On va peut-être commencer par celle-là et qui est autour des bonnes pratiques de DataOps, justement, pour assurer la non-régression à traitement de données de bout en bout.

42:01 Alors, tu en parlais un peu tout à l'heure, Florian. Je ne sais pas lequel de vous veut commencer. Je peux commencer si tu veux. Allez. Sur la partie, oui, c'est la pyramide de tests tout simplement. C'est quelque chose qu'on a mis en place. Donc typiquement, vous avez une pyramide avec certains niveaux. Donc le test unitaire qui nous permet d'avoir un test un peu plus technique sur est-ce que mon module marche bien tout seul, la configuration est bonne. L'intégration qui est entre plusieurs modules. Mais ça reste assez quand même technique et assez orienté vers ma partie de code. Dans la partie donnée, c'est que ce qui est dur à estimer, c'est la forme qu'elle prend, le volume qu'elle prend, comment elle va se comporter, parce qu'elle est protéiforme, en fait, elle change complètement tout le temps. Donc, comment faire en sorte de s'adapter à ça? Donc, on essaye de plus le résoudre au niveau du fonctionnel, donc d'avoir des scénarios. Typiquement, on essaye de définir des scénarios qu'on rencontrerait potentiellement. On les met en entrée, on regarde qu'en sortie, on a ce qu'il y a, on a réussi à atteindre ce qu'on voulait comme sortie. Et une autre façon de voir les choses, c'est qu'on ne pourra jamais... anticiper tous les problèmes qui vont se passer ou les bugs.

43:02 Donc, en fait, il faut être prêt à les rencontrer. Donc, le chaos engineering ou introduire de l'erreur peut permettre aussi de voir comment son système répond. Et dans tous les cas, si on n'a pas réussi à anticiper tous les cas, on prend juste un cas qui nous est arrivé et on le met dans le scénario. Typiquement, on a une erreur, on a un problème de production, on le réinsère dans le scénario d'entrée et on s'assure qu'on l'a corrigé. Pour toutes les évolutions à venir. Pour compléter, une des pratiques qu'on a à nous utiliser, c'est qu'on utilise un outil qui s'appelle DBT, qui est à la fois un métalangage sur SQL, qui nous permet finalement de templatiser nos SQL, Et dans cet outil, il y a une partie test qu'on utilise pas mal sur deux niveaux, sur les tests de schéma. Donc ça, c'est un des gros challenges qu'on a nous, puisqu'on a beaucoup de diversité dans ce qu'on reçoit de nos clients. Et puis parfois, on reçoit un truc où la colonne a changé d'ordre ou des trucs vraiment un peu bizarres. Donc on arrive à détecter avec ces outils un petit peu de choses.

44:02 Et donc ces tests, on les fait tourner à la fois dans notre CI, quand nous on change quelque chose, et aussi scheduler sur nos environnements, pour une partie sur les environnements de prod, et évidemment sur les environnements de staging. Ça nous permet de détecter des scénarios, et comme Florian, à chaque fois qu'on a un incident, on va compléter notre batterie de test. automatique. La dernière chose, et on y reviendra peut-être plus tard, c'est que finalement, le challenge des pratiques de données, c'est que je vais développer mon pipeline dans un environnement réel avec peu de données. Et en vrai, il y a aussi des problèmes dans les data pipelines qui arrivent avec soit le volume de données, soit la... Et donc ces problèmes, pour pouvoir les répliquer en staging ou en environnement contrôlé, on a mis en place des mécanismes qui nous permettent de copier la donnée de prod de manière régulière et donc de... Vous avez dit la prod dans un environnement contrôlé. Oui, et qui sont justement, c'est ce qu'on disait un peu plus tard, assez différenciants des sites de pipeline qu'on pouvait avoir l'habitude d'avoir en DevWorld.

45:07 Et justement, est-ce que tu veux en profiter pour creuser un peu ce point-là, justement, autour des différences entre le Dev, le staging, le sens de la donnée et l'importance que ça peut avoir? Oui, bien sûr. Et c'est là où le DevOps, en software craftsmanship classique, on a une séparation très claire. Si on pousse le truc à l'extrême, on va avoir des VTC complètement séparés entre ma mandelle, mon staging et ma prod. Et là, ça devient un peu compliqué quand on fait de la donnée, puisque moi, j'aimerais bien en staging pouvoir replay la donnée de Slack pour vérifier que tel scénario va bien baser sur la donnée de Slack. Et dans des scénarios un peu rigides, c'est un petit peu compliqué. Et c'est encore plus vrai dans la partie AI, puisque pour traîner un modèle, j'ai besoin de le traîner sur toute la profondeur de mes productions d'onglets. Et donc finalement, il y a deux choses qui ont besoin d'être poreuses dans les environnements. Ce qu'on appelle l'artefact store, c'est-à-dire la partie qui va stocker les représentations intermédiaires pour mes modèles et mes modèles, Et évidemment, la donnée.

46:14 C'est-à-dire que ma donnée de prod, elle doit être queryable depuis mon environnement de dev ou mon environnement de staging. Par contre, évidemment, depuis staging, le pipeline ne pourra jamais écrire en production, il ne pourra écrire qu'en staging. Et donc, on a un mécanisme qui va nous permettre d'avoir de la porosité dans le sens... production staging dev et pas dans l'autisme. Ah ça c'est un point intéressant. C'est vrai que je vois souvent aussi cette confusion entre dev et prod en data, où finalement en fait on fait un environnement de dev, mais on a de la donnée de prod dedans, et finalement en fait la plateforme de dev c'est elle qui est la plus dimensionnée, parce que c'est là qu'on va faire le dev, qu'on va entraîner les modèles, etc. Là où la prod ça va juste être pour opérationnaliser ou distribuer, et donc elle est moins dimensionnée, donc c'est vrai que ça inverse totalement le paradigme par rapport à d'habitude, et ce que je vois moi comme étant le truc qui va vraiment séparer le prod de la dev, c'est le rythme des releases bien sûr, mais aussi la sécurité et la gouvernance. La prod, c'est vraiment le truc où la donnée est accessible, il y a un sous-ensemble de cas d'usage qui sont très bornés, là où le dev, c'est un peu plus ouvert, mais finalement, c'est vrai que ça a perdu un peu son essence, et je pense que ce n'est pas une bonne idée de s'arc-bouter sur ces concepts qui ne s'appliquent pas forcément à la data.

47:18 Pour rebondir là-dessus, justement, au niveau des notions d'environnement, ce qui est intéressant aussi, c'est la dimension coût. On s'aperçoit aussi que les environnements de dev sont très coûteux, justement, par ces tests, la CI, tous les process que nous avons pour s'assurer que la production ne va pas être impactée. Et ça aussi, dans la définition et dans le réfléchir, quand on architecture autour du data house, no house, Quoi qu'il en soit, la réflexion autour du coût est très importante et on s'aperçoit justement à ce niveau-là que ça change. Des fois, on a plus de données en prod, mais on paye moins cher parce que le système est moins testé, il tourne jour le jour et il est optimisé. En dev, on a beaucoup de tests, beaucoup de CI, beaucoup de pipelines pour s'assurer que tout va bien. Merci beaucoup. Sur le Kine, j'ai quelques questions un peu en haut des autres. des technologies, je vais un peu consolider tout ça. La première qui ressort, et elle sera peut-être du coup un peu pour toi, Johan, c'est de rapidement nous briefer les composants GCP pour gérer un détail en mode serverless, ce qui existe aujourd'hui. Et puis, je l'associerai aussi à est-ce que ce NoOps marche justement avec le NoCode et le NoSQL?

48:20 Est-ce que tu peux, voilà, nous faire un petit wrap-up là-dessus et puis, voilà, comme ça, on aura un petit éclairage. J'aime beaucoup l'esprit, Patrick. Je vais répondre à celle d'avant. De Robin. Donc rapidement, les composants GCP, on en a illustré quelques-uns. En gros, les data lakes de nos jours, alors pareil, on va passer sur la définition de ce qu'est un data lake versus un data mesh et compagnie, mais en gros, ça va tourner autour de BigQuery, notamment pour tout ce qui est données structurées, accès à la donnée, batch de données exprimé en SQL. On va avoir Cloud Storage pour tout ce qui va être gestion des fichiers, stockage des fichiers, les deux étant serverless et totalement autoscalable. Pour les parties plus data lakes qui viennent du monde à double, si je l'entends comme ça, on fait aussi du serverless avec Spark Serverless. Donc on peut lancer des pipelines Spark qui vont tourner de façon entièrement serverless dans un mesh de ressources dans le cloud. Et on a des solutions très managées pour faire des clusters à double temporaire, des choses comme ça, qui sont un petit peu moins serverless, mais qui permettent une compatibilité avec le monde à double existant. On a des architectures de référence, je t'invite à aller regarder sur le site web. Et dans tous les cas, pour ce déclat, tu en trouveras plusieurs déjà.

49:22 Oui, tout à fait. Puis on sera de toute façon aussi dans les salons après, si vous voulez vraiment préciser ces questions-là. Et puis du coup, je rebondirai un peu là-dessus pour peut-être aussi aller… Mike et Florian, vous, vous l'avez perçu comment, du coup, l'impact du cloud ? On parlait tout à l'heure du serverless et de ce que ça amène en agilité d'infrastructure. Mais même pour aller plus loin en termes d'organisation, d'équipe, je pense que ça peut être aussi intéressant de voir tout ce que ça a apporté et challenger peut-être aussi. Je peux commencer, Mike, si tu veux. Je vais reprendre ce que tu disais juste avant, qui était très intéressant pour moi. Cette dimension où on était un peu avec des architectures très dures à maintenir. avec beaucoup d'équipes. Moi, je travaillais souvent avec trois, quatre équipes différentes sur des infrastructures différentes, avec des changements de disques à certains niveaux sur certaines machines. Et du coup, on trouvait ça hyper compliqué. Et quand on est arrivé avec une approche un peu plus club native comme TinyClues avec des systèmes à disposition, pour moi, ça a été le gros changement dans le sens où on avait une... Une capacité, un impact qu'on n'a jamais eu, c'est-à-dire que l'équipe est capable de déployer, maintenir et de nombreux outils différents.

50:25 Donc, il faut quand même comprendre comment les mécanismes sous-jacents marchent. On en parlait avec la notion de sécurité, de réseau et de comment tout ça se groupille. Mais pour moi, ça a été le plus gros changement que j'ai aperçu. Et après, c'est toute la philosophie un peu plus de comment travailler ensemble. Sur l'infrastructure. Donc ça, c'est des choses qui étaient très isolées avec des équipes dédiées à un outil. Maintenant, c'est plus, OK, on a plusieurs outils. Donc, comment on réfléchit à des nouvelles façons de penser, comme l'autonomie, la responsabilité, le fait de chaos engineering, le testing, etc. Toutes ces dimensions qu'on avait moins vues avant de manière plus locale. Pour compléter un peu ce que tu dis, effectivement, historiquement, chez Danny Toos, on avait une équipe DevOps qui n'était vraiment pas séparée de l'équipe Data Engineering. Et le pari qu'on a fait, c'est de dire, en fait, en important, c'est deux genres de compétences dans la même équipe, donc sur les mêmes problématiques qu'on va arriver au... Au meilleur des deux mondes, ça a été long et compliqué, puisque un DevOps qui est le garant de la sécurité,

51:30 Ce n'est pas possible d'avoir la donnée poreuse entre les systèmes ou des artefacts qui sont accessibles à tout le monde. Et au fur et à mesure du travail ensemble, on s'est rendu compte que c'était indispensable pour pouvoir délivrer notre valeur de manière cost-effective. Et donc, on a commencé à mettre en place ce genre de système. Pareil sur l'infrastructure Ascode, on a essayé de dire, finalement, tout le monde doit pouvoir opérer l'infrastructure Ascode, pas en France évidemment, mais sur les autres systèmes. Et donc, cette compétence qu'il y avait à créer du Terraform, etc., finalement, elle a été disséminée dans les organisations de manière à ce que chacun soit un petit peu indépendant, avec évidemment le support en compétence de l'équipe d'ADOC, et donc tout le monde en compétence sur cette partie-là. On n'y est pas complètement encore, c'est un journey, c'est un voyage. Nous, l'environnement parfait où je suis capable de tester les données de tel client en prod, j'ai encore du boulot.

52:34 Merci. Attends, Anne-Elisabeth, avant de partir sur la question de Bruno pour Florian sur la complexité du multi-cloud, juste pour répondre à Patrick et sa question humoristique, est-ce que le no-hops marche avec le no-code et le no-sequel? Je t'ai fait une no-answer, oui. Voilà, donc ensuite Bruno, pour Back Market, le multi-cloud, AWS et GCP n'ajoutent-ils pas de complexité ou de latence? Vas-y. Oui, pour répondre à l'approche multi-cloud, je pense qu'on est multi-cloud par défaut, dans le sens où on utilise dans tous les systèmes qu'on est, on utilise différents cloud providers. On a vu par exemple le cas de Ivan, qui est notre Kafka, on va dire, managé, il se lance dans AWS. On est sur le GCP, on va utiliser un système qui est BigQuery. Donc c'est vrai qu'il y a une certaine approche sur le multi-cloud, mais qui répond à différents usages. En fait, le AWS est très lié avec notre population un peu plus back-end, infra, existante à Back Market. Et nous avons une autre population qui est plus orientée sur des systèmes analytics, usage, BigQuery et certains systèmes qui rentrent plus dans ce cas d'usage.

53:36 Il y a aussi plusieurs équipes qui travaillent directement déjà sur GCP. Donc la complicité, elle est là, oui, mais elle est déjà là avec différents systèmes. Sur la latence, aujourd'hui, on n'en aperçoit pas. On réfléchit surtout à une approche, comme tu évoquais, Johan, on essaye de réfléchir au SLA. Quels sont les datasets critiques chez Back Market? Quels sont les SLA associés? Et notre but, c'est de les délivrer en temps et à heure. aux consommateurs en fait. Donc on a une approche vraiment qui est orientée plus usage que performance à tout prix sur des systèmes qui arrivent et qui tapent fort en entrée. Vous avez des data products avec des SLA et des tribus. Vous êtes déjà à fond dans le data mesh, ça pourrait être le sujet d'un autre talk sur des buzzwords. Data mesh, il est sympa. Data mesh est un gros buzzword. Peut-être ajouter un mot sur le multi-cloud. Autant on est multi-cloud par transition, finalement, puisqu'on était nativement, exclusivement sur AWS il y a un an et demi, et que là, on est un petit peu entre les deux.

54:42 Donc, nous, on a fait un parti pris assez fort là-dessus. Cela dit, on avait des hypothèses sur... Donc, nous, on a un métier où on a besoin de transférer finalement pas mal de données puisqu'on va avoir des... Et finalement, là, on est sur un bon égrig où aujourd'hui, j'ai encore des pipelines qui tournent sur un WOS. Ils font des queries de données sur BigQuery. On avait très peur des coûts de network. Alors, on a moins le problème de l'attente parce que c'est le train et que c'est donc asynchrone. On avait des grosses peurs sur le volume de transfert. Et finalement, sur la grosse photo des mille pieds, finalement, ça ne représente pas grand-chose par rapport à notre structure de coût actuelle. Donc, j'ai envie de dire, si je devais, dans ma future carrière, avoir une approche, je vais prendre le meilleur système pour le use case que j'ai besoin de faire. Finalement, toute cette connectivité devient tellement plus facile qu'elle pouvait l'être il y a 5-10 ans. C'est vrai, Mike, sur ça, on a eu la même analyse. On s'est dit AWS GCP, de suite, c'est le coût d'externalité des données qui va vraiment être impactant.

55:48 On ne pourra pas le faire. Donc, on a fait des estimations et des estimations très fortes dans le sens, je prends toutes mes données et je les déplace tous les jours. Et en fait, en tirant des indicateurs comme ça très démentiels, on s'est rendu compte que ce n'était pas ça la vérité du problème. Il y a plus des problèmes, on va dire, de connaissances en termes d'équipe, une connaissance GCP, une connaissance AWS, mais ça, avec des bonnes pratiques, ça peut se faire avec des scopes liés aux équipes aussi. Et par usage, je pense qu'on peut y arriver. Mais en effet, ce n'était pas du tout le cas bloquant qu'on a représenté. Nous, on n'a pas de problème avec le multicloud en général. D'ailleurs, BigQuery tourne aussi sur AWS. Et de base, l'égresse à partir de BigQuery est gratuite. Donc, vous faites des requêtes à partir d'un truc qui est sur AWS sur BigQuery directement. L'égresse, vous ne le payez même pas. Bien sûr, si vous transférez des fichiers à partir de GCP, CES, S3 par exemple, ça vous le payez. Mais les requêtes à partir de BigQuery, Multicloud sont gratuites aussi. Allez, la partie Grèce. Super. Écoutez, merci en tout cas, Mike, Florian, Joanne, pour l'échange d'intervention. De toute façon, on retrouve tout le monde après, je pense, dans les salons pour plus de questions. Merci du coup pour vos partages.

56:48 Je pense qu'on a un peu quand même répondu et avancé sur le chemin du no-ops. Et je trouve que ce qui ressort quand même, c'est qu'en effet, il y a une vraie importance de se focaliser sur les SLA, les SAI, sur les usages, beaucoup plus finalement que les OPS. Il y a vraiment une stratégie avec les technologies cloud et serverless d'aller chercher cette abstraction pour garder le bon focus. Et puis, on voit bien aussi, et peut-être qu'il y aura plus de questions dans les salons, qu'il y a aussi un vrai impact et challenge organisationnel au niveau des rôles et que c'est aussi ces briques-là qu'il faut penser. On a aujourd'hui la maturité, je pense, suffisante en termes de technologie et de solutions pour apporter des briques techniques derrière pour porter tout ça. Merci beaucoup. Merci aussi aux participants pour les questions, les échanges. On est on time. Et du coup, il y aura Johan, Florian, Mike, moi-même et également Sabi Traifi que je remercie, qui est un spécialiste data aussi chez Google Cloud, qui nous a aidé à préparer tout ce meet-up et qui sera également dans les salons pour répondre à toutes vos questions. Et puis, échanger aussi avec vous si vous avez besoin qu'on vous accompagne dans la mise en place de ces plateformes.

57:51 On l'a vu, on parle de maturité de solution. Il y a aussi des maturités un peu en termes d'organisation d'entreprise pour jumper sur ces sujets-là. Donc, ravie de vous accompagner là-dedans. C'est bien à table, enfin à table virtuelle j'entends.