Edge security : protéger les applications et API dans les environnements distribués

0:01 Bienvenue pour cette masterclass, on va attendre encore quelques minutes pour que tout le monde nous rejoigne et je vous propose de lancer à 12h05. Ok, il est 12h05, je vous propose qu'on commence.

4:55 Du coup, rebonjour et bienvenue à toutes et tous pour cette Master Tech Rocks. classe MongoDB que j'ai le plaisir d'animer dans le cadre du Tech.Rocks Summit qui aura lieu la semaine prochaine. Et j'ai le plaisir d'accueillir aujourd'hui Brice de chez MongoDB. Pour ma part, je suis Stan, je suis CTO de Théodo Cloud et je me ferai... l'animateur de cette session. Et donc, je te laisse, Boris, prendre la parole pour se présenter. Merci, Stan. On m'entend bien? Oui. Excellent. Eh bien, bonjour à tous. Brice Akuchi, Senior Solutions Architect chez MogoDB. Alors, Senior, c'est pour la barbe blanche. C'est ce qui donne le droit d'avoir ce titre. Merci à tous de vous être connectés aujourd'hui à midi. J'ai l'impression d'être un rempart entre vous et le déjeuner, mais à mon avis, certains d'entre vous sont en train de manger en même temps. Aujourd'hui, on va parler de résilience et le titre que vous avez vu, construire des infrastructures de données résilientes.

5:57 On aime bien les titres compliqués. Pour des choses qui au final sont assez simples. Donc je vous propose qu'on avance. Alors en ce qui me concerne, le petit QR code ici, si vous voulez vous connecter sur LinkedIn, surtout s'il y a des questions ou des choses qui vous viennent après la session, n'hésitez pas à vous connecter avec moi et à me contacter. En quelques lignes, j'ai une carrière dans le software. Dans le logiciel, j'ai commencé comme développeur en 2009, ça fait longtemps, c'est un peu déjà la préhistoire. Et je suis passé par plusieurs entreprises, j'ai passé beaucoup de temps chez Clique. la solution d'Analytics en Solutions Architect, donc en avant-vente. Et avant de rejoindre MongoDB cette année, j'ai fait une petite parenthèse pour faire de l'ébénisterie. Donc là aussi, si certains s'intéressent à tout ça, n'hésitez pas à me contacter. Mais j'ai voulu essayer de construire des choses qu'on pouvait palper, ce qui n'est pas toujours le cas avec le cloud. Donc, je vous parlais de préhistoire, je vous commence par une petite histoire. Donc ça, c'est moi à la sortie de l'école dans mon premier job.

7:01 Et finalement, je me souviens d'un épisode qui m'a marqué, puisqu'on parle de résilience. Mon chef m'avait confié la tâche sur un de nos serveurs de test. Alors, c'était encore des serveurs physiques qu'on avait dans un coin de notre bureau, dans une mini salle blanche. De changer le disque dur. Il nous fallait plus de stockage. J'étais un peu, j'étais débutant, je sortais de l'école. J'ai commencé à faire ça, en plus entre midi et deux, excellente idée. Et j'ai fait une mauvaise commande, tout simplement. Donc, j'ai formaté le disque initial au lieu de formater le disque que je venais d'installer. Donc, c'était un peu la panique. On parle de disaster, disaster recovery. Heureusement, on avait des backups, mais bon, je vous laisse imaginer. On était une petite startup, donc tout ce qui est disaster recovery plan et tout ça, on ne connaissait pas trop, surtout sur un serveur de test. Donc, heureusement, on a réussi à restaurer ça. Les backups étaient sur des bandes magnétiques en plus. Donc, assez long à restaurer. Mais... Je me suis souvenu de ça en commençant.

8:02 Donc, l'idée, c'est est-ce que le problème, c'était moi? Alors oui, en partie, mais c'est surtout, est-ce que c'est normal que j'ai pu faire ça? Et heureusement qu'on avait des backups, mais ça aurait pu être beaucoup plus embêtant. À l'époque, il n'y avait pas GitHub, donc on avait notre code qu'on committait sur le serveur, etc. On aurait pu perdre plusieurs semaines de travail. Donc, ce que je vous propose aujourd'hui, c'est de commencer tout simplement par parler de résilience. C'est dans le titre et c'est un mot qu'on entend souvent, surtout chez nos clients. Parlons de risque et puis on va définir ensemble un cahier des charges de ce que serait une bonne base de données par rapport à ça. Je vous parlerai évidemment de MongoDB, de Atlas, qui sont des solutions que vous connaissez peut-être. Et puis quelques cas concrets. Il y a beaucoup de contenu, n'hésitez pas en fonction de l'avancement à donner des commentaires dans le chat si vous le souhaitez. Je voudrais être un peu technique, mais pas forcément trop. Donc, ça va dépendre des attentes de chacun. Et si jamais vous êtes un peu sur votre faim, sans mauvais jeu de mots, À la fin de la présentation, on continuera sur LinkedIn.

9:07 Alors, la résilience. Excuse-moi, je t'interromps deux secondes, Brice. L'idée, c'est vraiment de... Il n'y a pas de questions bêtes, donc vraiment, utilisez l'onglet questions pour poser toutes vos questions. Et j'essaierai de voir, s'il y a certaines questions qui émergent, je t'interromprai, Brice. Excellent. Avec grand plaisir, je préfère que ce soit interactif. Je ne suis pas là pour être un professeur d'école avec des élèves sages. Alors, j'ai cherché des citations sur la résilience. Ça m'a beaucoup ramené au développement personnel. C'est un point important, mais vraiment cette idée qu'il y a des coups durs dans la vie et comment on arrive à se relever. C'est un peu ce qu'on applique au logiciel quand on parle de résilience. Moi, j'aime bien cette citation de Mark Twain. On la connaît tous. Il ne savait pas que c'était impossible, donc ils l'ont fait. En fait, je la modifie pour aujourd'hui. C'est plutôt, ils ne savaient pas que c'était possible. Et c'est un peu ça la base de la... notre discussion aujourd'hui. Je vous donne quelques actualités. L'idée, ce n'est pas de pointer certaines entreprises du doigt parce que je pense que tout le monde risque d'y passer un jour ou l'autre.

10:10 Mais on n'arrête pas d'entendre cyberattaque, bug crowd strike, panne de région cloud, etc. En fait, on a beau être très préparé, il y aura toujours des pannes. À l'époque, même sur un serveur, quand on mettait de la redondance, on se disait on va mettre deux disques durs, comme ça, ou du RAID. S'il y en a un qui tombe en panne, il y en a un autre qui stocke les données. Dans la notice même de toutes ces machines, il y avait MTBF, qui est le temps moyen entre deux pannes. Donc, c'est un état de fait. Il y aura des pannes. Et si on considère qu'il n'y aura jamais de pannes, on part déjà avec un énorme problème. On parle beaucoup de disaster recovery ou disaster recovery planning. Je vous donne quelques exemples de disasters, parce qu'il y en a certains qu'on n'a pas toujours en tête. Alors, les catastrophes naturelles, il y a quand même eu des inondations récemment dans plusieurs pays. Ça peut noyer littéralement un data center s'il n'est pas bien protégé. On a quand même... Vécu une pandémie, ça a quand même un gros impact sur des serveurs.

11:12 Il peut y avoir une charge supplémentaire, il peut y avoir des nouveaux usages. Alors en ce moment, c'est beaucoup quand même les cyberattaques. Donc là, on est sur un autre type de désastre parce que ce n'est pas forcément des pannes ou du déni de service, mais il peut aussi y avoir du vol ou de la correction de données. Du ransomware, les intervenants Je repense aux dinosaures de la préhistoire. Tout simplement, faire une mauvaise commande, ne pas comprendre ce qu'on fait, mais aussi parfois être un acteur malhonnête. Des pannes réseau, ça arrive souvent qu'on le pense. Et donc, le serveur ne tombe pas forcément en panne, mais il peut devenir inaccessible. Ce qui parfois est d'ailleurs même plus gênant, il peut être vu par exemple par une partie de vos serveurs applicatifs et pas par une autre. Et il peut y avoir des choses qui se passent en parallèle et donc des choses incohérentes. Et au moment où le réseau se rétablit, il y a des conflits à gérer. Les pannes hardware, évidemment, même si tout est relativement sécurisé maintenant au niveau des clouders. Alors, recovery, moi, je dis souvent aux clients, on vient de voir pour du DRP, on dit on veut faire du multi-cloud ou du multi-région.

12:21 Ça, c'est le focus outil, c'est le focus software. C'est un point important, avoir des sauvegardes, avoir de la redondance, des mécanismes de réparation qui permettent d'avoir de l'eau au dispo, c'est très important. Mais en fait, ça ne suffit pas. Les process sont tout aussi importants. Quand on est pilote d'avion et qu'on a un souci et qu'il faut réagir très vite, en vol, on a des checklists. C'est-à-dire qu'il y a des gens qui ont travaillé en amont, pas dans l'émotion, mais quand tout était calme, pour proposer la meilleure marche à suivre. On n'a pas besoin de comprendre forcément toutes les étapes dans le feu. de l'action, mais on sait qu'en les suivant, on va pouvoir rétablir la situation. Ça demande donc des checklists, des plans de reprise et évidemment, ça c'est le cas classique, des tests. Rien de pire, c'est arrivé à plein d'entreprises, rien de pire que de se rendre compte au moment où on en a besoin, que le backup est corrompu ou n'existe pas, comme on le pensait.

13:26 Donc, c'est très important, quand on est sur une application très critique et qu'on a un plan de recovery sérieux, de tester régulièrement qu'on est capable de réparer le système. Pour souligner ce propos, à titre d'exemple, côté Théodoclade, on a exactement cette philosophie-là qui est d'accompagner nos clients sur« Ok, vous avez un DRP, mais un DRP non joué est inexistant. » Ça fait très peur de jouer un DRP, mais on se pose les bonnes questions quand on se dit« Ok, qu'est-ce qui nous bloque dans le fait de le jouer? » Et c'est là qu'on trouve les vraies actions pour se prémunir de la étape des astres le jour où. Exactement. On l'a tous vécu, même dans la vie perso. On a d'autres cas. C'est peut-être une voiture ou autre qui tombe en panne. Il y a plein de choses. Et enfin, c'est aussi des personnes. Il faut identifier les équipes avec des rôles bien définis, avec des plannings d'intervention. Qu'est-ce qui se passe si on a le site e-commerce qui tombe? Samedi ou la veille du Black Friday, ça c'est très très important.

14:28 Donc, Tout ça pour dire que ça se réfléchit, mais aussi, certains d'entre vous voient peut-être là des euros ou des dollars. Tout ça, ça a un coût. Il faut se dire que le disaster recovery, c'est une assurance. Donc, il faut définir pour chaque application la criticité. Qu'est-ce qui se passe quand j'ai une indispo d'une heure, d'une demi-heure, si je perds mes datas? Et en fonction de ça, on va décider de l'investissement et donc du niveau d'assurance qu'on va prendre. On ne va pas forcément mettre le niveau maximal avec des équipes dédiées. sur des applications pas critiques, c'est évident. En parlant de DRP, je vous donne deux termes. Ce serait intéressant de savoir si vous les connaissiez déjà ou pas. Mais ces deux métriques qui sont importantes dans votre cahier des charges, Donc, le RTO, Restart Time Objective, globalement, c'est combien de temps il va me falloir pour réparer mon système en cas de disaster. Donc, moi, je le traduis en qu'est-ce qui se passe du point de vue business, mais parfois aussi vie humaine, parce qu'il y a des applications qui ont un impact réel.

15:34 Si mon application est disponible une minute, une heure, une journée, potentiellement, c'est des millions d'euros de vente en moins ou des... Des matières importantes, dans le cadre médical par exemple, des greffes ou autres qu'on ne peut pas acheminer assez rapidement. Il y a plein de cas et c'est ça qui va déterminer aussi la criticité de votre application. Et enfin, le RPO, Restore Point Objective. Globalement, c'est si je perds, par exemple, mon système, je vais devoir restaurer un backup, Quel est l'âge maximum de ce backup? Est-ce que c'est acceptable de revenir une heure en arrière? Est-ce qu'il faut absolument que ce soit moins d'une minute? Et là, encore une fois, on va augmenter les coûts. On va entrer dans des niveaux d'assurance supplémentaires. Mais si vous voyez, là, je n'ai même pas mis« et si je perdais des données? » C'est vraiment… qu'il faut accepter qu'il y ait des choses qui soient perdues.

16:36 Donc, il faut savoir le gérer. Ça fait partie aussi du plan de reprise. C'est quoi tes insights là-dessus sur le RPO? Juste pour creuser, Brice, je sais que c'est des discussions qu'on a souvent d'un point de vue infra, mais on se rend aussi compte dans la réalité que des applications qui ne sont pas complètement stateless, typiquement, si tu as des RPO sur des bases de données, ça va potentiellement mettre quand même l'application dans un état incohérent. Comment est-ce que vous travaillez là-dessus côté Mongo? Comment est-ce que vous accompagnez vos clients? Parce que le RPO, c'est un peu global finalement. J'ai l'impression qu'on ne parle pas uniquement de la donnée. Alors, c'est sûr que nous, et dans la discussion d'aujourd'hui, je vais me focaliser sur la base de données. L'idée, c'est que la base de données est quand même le cœur de presque toutes les applications. Donc, dans le DRP global, si tu peux t'épargner d'avoir à réparer ou de faire des choses compliquées pour réparer ta base de données, tu vas pouvoir te focaliser sur l'applicatif. Dans MongoDB Atlas, j'y reviendrai tout à l'heure en quelques mots, mais c'est notre solution cloud managée, on peut aller jusqu'à un RPO qu'on affiche à une minute.

17:47 Ça peut être moins, mais on préfère dire une minute. C'est-à-dire qu'on va pouvoir restaurer la donnée à n'importe quel moment. Ce qui est aussi important en cas, par exemple, de corruption ou d'attaque. de pouvoir se dire que l'attaque a eu lieu à 12h17, on va récupérer l'état des données à 12h16. Voire même de développement qui casse quelque chose en prod. Oui, exactement. C'est des activités qui font plaisir sur les rollbacks. Exactement. Donc, il faut que le flux d'intégration continue aussi soit suffisamment robuste. Mais bon, encore une fois, l'idée, c'est à chaque fois qu'il y a une erreur, il ne faut pas forcément blâmer la personne. C'est que ça a été permis. Donc, c'est qu'on n'a pas forcément mis en place les bons garde-fous ou la bonne assurance. Un point sur lequel je vais me concentrer aujourd'hui, ce que j'aime bien, et il y a beaucoup de clients qui me disent ça, j'en avais encore un aujourd'hui qui est notre plus gros client en France, qui a dit texto, ce n'est pas parce qu'en fait, ils ont 1200 clusters.

18:51 C'est énorme comme déploiement. En gros, il a dit, ce n'est pas parce que ça marche parfaitement et qu'on n'a jamais d'alerte, qu'il ne faut pas qu'on mette en place des métriques, qu'on mesure, etc. C'est-à-dire que ce n'est pas vraiment un souci. Ils n'y pensent pas tous les jours en se disant qu'est-ce qui se passe. Parce qu'en fait, ça fait des années qu'ils l'utilisent et ça fonctionne. Donc, plutôt que d'être dans le recovery, ce que je vais proposer aujourd'hui, c'est soyons dans la prévention. Et la prévention, pour moi, un des moyens, c'est l'out-dispo. L'out-dispo, c'est-à-dire considérer que mon GoDB va être une base de données always on, qui ne s'arrête jamais, qui est une panne, ou même qu'une panne d'un serveur, par exemple, une panne d'une région cloud, ou même si on veut faire des opérations de maintenance, ce qui n'est pas forcément possible avec des bases de données classiques. Donc ça, c'est un petit rappel. On parle souvent en nombre de nines, donc 6 nines, 5 nines, ça vient aussi de l'industrie ou de l'aéronautique.

19:54 Voilà en quoi on peut le traduire. Donc, ne serait-ce qu'avoir 4 nines, c'est déjà… avoir seulement en moyenne 8 secondes d'indispo par jour. Qui est déjà un bon niveau de service. Donc Atlas sur la partie Atlas en elle-même, on est à 99.995, donc entre ces deux-là. Je vous propose un cahier des charges très simple. Enfin, très simple. Si ça venait sur mon bureau et que je devais le développer, j'aurais quelques gouttes de sueur. Mais essayons d'avoir une base de données qui reste accessible en lecture et en écriture, qui garantissent la durabilité des données, C'est ce qu'on attend en général d'une base de données. Autrement dit, si j'ai une panne, je suis sûr que mes données sont... Je vais pouvoir les récupérer. La cohérence, c'est important aussi la cohérence. Si j'ai plusieurs données qui dépendent l'une de l'autre et que j'ai besoin qu'il y ait un statut cohérent entre les deux, j'ai envie de garder ça. Et j'aimerais résister à plusieurs choses. Et on va dire qu'il y a différents niveaux dans notre assurance. Une panne d'une machine ou une indisponibilité ou la destruction.

20:58 Un data center, ou une availability zone pour ceux qui utilisent le cloud, une région du cloud, et pourquoi pas un cloud complet. Azure, GCP, AWS, indispo pour une raison X ou Y, est-ce que ma base doit continuer à marcher? Alors, ne blindons pas trop non plus le côté base de données si on n'est pas capable d'avoir aussi un niveau côté applicatif. Moi, ça me fera plaisir de savoir que Mongo n'est pas tombé en panne. Mais si vous n'avez aucune... Si vous n'arrivez pas à faire marcher vos applications par-dessus, ce n'est pas le plus intéressant. Il y a un autre client qui est une banque et qu'on a acquis comme ça. Je crois que c'est une banque américaine. Il y a eu un désastre, une perte d'un data center. Toutes les bases sont tombées, sauf Mongo. Et en fait, c'est arrivé dans une discussion avec le CEO. Et il a dit, mais c'est quoi ça, mon goût, en fait? J'ai de quoi vous parler.

22:00 Et globalement, c'est devenu un de nos plus gros clients depuis. C'est-à-dire que là, c'est un cas réel. La base a continué à marcher avec les différents mécanismes de résilience qu'on a. Je vous propose d'avancer. Le point aussi sur le RTO et le RPO, Évidemment, on veut le RTO le plus petit, on veut que ça se répare rapidement. Uh, Et puis, on ne veut pas perdre le moins de données possible, voire pas du tout. Je mets le disaster recovery en deuxième. Mon focus, c'est vraiment l'achat, mais... Le disaster recovery sera inévitable s'il y a eu une corruption ou un ransomware. Parce que là, la base a beau fonctionner, si les données ne sont pas là, on a un vrai problème. Alors MongoDB, en quelques mots, pour ceux qui ne connaissent pas, c'est une base de données. On nous classe dans le NoSQL parce qu'on travaille avec des documents. Globalement, au lieu d'avoir une ligne dans une base de données relationnelle, on a un document au format JSON. Un document, c'est hiérarchique. Donc, dans une ligne, on est quand même assez limité parce qu'on a des colonnes.

23:03 Là, avec un document, on va pouvoir mettre des champs, des sous-documents, des tableaux. On va pouvoir stocker beaucoup plus d'informations ensemble. C'est distribué, c'est ce qui va nous intéresser aujourd'hui, ou réparti en français. Je me souviens de mes cours de système réparti à l'époque, on traduisait tous les mots. Désolé pour les anglicismes. Et puis, ça reste une base de données. Donc, si vous voulez briller en société, vous pourrez dire que MongoDB est une base 3D. Donc, les documents, j'en ai parlé. L'idée, c'est qu'à la place de toutes ces tables-là, on va relier toutes les infos qui vont ensemble. Je construis une page pour renseigner mes informations d'utilisateur avec mes adresses, etc. Au lieu d'avoir six ou sept tables et de devoir faire des jointures, voire plusieurs appels consécutifs à ma base, en un seul appel, je récupère les infos et en un seul appel, je les écris. Donc ça, c'est un gain en termes de performance. C'est plus facile pour la cohérence de données aussi. On s'arrange pour que les données restent ensemble, les données qui sont en lien. C'est plus adapté à la programmation objet.

24:06 Finalement, on va reproduire ce qu'on manipule dans le code. Et donc, vous avez ces points forts ici. Peut-être en deux secondes, Brice, si tu as une explication rapide de la gestion des relations NN, parce que là, du coup, les NN, on comprend bien l'aspect graphique. Tout de suite, les questions difficiles. En fait, on a... On a toutes sortes de patterns de modélisation. Il y a un de mes collègues qui est un des auteurs de ce livre qui permet d'apprendre justement à modéliser les différents patterns. Je le prends souvent comme référence. L'idée, c'est que de toute façon, on a des données, on aura toujours un modèle relationnel avec des liens. Un effet, des liens 1, 1, 1, N et NN. Et ensuite, ce qui est très important dans Mongo, c'est de comprendre comment on va requêter la donnée. C'est ça. C'est ça le driver et c'est ça la force de la solution. Au lieu de se dire, j'ai une base, l'invention du SQL, c'est un langage pour pouvoir poser n'importe quelle question sur une base de données.

25:10 Sauf qu'en fait, quand on crée une application, on ne pose pas n'importe quelle question. Sauf certains cas spécifiques, BIA et tout, qui ne sont pas forcément les profs de Mongo. Mais quand on a une application, une fois qu'on l'a développée, une fois qu'on va en prod, on sait les patterns. Et donc, on sait, on va être capable de définir les requêtes les plus importantes, celles qui doivent être les plus performantes, etc. Plus performant, pardon. Et en appliquant des règles et en posant des questions, donc il y a des espèces d'arbres de décision, par exemple, dans ce livre, mais vous trouvez aussi tout sur notre blog, on va pouvoir décider comment modéliser. Et le cas NN, en fait, il y a trois manières de modéliser en fonction des réponses. Okay. En fait, ce qui est intéressant, c'est que le N, quand on parle souvent de SQL, on dit N, mais dans Mongo, on va chercher à se dire plutôt dizaines, centaines, milliers, parce que, par exemple, si le lien, c'est une dizaine, on a tout intérêt à le mettre dans le même document. Mais encore une fois, rien n'empêche, je veux dire, dans 10% des cas, on va quand même garder...

26:13 Des relations, avoir deux documents qui sont en lien et faire l'équivalent d'une jointure pour aller le chercher. Mais c'est en général à la marge. Est-ce que ça répond à ta question? Oui, complètement. Est-ce que ça répond aussi à ce que toi, tu as observé sur le terrain avec tes différents... Oui, tout à fait. Alors, j'avais moins cette vision de l'optimisation pour un peu les golden paths, je dirais, applicatifs. Exactement. Donc, on observe. Mais le raisonnement reste le même. Et je suis assez curieux de la lecture que tu prends, parce que je ne l'ai pas du tout entendue. Oui, c'est la philosophie. Après, tout est sur notre blog, tu trouveras plein de ressources. Aujourd'hui, on parle de résilience. Il faut juste comprendre, l'unité de base en termes d'archi, d'infra, de MongoDB, c'est ces trois nœuds ici, ces trois serveurs, primaire et deux secondaires, mais c'est le minimum syndical. Et l'idée, en fait, c'est d'avoir un système qui se répare tout seul. C'est ça qui va permettre l'audispo. Pour avoir au dispo, disaster recovery et maintenance.

27:15 Je vais expliquer un peu plus en détail. Globalement, on a un nœud primaire qui va être en charge d'accepter les écritures. Donc ça, c'est le choix qui a été fait. Il y a un nœud qui gère les écritures. C'est ce qui va permettre de gérer la cohérence. De gérer l'ordre des écritures, toutes ces choses qui font que ma donnée est cohérente tout le temps. Et les secondaires, leur rôle, c'est de répliquer ce qui se passe sur le primaire, donc d'avoir une copie de la donnée. L'idée, elle est simple. La donnée, si elle est copiée sur au moins deux nœuds en permanence, on considère qu'elle est durable et que s'il y a un de ces deux serveurs qui tombe, elle est toujours accessible et elle est stockée. Ça va permettre aussi de la maintenance. Ça, on n'y pense pas souvent, mais avec ces trois nœuds et un mécanisme, de rolling, par exemple, je sors un secondaire, je fais des opérations de maintenance dessus et je le remets, etc. Je vais pouvoir, par exemple, faire des opérations de maintenance sur l'OS, sur la base de données. Des choses qui sont extrêmement compliquées à faire avec des bases de données traditionnelles sans arrêter le système.

28:16 L'idée, c'est vraiment de jamais arrêter la base. Et puis pour le petit détail, ça je ne l'ai pas compris tout de suite quand j'ai commencé à étudier Mongo. En fait, le pilote ici, vous avez des pilotes dans tous les langages principaux, il est extrêmement important dans cette notion de résilience. En fait, il fait beaucoup de choses. Il est en permanence en train d'interroger les différents nœuds. Il a une vision de ce qui se passe et c'est lui qui va permettre de cacher les problèmes à l'application s'il y en a. Enfin, les secondaires, on va pouvoir aussi les utiliser en lecture. Donc, si on veut répartir la charge, par exemple, ou isoler certaines choses. Si j'ai un use case analytics, on va faire des requêtes qui demandent plus de CPU, on va les faire, par exemple, sur un secondaire pour ne pas perturber le système. Donc, j'ai mis des slides au cas où j'ai oublié de dire des choses, donc je vais avancer rapidement, mais ce que je vous ai expliqué, vraiment, c'est ce principe de primaire. Alors, ce qui va être important, c'est que si le primaire disparaît, tombe en panne, en fait, il va y avoir un mécanisme d'élection.

29:22 Alors, les élections, pour ceux qui aiment la technique, vous pourrez aller voir ici le... l'algo dont c'est dérivé qui s'appelle Raft, Mais globalement, les nœuds sont en permanence en train d'interroger le reste du cluster pour savoir ce qui se passe, pour savoir s'ils sont toujours disponibles. Si à un moment, ils détectent que le primaire n'est plus là, les secondaires restants vont se dire qu'il faut qu'on élise un nouveau primaire. L'élection va se faire à la majorité. Il y a une petite subtilité, c'est que c'est la majorité quand tout marche. Donc ça aussi, je n'avais pas forcément compris au début. Si j'ai 3, 2, la majorité, c'est 2. Donc il me faut au moins 2 secondaires. pour être capable d'élire un nouveau primaire. Donc en cas de panne d'un primaire, les deux secondaires vont se mettre d'accord. Celui qui a la donnée la plus récente va devenir primaire et il va avoir un système avec un primaire et un secondaire. Du point de vue du client, dans le driver, on va activer le retry write qui permet de se dire si à un moment je n'arrive pas à faire mon écriture, parce que je n'ai plus mon primaire, je vais réessayer.

30:24 Donc, côté client, côté applicatif, au lieu d'avoir une grosse erreur qui dit ta requête n'est pas possible, on va avoir une latence, le temps de l'élection, donc c'est quelques secondes. Selon les sources, on dit que c'est deux, en tout cas c'est 10 max, 10 secondes max. On va avoir un nouveau primaire qui est prêt à accepter les écritures et on est sûr qu'il y a la cohérence dans le système. Donc, quand j'explique tout ça, ça a l'air très simple. En vrai, si on commence à se poser des questions et qu'est-ce qui se passe ici et ça, Avec Brice, il me semble qu'on ne t'entend plus depuis 30 secondes.

31:30 J'avais un doute sur le fait que c'était moi. C'est bon. Ok, bon, ce n'est plus le même micro, mais si vous entendez... Tu nous disais de nous imaginer que des choses ne marchent plus, on ne pensait pas au micro, mais ça nous va. Et là, regardez, redondance, j'avais deux micros. J'avais un disaster recovery plan. Je n'ai pas prévu le cas où il y a un bris qui tombe, mais bon, on va dire que ce n'est pas le plus probable. Donc oui, je parlais de l'audispo. Donc vous avez compris, en gros, vous n'avez pas besoin de vous en préoccuper. Il y a des problèmes réseau, des pannes. Le cluster se répare tout seul. Ça, c'est important. Petite parenthèse, j'ai parlé tout à l'heure de cohérence et de durabilité. Il y a des paramétrages dans mon mot. Par défaut, On va être en ce qu'on appelle« right concern majority». Ça veut dire un truc très simple. Je considère que ma donnée a été écrite quand elle a été recopiée sur la majorité des nœuds.

32:32 Et c'est paramétrable. Il y a certaines applications, on va se dire, non, un nœud me suffit, le primaire. Je n'ai pas besoin qu'elle soit durable, la donnée, c'est un truc, c'est du cash, c'est un panier, peu importe. Je veux que ça réponde plus vite. Mais si on veut la durabilité sur ce système réparti, on va mettre majority. Et on va s'assurer que si le primaire disparaît, il y a au moins un secondaire qui a la copie de la donnée. Ça, c'est très important. On a la même chose sur les lectures. Et là, on est plus sur la cohérence et la fraîcheur. Selon les applications, des fois, on voudra lire la dernière donnée qui a été... Et donc, ça va demander de s'assurer qu'elle est sur plusieurs nœuds et des algorithmes un peu plus compliqués aussi d'horloge logique. Ou alors, on va se dire, je lis sur le secondaire, je sais qu'il n'est pas forcément à jour, mais c'est parfait pour mon application. J'affiche un nombre de vues ou des choses comme ça, je n'ai pas besoin forcément d'avoir le dernier statut. J'affiche les avis sur une page produit, je n'ai pas besoin d'avoir le dernier. Il y a toujours ces compromis entre durabilité, cohérence, temps de réponse. Donc ça, c'est des choses, en tout cas, il faut savoir que c'est paramétrable.

33:34 Et par défaut, nous, ce qu'on met, c'est strongly consistent. Donc, on s'assure que la donnée, elle est là, elle ne sera pas perdue en cas de panne et qu'il y aura toujours de la cohérence. Donc j'avance, ça c'est ce que je vous ai expliqué. Histoire de faire simple, là on a présenté ce système primaire, secondaire, secondaire. Sachez juste, je ne rentrerai pas dans les détails, déjà je vous laisse imaginer si vous deviez gérer ça vous-même, on va complexifier. On a un principe aussi dans MongoDB qui s'appelle le sharding. Je ne sais pas si ça te parle, Salislas. Tu as eu à le mettre en place. Globalement, quand on commence à avoir énormément de données ou qu'on veut répartir la charge en écriture, on va partitionner la data. Donc selon des règles logiques, ça peut être plein de choses, mais ça va être géré automatiquement par Mongo une fois qu'on a défini la règle. Et donc des répliques à 7, c'est 3 nœuds, 5 nœuds, 7 nœuds, etc. Et on va en avoir plein. Et alors là, on commence à rendre la complexité encore exponentielle en termes de maintien en condition opérationnelle, disaster recovery, backup, etc.

34:45 Donc ça, c'est encore, je prêche un peu pour la paroisse des services managés, mais les clients qui veulent gérer ça en communautaire, donc la version open source, c'est extrêmement compliqué. Oui, c'est toute une, il y a toute une théorie du sharding, et de quels sont les bons choix sur les chartings. Il y a beaucoup de littérature là-dessus. On fait des choix naïfs là-dessus qui sont très mauvais en général. Exactement. C'est pour ça qu'on a les solutions architectes. Je viens de vous aider dans la définition des projets et les bonnes pratiques. Mais par exemple, en communautaire, faire le backup, c'est extrêmement compliqué. Parce qu'il faut être capable de prendre la photo d'Echard au bon moment. C'est pour ça que sur les offres ensuite qui sont version d'entreprise ou Atlas dans le cloud, on a des outils mis à disposition pour le faire. Donc vous l'avez compris, les intérêts d'avoir ce système réparti, c'est la haute dispo avec des élections qui se passent de manière transparente. On peut aussi répartir la charge en mettant certaines opérations uniquement sur les secondaires. Et en plus, on va pouvoir avoir cette scalabilité horizontale avec le sharding.

35:50 Je conclue juste sur un point. Ça, pour moi, c'est ma partie évangélisation. Il y a beaucoup de clients chez qui on a remplacé des bases relationnelles par MongoDB. Mais chez la majorité des clients, c'est loin d'être transparent dans leur tête que c'est possible. En fait, mon GoDB, c'est toutes les forces des modèles NoSQL. Donc le document modèle, j'ai donné quelques avantages avec la scalabilité, la performance, la haute dispo qui est au cœur du produit depuis. Ce n'est pas un patch, ça a été développé comme ça, le système de réplique A7. Mais évidemment, on a pris aussi les forces du modèle relationnel qui ont quand même... Pas mal montrer le chemin avec un langage de requêtage qui permet de faire à peu près tout des index qui permettent de gérer la performance de toutes les requêtes des index de tout type les transactions acides ça beaucoup de gens savent qu'on le fait pas sans rentrer dans les détails c'est les transactions qu'on attend par exemple quand on a une application bancaire Je ne crée pas de l'argent ou je ne détruis pas de l'argent quand je fais une transaction monétaire.

36:56 C'est un peu grâce à ça qu'on le fait. On le fait en multineux, multidocument. Ça a pris des années à développer, ce n'est pas rien. Mais c'est ça aussi qui nous permet, je ne vais pas donner les noms des clients aujourd'hui, mais vous trouvez toutes les références en ligne, mais c'est ça qui nous permet d'être au cœur de systèmes de paiement ou de banque de détail. J'ai mis un petit lien dans le chat sur le cap théorème qui reprend ça. Et en fait, c'est en effet assez... C'est peu intuitif d'imaginer des transactions acides sur des systèmes NoSQL qui ont plutôt pour but de la disponibilité en général. C'est là où Mongo se différencie beaucoup aussi. J'ai hésité à parler du cap théorème, mais j'avais peur de passer trop de temps à l'expliquer. Il y a ce compromis toujours entre dispo et cohérence. Nous, on favorise la cohérence, mais en mettant le déploiement qui va bien, honnêtement, la dispo, ce n'est pas vraiment un problème non plus. Et là encore, je fais un peu une erreur en disant ça, ce n'est pas tout à fait le même type de cohérence.

38:00 Ce n'est pas le même type de dispo, mais si un jour quelqu'un veut creuser, encore une fois, contactez-moi sur LinkedIn, on pourra avoir des discussions théoriques si ça vous intéresse. Alors j'avance, ça c'est juste la petite preuve, et ceux qui utilisent du relationnel ou du MongoDB ou les deux, n'hésitez pas à télécharger cet outil qui peut vous montrer un peu comment passer de l'un à l'autre et pourquoi pas faire vos prototypes. Ça va très vite de passer, vous vous connectez à votre base relationnelle, vous vous connectez à votre cluster MongoDB Atlas, il y a un niveau qui est gratuit, vous pouvez créer déjà un petit cluster et vous pouvez tester la migration de l'un vers l'autre pour voir comment ça marche. Le dernier point. Ça dépasse un peu la résilience, mais c'est quand même pour moi, s'il y avait une force de MongoDB que je voulais mettre en avant par rapport à des DBA relationnels, etc., c'est les évolutions de documents, les évolutions de schémas. En relationnel, quand on veut modifier quelque chose, donc par exemple, avant j'avais

39:02 deux adresses et maintenant je vais avoir un tableau d'adresses, je suis obligé de créer des nouvelles tables de relations, je suis obligé de modifier mon code et puis surtout je suis obligé de prévoir des scripts de migration SQL à appliquer sur mes différents environnements, packager, tester. Ça je le faisais chez Voyage et SNCF, j'étais Scrum Master, mais j'échangeais beaucoup avec l'intégrateur, avec la prod. En fait, c'était vraiment un projet à chaque fois. Et puis, il fallait arrêter le système. Alors, le nœud, on le sortait, on n'était pas stable. state pool, heureusement, c'est beaucoup plus simple. Mais malgré tout, il faut sortir le nœud, il faut appliquer les opérations de maintenance, il faut serrer les fesses, si on a des expressions, et on espère que ça va marcher, etc. Avec Mongo, on peut stocker des documents au format différent, dans la même collection, au même endroit, l'équivalent de la table. Et finalement passer de l'un à l'autre. Je le gère dans mon applicatif, les deux formats, et je vais pouvoir migrer les documents, ou pas d'ailleurs, c'est un choix, mais si je le souhaite, je peux le faire à la demande ou en bas. En tout cas, encore une fois, on n'arrête pas la base de données alors qu'on fait évoluer le schéma de données.

40:05 Donc en termes de productivité et pour éviter les désastres, je trouve que c'est quand même assez important. Atlas en quelques mots, je vois qu'il est midi 40. Encore une fois, on a le même cœur de produit entre notre version, elle n'est pas ici, mais la version open source communautaire, la version Enterprise Advanced qui va être self-managed pour vous sur vos clouds, vous achetez des licences, ou Atlas qui est notre version cloud-managée par nous-mêmes. Donc le cœur du produit est le même. Le principe des répliques à 7, le principe des documents, toutes ces choses-là, c'est la même chose. Donc on en bénéficie toujours, mais évidemment, le niveau d'implication que vous allez avoir à mettre pour maintenir tout ça et gérer vos DRP, il va être de plus en plus décroissant au fur et à mesure qu'on manage des choses pour vous. Atlas, ce n'est pas uniquement MongoDB dans le cloud, c'est aussi des services en plus.

41:08 C'est-à-dire que, sans rentrer dans les détails, vous allez pouvoir faire du full text search. C'est basé sur Apache Lucene, comme d'autres solutions. Vous allez pouvoir faire du vector search, ça c'est pour les cas IA. Vous allez avoir de la gestion de time series, stream processing pour réagir par exemple sur des événements Kafka ou sur une collection et écrire dans une autre ou dans un Kafka. En gros, vous allez pouvoir construire des architectures un peu plus avancées sans avoir forcément recours à des systèmes externes, ce qui permet de simplifier. Et d'avoir évidemment de réduire les risques et les coûts avec toujours ces points forts de performance, de résilience, de scalabilité et de sécurité. Et enfin, un point extrêmement différenciant, c'est qu'on est multi-cloud, je crois qu'on est sur 115 régions maintenant, Donc, multi-cloud, ça va être la possibilité de déployer dans un même cluster des nœuds sur plusieurs clouders, soit parce que j'ai une région qui n'est pas dispo sur l'un, soit parce que je veux commencer à avoir de l'out-dispo beaucoup plus élevé.

42:13 Je vous propose de regarder à quoi ça ressemble. Sur cet aspect-là de déploiement dans les cloud providers, l'intérêt majeur que nous on voit, c'est aussi de se dire qu'en fait, vous pouvez bénéficier d'un service manager qui n'appartient pas nécessairement au cloud. provider, mais qui est quand même à une certaine proximité réseau, qui fait qu'on n'est pas en train de se dire, ok, en fait, ma base de données est très, très loin, et donc je perds complètement en performance, voire en sécurité, parce que c'est déployé ailleurs. C'est vraiment au cœur même de l'infra, techniquement, c'est proche. Il y a la latence évidemment aussi qui joue, on va pouvoir se mettre au plus proche. Je vous montre juste l'interface d'Atlas, n'hésitez pas à créer un compte, vous pourrez faire des choses avec les versions gratuites ici. Quand je crée un cluster, par exemple ici je choisis AWS à Francfort, On va choisir le type de machine. Donc ça, à étudier par exemple avec moi ou un de mes collègues, en fonction de ce que vous allez faire.

43:15 Différentes machines avec différents prix, mais c'est surtout en fonction des types de requêtes, de la data que vous allez stocker, des performances. En fait, c'est aussi simple que ça. Appliquer le backup, c'est un bouton. Deux niveaux de backup, soit c'est des snapshots. Donc là, si vous vous rappelez bien, le RPO va être... jusqu'à une heure, mais on ne pourra pas descendre en dessous d'une heure. On fait des photos de vos datas. Donc, c'est la solution entre guillemets économique. Par contre, si vous avez besoin d'aller à un RPO d'une minute ou moins, on va activer le continuous cloud backup. C'est-à-dire qu'entre chaque photo, on va également stocker toutes les opérations qui ont eu lieu. Comme ça, on pourra les rejouer si jamais il faut restaurer les données à un instant T. Et ce qui nous intéresse dans la résilience, L'étoile ici va indiquer région recommandée. En fait, qu'est-ce que ça veut dire? Je prends l'exemple AWS. À Francfort, on va avoir au moins trois availability zones. C'est-à-dire que c'est des data centers qui sont séparés. Je ne connais plus la règle exacte chez AWS, mais qui ont un certain nombre de kilomètres au moins entre eux.

44:21 Ce qui fait que là, par exemple, j'ai trois nœuds dans mon cluster. Automatiquement, ils sont assez éloignés les uns des autres. Si jamais il y a une panne sur un data center, il me reste deux nœuds qui assurent mon service. Alors, il est dégradé, parce que je n'ai plus que deux nœuds, mais il continue à tourner. Sans problème. On a toujours le fait de répliquer la donnée à deux endroits quand on écrit. C'est pour ça qu'on a trois nœuds également. Ensuite, si on va aller plus loin, j'active ici multi-cloud, multi-région et workload isolation. En fait, c'est aussi simple que ça de se dire, je suis sur AWS, on va aussi déployer à Paris. Donc là, il m'a mis trois nœuds. 3 nœuds, 2 nœuds. Sans rentrer dans tous les détails, il donne les configurations recommandées, mais il y a toujours des trade-offs. On peut mettre un nœud sur chaque région aussi. C'est tout à fait acceptable, mais il faut bien creuser sur ce que ça veut dire. Mais par exemple, ici, je peux avoir 3 nœuds. Et ce que j'aime bien dans Atlas, c'est qu'il nous prévient ici sur ce qu'on est en train de faire.

45:23 Donc là, il me dit, grâce à cette configuration, s'il y a une panne d'une région cloud, ta base de données est encore disponible. Alors, pardon, partial, c'est un des data centers, et full, c'est toute la région. Donc, si Francfort n'est plus accessible, On va continuer à fonctionner sur Paris et Milan. Sachez qu'il y a un ordre de priorité. Donc là, vous allez pouvoir gérer, par exemple, si vos applications sont à Francfort et pas forcément multi-régions, vous allez peut-être favoriser en secondaire une région plus proche. Comme ça, si Francfort tombe, vous gardez des bonnes latences. Il y a plein de paramètres à prendre en compte. Mais vous voyez comme c'est simple à mettre en place. Et si je mets un nœud sur chaque, alors je vais mettre un peu au hasard pour aller vite, sur chaque cloud d'heure, il me dit qu'on va pouvoir résister à la panne d'un cloud provider. Donc en fait, ce qu'on va faire en termes, est-ce qu'on met trois nœuds, cinq nœuds? Ça, encore une fois, c'est des discussions. Mon niveau d'assurance, puisque ça augmente les coûts, mon niveau d'assurance par rapport à mon risque. Une application extrêmement critique. Ce qu'on recommande, c'est d'avoir deux nœuds sur les deux régions principales et un nœud sur la dernière.

46:30 fait que même si une région tombe, il m'en reste trois. Et 3, ça fait que j'ai une version encore« golden» de mon GoDB qui tourne. Mais à réserver aux applications les plus critiques. Je précise que tout ça est évidemment terraformable. À bon temps. Oui, excellente remarque. Évidemment, en démo, je montre l'interface graphique, mais il y a les API, on peut le faire en ligne de commande, et évidemment avec Terraform. Vous allez pouvoir gérer vos backups ici. Sans rentrer dans les détails, il y a un point quand même. Que je vais vous montrer, alors sinon j'ai la slide, mais on configure son backup et en fait, je disais tout à l'heure, qu'est-ce qui se passe si une région tombe, mais que mes backups, ils sont stockés dans cette région. Alors c'est arrivé, bon, je n'ai pas accès à mes backups, c'est un peu dommage, je les avais mis au même endroit, donc on va pouvoir... Envoyer une copie des backups aussi sur d'autres régions. Donc ça, c'est super important. C'est vraiment des choses à anticiper.

47:32 Et tu me parlais de sécurité quand on avait préparé la session. Donc évidemment, ça fait aussi partie de la résilience. La prévention des attaques, ça passe par la sécurité. Le niveau de base minimum, c'est de choisir les IP qui peuvent se connecter, en whitelist. Mais on va aussi pouvoir, avec les clouders, faire du peering, voir des private endpoints. Par exemple, sur AWS, c'est le private link. Il faut vraiment s'assurer, avec private link, que le flux ne passe même pas par Internet. Vous avez vos... vos nœuds applicatifs dans votre région AWS. Nous, on a vos nœuds MongoDB dans notre région, on crée un lien direct, ce qui va permettre aussi de minimiser au maximum les attaques, etc. Et le très bon goût que vous avez sur cette fonctionnalité, c'est qu'elle n'a pas de surcoût. Et ça, du coup, nous, c'est quelque chose, c'est un no-brainer. Tous les secops se... Sautent sur leur chaise quand ils voient qu'on contacte direct Mongo en connexion directe. L'idée, c'est de faire du private link parce que c'est packagé avec ce que vous payez déjà, donc c'est une évidence.

48:38 En plus, c'est compatible multirégion. Alors, on rentre sur des architectures un peu plus compliquées, mais vous pouvez justement... Vous faites votre redondance niveau applicatif, vous déployez vos nœuds applicatifs sur plusieurs régions, vos nœuds applicatifs seront connectés aux nœuds de base de données les plus proches. Et évidemment, on gère aussi la réparation automatique. Tout ça, c'est des choses qu'on sait faire. Ah ben voilà, je savais que j'avais oublié de vous montrer quelque chose. Je ne vous fais pas de démo parce que c'est la démo la plus ennuyante, ennuyeuse, ennuyante, je ne sais jamais. J'ai une démo où j'écris sur ce cluster et je fais une panne et il continue à marcher. Ce n'est pas super bien à voir, super entertaining. Mais on parlait de test tout à l'heure. C'est prévu dans Terraform, mais aussi dans l'interface de Mongo. Donc j'ai mon cluster, je veux valider que mon application utilise bien le cluster et que j'ai tout bien configuré pour que ça continue à fonctionner en cas de panne.

49:40 On vous donne carrément les outils dans l'interface. Soit je fais tomber un nœud, je le rends inaccessible, et je vérifie qu'avec l'élection d'un nouveau primaire, ça continue à marcher. Soit, dans le cas du multirégion, on peut carrément faire disparaître une région et voir ce qui se passe côté applicatif et ce que mon appli continue à fonctionner. Ok, donc ça c'est... une fonctionnalité de... C'est un chaos monkey inclus dans le... Dans Atlas. Dans Atlas, OK. Oui. Ça, c'est important. On l'a dit tout à l'heure. Il faut les tester. Même toi, tu as ressouligné le point. Il faut tester ses plans. Donc, j'avais prévu mes slides, mais j'ai déjà tout dit à l'oral. Mais rappelez-vous. Ça, c'est un cas, encore une fois, c'est arrivé. En fait, quand on le dit, c'est comme quand on étudie les accidents des avions, il y a des choses qui ont l'air évidentes, mais tant que ce n'est pas arrivé, des fois, il y a des trous dans la raquette. Donc, stocker les backups au même endroit qu'une région cloud, Et quand la région clave disparaît, je n'ai plus accès au backup, c'est arrivé.

50:44 J'en profite, il y a deux questions dans le chat, je les laisse les traiter dans le chat. Il y en a une première sur des fonctionnalités de Mongo qui sont dépressées, certaines parties des services qui sont dépressées. Au profit éventuellement d'autres, savoir un petit peu ta vision là-dessus. Et la seconde, un peu plus technique sur le chiffrement à 13, est-ce qu'il est possible d'avoir des clés stockées à l'extérieur du coup d'Atlas, j'imagine, sur l'exemple AWS, KMS? Ok, bonne transition. Je commence par la sécurité, c'était ma slide suivante. N'étant pas expert, c'est vrai que je ne rentre pas toujours dans les détails, les données sur Atlas sont chiffrées à 13 par défaut. On a aussi le chiffrement réseau avec TLS. On va pouvoir utiliser avec KABIP un KMS externe. Ça, c'est important. Et un gros différenciant, vous voyez ici, Cloud KMS, c'est Client-Side Field Level Encryption.

51:46 Maintenant, ça a été remplacé par Queryable Encryption. Ça, ça veut dire qu'en fait, la donnée est chiffrée jusqu'au client, jusqu'à votre application. N'importe personne, même quelqu'un qui a accès à la base de données, ne peut comprendre les données sur ces champs-là. Donc, quand vous avez des données sensibles, on va les chiffrer de cette manière-là. Il peut même y avoir une clé générée dynamiquement. Et l'idée, c'est que c'est vraiment que côté client que la donnée est déchiffrée. On va se dire, c'est un peu embêtant pour requêter. Ce qu'on propose avec Curable Encryption, c'est de pouvoir requêter ces données-là, même sans connaître le contenu. On vient de sortir MongoDB 8.0. Jusqu'à maintenant, on supportait l'égalité. Donc, je veux que ce champ soit égal à telle valeur. Maintenant, on supporte aussi les range queries. Donc, par exemple, je ne sais pas, j'ai des montants de comptes bancaires. Je n'ai pas le droit de les voir ou des salaires ou ce genre de choses. Je vais quand même pouvoir faire une requête qui dit supérieur à 2000.

52:50 Et ça, c'est quelque chose d'assez fort. Est-ce que ça a un impact sur les performances? Ça me fait penser à l'homomorphique encryption. Qui est un secteur large, sur comment est-ce qu'on peut traiter des données chiffrées. Et je sais que là-dedans, il y a beaucoup d'impact sur les performances. Je n'ai pas les chiffres, mais il y a forcément un surcoût. C'est pour ça qu'on ne chiffre pas tous les champs. Oui, bien sûr. Par exemple, on va choisir les champs les plus critiques. Mais bon, pensez à l'actualité, pensez aux IBAN, pensez à des choses comme ça. Se dire que même si un acteur malveillant arrive à accéder à une base de données parce qu'il y a un trou dans la raquette, c'est quand même important de savoir que... Même s'il a un accès admin, parce que c'est ce qui s'est passé dans les attaques récentes, il y en a qui ont réussi à accéder à des outils internes des entreprises, même les admins n'ont pas accès à la data. Et l'autre question, c'était sur les fonctionnalités qu'on a dépréciées, c'est ça? Oui, tout à fait.

53:51 Alors, je n'ai plus les exemples exacts, mais c'est un article de... L'exemple, c'était DeviceSync. Oui, c'est ça. En fait, on a arrêté App Services dont DeviceSync faisait partie. Je ne suis pas assez haut placé dans l'entreprise pour avoir tous les détails. Ce que je peux vous dire, c'est que MongoDB, en fait, a une gestion financière très, très, très, très fine. Et en fait, en permanence, en train de chercher à optimiser les choses. Ce qu'on a vu, c'est que clairement, le ROI de ce système-là n'était pas... n'était pas à la hauteur, c'est-à-dire qu'en termes de nombre d'utilisateurs, ce n'était pas une fonctionnalité si utilisée que ça. Donc, en ce qui concerne le devising précisément, il y a de la valeur. Pour ceux qui ne connaissent pas, c'est la possibilité d'avoir une base de données en local, soit pour de la UTI, soit sur un smartphone ou autre, et de gérer une synchro avec Atlas. Même si le device est offline.

54:56 En fait, on s'est rapprochés de partenaires. Là, il vaut mieux que vous contactiez. mes collègues de Mongo, votre responsable commercial ou autre, pour avoir les éléments. Mais en fait, je sais que chez plusieurs clients, on est déjà en train de travailler avec des partenaires qui sont spécialisés dans ce genre de solutions pour faire une transition. Donc ça, c'est vraiment cette idée-là. Et ensuite, en vrai, on cherche à se focaliser sur... À se refocaliser sur la base de données, même si c'était des services à valeur ajoutée. Donc, le stockage et le requêtage de la donnée. Donc, la base de données en elle-même, le full text search, le vector search pour les usages IA, ça, c'est les points vraiment cruciaux. Et petite parenthèse, la 8.0 est sortie. La plus grosse annonce, en fait, c'est la performance. On a explosé tous nos benchmarks de performance parce qu'on a remis un focus là-dessus. Donc, on veut que les clients qui démarrent ou qui sont déjà sur MongoDB puissent avoir les performances optimales et donc aussi optimiser leurs coûts.

56:02 Avec un cluster tier, par exemple, dans la classe de M30, on peut faire beaucoup plus de choses avec la Vizio. Sur certains use cases, c'est toujours à étudier. On est là pour ça, pour creuser avec vous. Est-ce qu'il y a une autre question sur le chat ou je termine? Écoute, non, on a fait le tour des questions. Il est 56, je te propose. De passer quelques minutes à... Ok, je passe en 10 secondes sur chacune des dernières slides, c'est juste pour vous expliquer qu'on s'intègre évidemment Avec les différents clouders, là, j'ai choisi AWS parce que j'ai travaillé avec un client qui est AWS récemment. On va pouvoir faire des architectures avec toutes les différentes briques, surtout avec le private endpoint ou le peering connection où on a des liens faciles. Et évidemment, en tant que Solutions Architect, c'est un diagramme qui a été fait par un collègue avec un client en live sur comment il allait pouvoir gérer son multirégion applicatif et MongoDB. Ou encore une fois, si vous avez un sujet DRP multi-cloud, on va pouvoir travailler avec vous. Ici, on est sur 7 nœuds avec du AWS, du GCP et du Azure.

57:08 Juste la petite conclusion, vous vous rappelez le cahier des charges, en fait l'idée c'est que c'est ce qu'on propose avec Mongo, donc vous pourrez le relire après. Moi ce que je pense vraiment c'est que si la base de données est hautement disponible, vous enlevez une énorme épine du pied. Parce que non seulement vous n'avez pas à gérer de disaster recovery, mais vous n'aurez pas non plus à poser des questions sur est-ce que les données que j'ai sont vraiment cohérentes, est-ce que j'avais différents threads qui ont écrit des choses en parallèle sur deux primaires. Tout ça, c'est des problèmes qu'on a typiquement quand on essaye de gérer soi-même la réplication et ce genre de choses. Et l'idée là, c'est que mettez le bon niveau de résilience dans votre cluster MongoDB et vous aurez la sérénité. Et donc, vous pourrez être comme ce fameux personnage. Personnage en cas de désastre. Oui, tout à fait. Nous, c'est vraiment ce message-là, c'est celui qu'on porte à nos clients également.

58:10 Investir dans un service manager, c'est toute une charge, déjà une charge mentale pour les gens qui sont responsables de ça et même un investissement dans des profils spécifiques qu'on ne fait pas. Et c'est vraiment un modèle qu'on va recommander dans 99% des cas. Merci beaucoup. Petite, petite. Oui, vas-y, pardon. Juste une toute petite parenthèse, mais cet été, comme j'étais encore en formation, j'ai fait des exercices, en fait, de manager tout ça moi-même. Donc, j'ai fait des scripts, Ansible et tout ça, même Shell, pour déployer les nœuds, gérer toutes sortes de choses. Et en fait, au bout d'une semaine, j'ai dit, mais Atlas, c'est génial, en fait. Autant j'aime bien ce côté geek, mais en fait, au bout d'un moment, je n'en pouvais plus. Je me suis dit, mais c'est quand même super de pouvoir cliquer sur un bouton et d'avoir tout qui se déploie tout seul. Oui, tout à fait. Et c'est ça, c'est l'assurance qu'on paye, comme tu le disais, c'est vraiment ça le calcul. Merci beaucoup, Brice, pour cette superbe masterclass. Pour info, il y aura une prochaine masterclass le jeudi 28 à midi en anglais, cette fois-ci sur plutôt l'aspect applicatif des systèmes distribués et comment est-ce qu'on peut protéger tout ça.

59:24 Par ailleurs, je serais personnellement, je crois que tu y seras aussi, Brice, au Tech.Rocks Summit. On pourra évidemment continuer. À échanger sur ces sujets avec grand plaisir. Merci à toutes et tous d'être venus. Et cette fois-ci, bon appétit. Et à très bientôt.