Architecture : les meilleures pratiques du moment

0:03 Bonjour à tous, je suis très heureuse d'animer ce meet-up sur l'architecture, comment dire, l'architecture qui est une question clé lorsqu'on est CTO et lorsqu'on pense l'évolution de son système d'information ou de son application. Et j'ai le plaisir aujourd'hui de vous annoncer que ce soir, trois speakers Stéphane Landelle qui est CTO d'Arolla, qui va nous parler de pourquoi et comment mettre en place des tests de performance au niveau de son architecture. Il y a également Cyril Marcraire, CTO de Arolla, pardon Stéphane Landelle, CTO de Gatling, pardon. Et Cyril Martraire, CTO d'Arolla, qui va nous parler de l'architecture à l'échelle. Et enfin, Arnaud Lemaire, député CTO de LGO, qui va nous montrer comment réfléchir son architecture via les concepts de complexité et localité nous permettent d'acter de bonnes décisions. Sans plus tarder, je demande Stéphane, peux-tu me rejoindre sur scène?

1:14 Il faut que je trouve... Oui, donc Stéphane, je rappelle, CTO de Gatling, qui va nous faire 15 minutes à 20 minutes de présentation. Et après, s'en suivront les questions. Alors, est-ce que vous me voyez, vous m'entendez? Oui, on t'entend. Super. Bonjour à tous. Je ne sais même plus comment ça se fait. Excusez-moi. Bon, ce n'est pas grave. On va faire comme ça. Bonjour à tous. Je m'appelle Stéphane Landelle. Effectivement, je suis le CTO de Gatling Corp, qui est l'éditeur d'une solution de test de charge. Aujourd'hui, je vais vous parler de... De perf, des impacts sur l'archi, pourquoi se soucier des perf et comment s'y prendre. Donc petite intro rapide, Gatling c'est un projet open source que j'ai fondé il y a déjà pas mal d'années et donc le projet a pris de l'empereur et donc au bout d'un moment on s'est décidé à lancer une société pour être l'éditeur de ce logiciel.

2:19 Donc voilà, on est français. On est hébergé à Station F. Et donc, comme tous les éditeurs, on a un noyau open core, cette solution Gatling qui est toujours open source, sous licence à page 2, et puis on propose une version entreprise construite au-dessus, et puis voilà aussi du service de l'accompagnement, etc. Voilà, donc sans plus tard. On va rentrer dans le vif du sujet. Alors, en intro, je voudrais parler un peu du job du CTO. Le job du CTO, c'est de garantir le bon fonctionnement de l'IT au quotidien. Donc voilà, s'assurer que les applications tournent et puis que l'IT va être capable d'accompagner la croissance du business. Donc, à ce jour, et puis également par rapport aux prévisions business que vous avez d'ici un an, deux ans, etc. Donc, ça veut dire être capable d'anticiper, de prendre des décisions maintenant pour être capable d'anticiper, pour être capable, pour garantir que l'IT va pouvoir suivre le business. Tout ça, c'est un job de pilotage, donc il y a besoin d'input.

3:21 Notamment, il y a besoin d'avoir de la visibilité sur la manière dont se comportent les applications. Autre petite clarification aussi, les tests. Tous dans nos applications, on fait des tests. Maintenant, les tests, ça sert à quoi? Souvent, on perd de vue que les tests, ça sert à garantir le bon comportement de l'application une fois qu'elle est en prod. Le workflow classique, c'est les développeurs ont développé quelque chose. Donc, une fois qu'ils sont dans l'état« work on my machine», ils vont pousser ça en QA. Donc, que ce soit une équipe, que ce soit de l'intégration continue, peu importe. Et une fois que ça passe la QA, on va pouvoir passer ça en prod. La question, c'est justement sur cette dernière étape, le passage de l'environnement de QA à l'environnement de prod. En quoi est-ce que les conclusions auxquelles vous avez abouti sur la base de votre environnement de QA, elles sont extrapolables pour permettre de passer en prod? Ce n'est pas parce que vous avez fait tourner des petits tests d'intégration avec trois jeux de tests dans la base de données que votre application va se comporter correctement en prod.

4:32 Donc, si votre architecture est complètement différente, si votre infra est différente, si votre trafic est différent, si le volume de données à manipuler est différent entre ce que vous avez sur la QA et ce que vous avez sur la prod, votre extrapolation, ça se trouve, elle repose sur rien. Peut-être qu'elle repose sur quelque chose, peut-être que c'est volontaire, vous avez peut-être fait ce qu'on appelle une mise à l'échelle, vous avez fait tourner des tests avec moins de données, avec moins d'utilisateurs, et vous vous êtes dit, Vous essayez d'extrapoler, vous savez que ce n'est pas parfait. comme méthodologie, au moins, vous avez des hypothèses sur lesquelles repose votre extrapolation. Très souvent, ce qu'on voit, en fait, c'est que le problème est complètement occulté. Il n'y a pas d'extrapolation et on ne se soucie pas vraiment de comment ça va se passer en prod. On a l'impression qu'on a un produit fini et garanti une fois que ça a passé les tests fonctionnels. Ça ne marche pas comme ça, très souvent. Donc, les pertes peuvent être un enjeu. Alors attention, je dis que les pertes ne sont pas systématiquement un enjeu. Ça, c'est vous qui le savez. Vous développez une application qui va encaisser peu de trafic, une petite application qui est tranquille.

5:40 La perte ne peut pas être un enjeu pour vous. En revanche, il y a tout un tas de situations dans lesquelles, au contraire, la perte est un enjeu. Si vous avez une application qui est critique pour votre business, à la fois pour votre source de revenus, parce que vous faites un site e-commerce, ou parce que l'application, c'est votre cœur de métier et c'est l'outil qui est utilisé au quotidien par vos employés. Il ne s'agit pas qu'elle tombe ou qu'elle se mette à mouliner ou à faire n'importe quoi, parce qu'à ce moment-là, c'est toute votre organisation qui est bloquée, qui n'arrive plus à travailler. Si votre application, elle doit encaisser un trafic qui est conséquent, ou alors qui est fluctuant. Par exemple, une application, un site e-commerce qui se prend un trafic assez stable durant l'année et qui se prend des gros pics durant les périodes de solde de Black Friday. Ça peut être aussi une... voilà la déclaration des impôts voilà il ya plein d'applications où ça peut être même simplement tacou tiens ça y est vous faites le buzz voilà vous passez au journal de jean pierre pernault

6:42 et donc vous faites le buzz donc vous allez peut-être multiplier comme ça votre trafic par 100 de manière subite Si votre application doit manipuler des volumes de données qui sont conséquents. Également, si vous avez des perspectives de croissance, ça c'est important. Quand vous construisez un MVP, l'objectif d'un MVP, ce n'est pas de tenir la perf, c'est de démontrer un produit, démontrer un marché. Et donc, vous allez faire des choix de technologie, d'infrastructure, d'architecture qui vont permettre d'aboutir à ce résultat rapide, pour être rapidement sur le marché. Le MVP que vous avez construit, ce n'est peut-être pas du tout l'implémentation qui va vous permettre de faire votre seed, mais peut-être pas l'implémentation qui va vous permettre de faire votre série A, et encore moins votre série B, et encore moins votre série C. Et ça, il faut le savoir. Il faut savoir jusqu'où ce que vous avez construit sur la base de votre MVP, jusqu'où il est capable de vous accompagner en termes de croissance. C'est ça. Oui. Est-ce que tu peux mettre ta présentation en full screen, s'il te plaît?

7:48 Il y a présenté, tu dois avoir accès à un bouton présenté. Oui. Voilà. Donc, est-ce que ce que vous avez construit sur la base de votre… MVP, il va être capable de vous accompagner jusqu'à quel point il va être, à quelle salle il va être capable de vous accompagner. Et sachant que réécrire un produit sur une nouvelle archi, sur peut-être des nouvelles technos, peut-être avec des équipes différentes parce que c'est des technos différentes, ça ne se fait pas du jour au lendemain, il va falloir l'anticiper. Si votre architecture est complexe, on a beau dire que les monolithes, c'est plus facile à exploiter que des microservices. Donc, il ne s'agit pas que votre architecture, votre service mesh, s'il y a un composant, se casse la figure, que ce soit tout qui s'écroule comme un jeu de cartes. Et puis, si vos choix technologiques sont encore mal maîtrisés, si vous êtes en train d'introduire des nouvelles technos et que vous pensez à monter un POC et que ce POC soit consistant, il fasse du sens par rapport à votre cible.

8:53 Moi, j'ai vu... J'ai vu dernièrement un client qui avait choisi une certaine base de données NoSQL. Et ils ont monté le truc dans leur coin, sans jamais solliciter l'éditeur, sans jamais solliciter des experts, en apprenant un peu sur le tas. Et puis, au bout de deux ans, une fois qu'ils ont fini de construire tout leur truc et de passer en prod, ils se sont rendus compte que ça ne tenait pas. Ils ont fait appel à l'éditeur. L'éditeur leur expliquait que pour pouvoir faire tourner leur solution, il leur fallait, par rapport à leur cas d'utilisation, des serveurs avec 64 Go de RAM. Et là, ils se sont rendus compte que leur hébergeur n'était pas capable de fournir ce type de machine. Donc, les choix technologiques, ça se valide avant d'avoir construit. Les performances, ce qui dit performance, dit risque en fait. À ne pas adresser vos problèmes de performance, à avoir des problèmes de performance, vous risquez d'endommager vos ventes, vos sources de revenus, vous risquez d'encorner l'image de la marque. On a très souvent comme ça des buzz sur un grand nom, sur une grande...

10:00 De marques qui s'écroulent. Qu'est-ce qu'on a eu dernièrement? Par exemple, il y avait eu Decathlon qui avait mis en vente un... Un vieux survet collector, enfin une réédition. Et donc, ils ont bien fait le buzz. Et le jour où ils l'ont mis en vente, ils sont écoulés. Donc après, vous avez les community managers qui essaient de rattraper le coup, qui racontent, super, il y a eu énormément d'engouement, vous nous adorez, on vous adore aussi. Bon, mais c'est un peu essayer de sauver les meubles. Et puis, le risque aussi, c'est d'augmenter ses coûts d'exploitation. J'ai d'autres exemples avec de l'autoscaling qui a permis de ne pas faire tomber la prod, mais qui a multiplié les coûts d'exploitation par deux ou par trois. Donc, surveiller aussi. Malgré tout ce que je vous raconte, il y a des chances qu'un certain nombre d'entre vous ne fassent pas de test de charge. Alors, pourquoi? Parfois, c'est de l'excès de confiance. On se dit qu'on est des super ingénieurs, qu'on a fait du super boulot, et c'est perte de vue le fait que l'erreur est humaine, qu'on a tous le limite et qu'on est capable de se planter.

11:04 Autre chose aussi, c'est s'imaginer que le scaling out, ça résout tout. Il y a encore plus cet effet-là avec maintenant le cloud, où rajouter des machines, ça se fait très rapidement. Ça peut même se faire de manière automatique. Sauf que, comme je vous disais, ça peut... Ça peut faire exploser beaucoup d'exploitations et puis ça introduit également une complexité supplémentaire. Moi, je me souviens de... J'avais un exemple, j'étais intervenu chez un client qui était un grand nom de l'immobilier en France. Et ça faisait des mois et des mois, même des années, qu'ils avaient des fuites mémoires. Et elles s'empiraient en fait. Et donc, ils rajoutaient de la RAM, ils rajoutaient de la RAM, ils rajoutaient de la RAM. Quand je suis intervenu chez eux, ils avaient un serveur TomCat qui tournait avec 32 Go de RAM. Et ils étaient absolument incapables d'exploiter correctement un tel serveur. Donc, je suis intervenu, on a réglé le problème, on est revenu avec... Et en plus, ils redémarraient le serveur deux fois par jour.

12:05 Donc, vous avez des clients, vous avez une recherche pour essayer de trouver un appart, tout le mettre en ligne. Voilà, le serveur redémarrait à midi, à 18h. Ce n'était pas franchement une situation idéale. Et en fait, on a adressé le problème et on a ramené la IP à 256 Mbps en réglant les problèmes de fuite mémoire. Dernier point aussi, et là c'est votre rôle, c'est le manque de soutien de la hiérarchie. C'est-à-dire que les équipes tech sont conscientes du fait, les équipes de développement sont conscientes du fait qu'il faudrait qu'ils fassent des tests de charge, qu'ils ne sont pas du tout confiants sur ce qu'ils vont mettre en prod, sur la manière de travailler au quotidien, mais la hiérarchie impose une course à la feature et il n'y a jamais de temps pour des user stories techniques qui sont perçus comme ayant peu de valeur. Donc ça, c'est votre responsabilité en tant que CTO d'analyser les risques et de mettre des moyens en face. Alors, les tests de charge, qu'est-ce que c'est exactement ? Donc, les tests de charge, ça consiste à utiliser des outils pour aller simuler du trafic sur vos applications avec différents types de profils.

13:10 Et donc, ces différents types de profils, ça va correspondre soit à des situations réelles sur la prod, soit à des situations qui sont imaginées. De se dire, qu'est-ce qui se passe sur cette application si dans un an, on fait x2 sur le trafic? Qu'est-ce qui se passe si on améliore notre taux de conversion et si au lieu d'avoir 10% de gens qui achètent les produits, on passe à 20 ou à 30%? Est-ce que le site s'écroule? Donc, il va vous falloir définir des exigences de performance. C'est souvent un truc qui est loupé. Et en fait, c'est la partie, en réalité, moi, je trouve que c'est la partie complexe dans les tests de charge. C'est la partie métier, c'est définir la partie métier des tests. Donc pour définir ces exigences, il va falloir déjà impliquer tout le monde. Il va falloir impliquer les gens du métier, parce que c'est eux vos donneurs d'ordre, c'est eux qui ont accès souvent aux analytics sur la prod, c'est eux qui ont accès aux projections business. Donc ils sont...

14:11 Voilà. Ensuite, vous avez souvent besoin des gens de la QA. Parce que souvent, c'est des gens qui vont penser à des use cases qui ne sont pas... L'Usquest Nomino. Là où les développeurs vont se concentrer au contraire souvent sur l'usquest nominal. Eux, ils vont penser, voilà, ah, mais qu'est-ce qui se passe? Et c'est souvent là que le bas blesse. Et puis, vous allez avoir besoin des ops, parce que c'est eux qui vont dimensionner l'infra, c'est eux qui vont être sur le pont au quotidien sur la prod, et c'est eux qui vont être appelés à 2h du mat si la prod tombe. Il va falloir définir un process. Monter des tests de charge, comment est-ce que vous faites rentrer ça dans le dans le cycle de développement. Mon premier conseil, c'est de commencer petit si vous n'avez encore jamais fait de test de charge. Définir les priorités, vous concentrer sur les applications les plus critiques, celles avec le plus d'enjeux.

15:14 Souvent, vos architectures vont être complexes. Il va y avoir plein de composants et en fait, il va y avoir une sorte d'architecture en oignon entre au plus profond la donnée et les applications qui manipulent la persistance et la donnée. Et puis, plus on va vers l'extérieur, plus on se rapproche des couches qui sont visibles du point de vue utilisateur. Donc, commencez par tester les couches basses. Votre architecture, souvent, ça va être un ensemble complexe. C'est difficile de raisonner sur des ensembles complexes. Donc, l'idée, c'est d'aller découper votre problème en plus petits problèmes. Essayez de travailler un peu plus en isolation, quitte à moquer des dépendances. Autre chose aussi sur laquelle il va falloir vous interroger, c'est est-ce que vous faites des campagnes de tests de charge qui sont manuels? Où est-ce que vous lancez les tests de charge depuis l'intégration continue? À quelle fréquence est-ce que vous faites ces tests de charge? Alors là-dessus, moi, j'ai deux conseils. Le premier, ce n'est pas attendre qu'il soit trop tard. Historiquement, les tests de charge, on les faisait au fin d'un cycle en veille, deux semaines avant la mise en prod.

16:19 Dans ce genre de situation, c'était des annonciateurs de mauvaises nouvelles, les tests de charge. Souvent, on se rendait compte que l'infra était mal dimensionnée. que l'archi n'était peut-être pas adapté, des choix de librairie ou de software n'étaient pas adaptés, des règles de développement n'étaient pas adaptées. Et quand il s'agit de reconsidérer des choix aussi structurants, c'est douloureux. Et en général, la date de mise en œuvre, on ne la tient pas. Autre chose aussi, ce qu'on faisait historiquement, je vous disais à la fin d'un cycle en B, ça veut dire que quand vous faisiez des tests de charge, vous les faisiez une fois tous les six mois, et entre temps, il se passait quoi? Les tests de charge partaient au frigo. Comme tous les tests, ils partaient, ils se retrouvaient plus maintenus. Quand il s'agissait de refaire tourner des tests en les ayant fait tourner depuis longtemps, souvent on repartait from scratch. Parce que déjà, les tests ne fonctionnaient plus sur la version à jour de l'application, mais en plus, on avait perdu la connaissance. Soit simplement parce que même on pouvait avoir les personnes en charge des tests qui étaient parties dans une autre équipe, quitter la société.

17:27 Même simplement parce que les gens ont oublié. Moi, personnellement, quand je ne touche pas à un code pendant six mois, c'est assez dur de me replonger dedans. Parfois, je n'y arrive pas. L'exemple à côté, c'est comment est-ce qu'on testait, comment est-ce qu'on construisait des ponts il y a 100 ans et comment est-ce qu'on les testait. On construisait le pont et puis à la fin, on essayait de faire passer des camions dessus. Si jamais le pont s'écoulait, on l'avait un peu mauvaise quand même. Donc il faut éviter ce genre de situation. Il va falloir définir des responsabilités. Qui met en place les tests? exécute et qui analyse les résultats. On voit souvent cette responsabilité, la responsabilité des tests de charge qui est confiée au QA. Si vos QAs n'ont pas un background technique, ils vont être perdus, franchement, parce que c'est une problématique qui est technique. Ils ont une valeur ajoutée sur définir les scénarios, sur donner du recul par rapport aux tests, etc.

18:28 Mais ce n'est pas leur métier de diagnostiquer ce type de problème. C'est vraiment une problématique technique. Donc, évitez de confier les tests de charge à des profils QA qui ne sont pas techniques, qui ne sont pas formés à ça. Vous avez peut-être aussi, c'est ce qu'on voyait historiquement dans les grandes organisations, il y avait des experts performance. Donc une petite équipe dédiée qui elle seule avait la connaissance et la compétence sur les outils et sur la problématique. Et donc à la fois c'était des équipes qui bossaient en boîte noire et puis elles se retrouvaient être une sorte de boulot d'étranglement pour l'ensemble de l'IT. Donc ça ne fonctionnait pas. Ce qui est intéressant, ce qu'on fait de plus en plus de nos jours, en fait, c'est le... Il y a peut-être besoin d'experts de performance, d'experts de performance si vous n'avez pas ce type de connaissances vraiment dans les équipes projet, pour aller diagnostiquer les problèmes, pour pouvoir aller les corriger. Peut-être qu'à un moment, il y a besoin d'experts. En revanche, sur toute la partie crafting des tests, la valeur ajoutée de vos experts, c'est si c'est...

19:30 Sur la rédaction des tests, confier le crafting et la maintenance des tests aux développeurs. Ils ont l'habitude de faire ce genre de choses et ils le font sur le reste des batteries de tests qui font tourner. Il va falloir définir une archi, une infra pour vos tests. Les tests de charge, ça va être un process qui est itératif. Vous allez faire tourner des tests, vous allez peut-être trouver un problème de perf, vous allez développer un fix, vous allez déployer le fix, vous allez valider le fix. Potentiellement, c'était l'arbre qui cachait la forêt, un premier goulot d'étranglement. Et puis, quand vous faites tourner les tests, vous allez tourner sur un deuxième goulot d'étranglement parce que vous êtes encore en dessous de vos objectifs en termes de perf. Donc, il va falloir itérer. Qui dit itérer, vu que vous avez besoin de jeux de tests, il y a des chances que vos tests modifient l'état de votre application. Il va falloir restaurer l'application dans son état d'origine. Il y a 10 ans, c'était compliqué à faire, objectivement, parce qu'on n'avait pas les outils pour.

20:31 De nos jours, on a tout ce qu'il faut comme technologie de conteneur et de resto de base pour être capable de remonter rapidement des environnements. Donc, utiliser, exploiter toutes ces technologies à base de conteneurs. Autre chose aussi, sur votre environnement de test de charge, comment est-ce que vous le dimensionnez? Est-ce que vous êtes capable de disposer d'un environnement de test de charge similaire à la prod, chaque fois que vous faites tourner des tests, ça a potentiellement un certain coût? Ou alors, est-ce que vous faites tourner des tests à l'échelle? Par exemple, vous faites tourner sur une infra trois fois plus petite, trois fois moins de users avec trois fois moins de jeux dans la base de données. Les conclusions de vos tests ne seront pas 100% réalistes par rapport à votre prod. Mais vous serez probablement capable de détecter quand même des régations de perf qui ne sont pas visibles en environnement de développement. Et aussi, vous aurez une baseline. Et puis, vous maintiendrez vos tests.

21:36 Et donc, à la fin, une fois que vous avez mis en place, intégré cette problématique, vous avez sensibilisé un peu tout le monde, c'est seulement à ce moment-là que vous allez vous intéresser aux outils. Vous avez besoin de deux types d'outils, des outils de monitoring, Donc, allez regarder ce qui se passe sur l'application pour être capable de diagnostiquer les problèmes et de corriger les pannes. L'idée, ce n'est pas juste de faire un test de charge, d'aller faire tomber l'application et puis de se dire, on est content, on a fait tomber l'appli. L'idée, c'est de diagnostiquer et d'améliorer. Il vous faut des outils de monitoring. Il y a plein de solutions qui existent à la fois en open source et en solution commerciale. Vous utilisez ce type d'outil pour votre prod. Donc, servez-vous aussi des tests de charge pour vous entraîner à déployer, pour vous entraîner à automatiser, pour vous entraîner à dompter la bête et vous familiariser avec le comportement de votre application en prod. Et vous familiarisez avec les outils de monitoring également. Et puis, vous allez donc avoir aussi besoin d'injecteurs de charge.

22:38 Donc, les injecteurs de charge, c'est quoi? C'est des outils, comme je vous disais en intro, qui vont vous permettre de simuler du trafic et des comportements utilisateurs sur une application. Ce ne sont pas des URL bashers. On voit des outils comme AB, notamment Apache Benchmark. Parce que ça, c'est des outils qui vont bourriner le même mur encore et encore. Si vous faites ça, vous allez tester. Vous n'avez pas testé vos applications, vous avez testé vos caches. Les caches applicatifs, le Just-In-Time Compiler, les caches de la base de données, mais votre comportement ne sera pas réaliste. Il vous faut introduire la dispersion statistique réaliste dans les URL que vous jouez, dans les jeux de tests que vous attaquez, et dans les comportements qui sont empruntés par ce qu'on appelle des utilisateurs virtuels. Ces outils, souvent, ça ne va pas être des navigateurs web. Donc, ça veut dire qu'ils ne vont pas vous exécuter votre JavaScript parce que ça consomme beaucoup de mémoire et beaucoup de CPU, même des navigateurs headless. Donc, c'est plus des outils qui vont travailler au niveau réseau, qui vont discuter avec votre serveur sur le protocole HTTP et puis envoyer des payloads et lire des payloads en réponse et essayer de simuler des comportements de navigateur web sans pour autant en être.

23:44 Quand je vous disais que ça n'exécute pas votre JavaScript, ce n'est pas dramatique parce que de plus en plus, on revient à une architecture client-serveur avec des clients qui discutent avec des API sur le côté serveur. C'est là que vous avez envie de regarder vos problèmes de perte. Vos problèmes de perte face à la charge. Parmi les injecteurs de charge, si vous cherchez des outils sur Internet, il y en a une palanquée. Forcément, chez MESplug, je vais juste vous dire en quoi consiste Gatling. Gatling, c'est un outil qui, par rapport à pas mal d'autres outils, surtout des outils un peu legacy, vous propose de rédiger les tests sous forme de code. Et c'est là où c'est très intéressant par rapport aux outils historiques qui étaient orientés vers eux. interface graphique. Quand vous avez un outil orienté interface graphique, où il faut faire du clic-bouton et sélectionner des options, des sous-menus, etc., les tests sont difficiles à maintenir. Vous ne pouvez pas collaborer sur les tests, alors que quand votre test est du code, vous stockez ça dans votre repo git, vous faites des pull requests, vous arrivez à collaborer autour des tests, vous arrivez à les maintenir, à les gérer comme vous gérez les choses,

24:53 à les gérer comme vous gérez les sources applicatives ou les sources des autres tests, vos tests unitaires, vos tests d'intégration. Selenium, Cypress, ce que vous voulez. Donc Gatling s'orientait code et puis c'est une architecture assez moderne. Donc, en résumé, quelques takeaways. Donc, les tests de charge, ça vous permet de couvrir des risques. Donc, ça vous doit voir si sur telle ou telle application, vous êtes en situation de risque ou pas. Et à ce moment-là, prendre les mesures qui s'imposent. Si vous souhaitez mettre en place des tests de charge, je vous conseille de commencer petit. Visez, si vous n'avez jamais pratiqué, donc visez d'abord une application critique, mettez en place des tests simples. Et puis petit à petit, augmenter, automatiser. Essayez de rapidement mettre en place une intégration continue qui va vous permettre de maintenir les tests et de maintenir la compétence sur les technologies. Et puis, essayez Getlink parce que c'est bien. Donc, si vous allez jeter un coup d'œil sur notre site, getlink.io, jetez un coup d'œil au tutoriel, rejoignez la mailing list Open Source.

26:00 Et puis, si à un moment, vous avez envie de franchir le pas, n'hésitez pas à nous contacter pour essayer nos offres commerciales. Voilà, voilà. Merci à tous. Et puis, je vous attends pour les questions tout à l'heure. Merci beaucoup Stéphane pour la présentation. Nous allons passer à environ 5 minutes de questions, donc n'oubliez pas de poser vos questions dans le QA. Avant de commencer la série de questions, je tiens à préciser la question de F. Schneeberg. Qui demande s'il y a un replay accessible. D'habitude, les meetups font l'objet d'un article que vous pouvez consulter sur tech.rocks. On se laisse la possibilité de voir si on met en place un replay ou pas. Alors Stéphane, il y a des questions, nous avons une question de Waiki Wong, je lis, qui demande dans le cas d'offres serverless, AWS par exemple, y a-t-il encore un intérêt à réaliser des tests de charge isolés sur les composants déployés dessus?

27:06 Alors, tes lambdas, tu vas les payer. Donc, tu as quand même envie de savoir. Déjà, quand tu vas basculer sur une architecture à base de lambda, tu as envie de savoir comment ça se comporte. Et puis, tes lambdas, tu vas les payer. Donc, peut-être que tu as envie d'optimiser certaines choses, optimiser tes lambdas pour ne pas faire exploser tes coûts d'exploitation. Au final, le lambda, enfin le serverless, c'est le serveur de quelqu'un d'autre, mais c'est quand même ton code qui va tourner dedans. D'accord. J'espère que j'ai répondu. Oui, Kiyong. Il y a un ensemble de questions qui rejoignent à peu près la même thématique. Donc, hors contexte de POC, c'est en fait comment commencer? Comment mettre en place des KPI au niveau architecture? Est-ce que tu peux nous en dire plus? Alors, première chose, comment commencer ? Quelles sont les exigences de PERF?

28:12 Observez déjà ce que vous avez sur votre prod. Rapprochez-vous des gens du métier pour avoir une idée de... Du trafic que vous prenez sur votre prod, des temps de réponse qui sont observés. Donc là, il y a des chances que ce soit les ops qui aient une visibilité là-dessus. Il y a des chances qu'il faille également rajouter peut-être des métriques métiers. Je ne sais pas si vous le faites. Les gens ne le font pas forcément. On se contente parfois juste des métriques. Les métriques OPS, genre le nombre de requêtes par seconde, le nombre de sessions créées sur le serveur, l'utilisation de la bande passante, des choses comme ça, et on n'a pas forcément de métriques métiers pour se dire, combien est-ce que j'ai d'outils rajoutés dans des paniers à chaque seconde? Combien est-ce que j'ai de paniers qui sont validés à chaque seconde? Et quelle est la taille des paniers? C'est là où il y a la partie métier des tests de charge qui intervient. Il va vous falloir une visibilité.

29:13 Il faut que vous compreniez le métier de votre application et le comportement de vos utilisateurs sur votre prod. Il va falloir vous doter d'abord de ces métriques métiers pour avoir une visibilité, comprendre ce qui se passe sur votre prod. Et puis, dans un premier temps, premier temps, peut-être juste essayer de garantir ce que vous avez sur votre prod. Que quand vous introduisez des nouveaux développements, des nouvelles features, vous ne risquez pas de dégrader déjà ce que vous avez à l'heure actuelle. Même déjà, en fait, monitorer ce que vous avez sur votre prod et de vous dire, tiens, est-ce que... Vous, en tant que développeur, est-ce qu'en front-end tech, est-ce que le pilotage de vos projets, ils savent où se situe la performance de vos applications actuellement en prod? Est-ce qu'ils savent que... On situe par exemple le 90e centile sur les temps de réponse ou est-ce qu'il n'en a aucune idée ? Par exemple, est-ce que vous n'êtes pas en train de perdre 20 ou 30% d'opportunités parce que vous avez des mauvaises pertes sur votre prod? Donc, souvent, quand on commence de rien, c'est souvent qu'on ne sait pas où on se situe.

30:17 Donc, d'abord... Vous mettre en place du monitoring sur la prod, notamment à la fois du monitoring technique et à la fois du monitoring métier, pour savoir où vous vous situez. Et ensuite, voir comment est-ce que vous pouvez améliorer les choses, est-ce qu'il y a des choses à améliorer, Et là, à ce moment-là, se donner des objectifs de les améliorer. Regardez également, étudiez ce que je vous disais, si vous avez des projections de métier, des projections de business. Si vous savez que vous avez une croissance, aujourd'hui, vous vendez tant de produits à l'heure, combien est-ce que vous vous en vendez d'ici un an ou deux? Ou même dans six mois. Et voilà, appliquez une règle de trois et regardez si vous tenez. Merci beaucoup Stéphane, merci beaucoup pour vos questions. Stéphane et toute l'équipe des speakers pourront répondre à la suite de vos questions en fin de session. Nous allons passer maintenant à Cyril Martraire, CTO d'Arolla, qui va nous parler de l'architecture à l'échelle.

31:18 Bonjour Cyril. Bonjour Ludi. Je te laisse présenter. Super. On y va, c'est parti. Tout le monde voyait bien mon écran? Donc, on y va, ça va défiler les slides, il y en a beaucoup. Donc, je suis Cyril Martraire, je bosse dans les systèmes d'information depuis pas mal de temps, en développeur d'origine, aujourd'hui cofondateur du Singe Cuivre et de Arolla. En gros, le singe cuivre, on aide les entreprises à se transformer. Et à Rola, on les aide à le faire et à le faire bien, avec 80 passionnés de test-driven development, de behavior-driven development et de domain-driven design en particulier. Alors aujourd'hui, le sujet, c'est l'architecture, l'architecture à l'échelle. Mais tout d'abord, je vais commencer juste très vite sur trois points sur l'architecture en général. L'architecture en général, il y a trois choses à garder en tête, et on va les passer vite. C'est d'avoir des buts précis. Donc de savoir, et à chaque fois qu'on parle solution, vérifier à tout moment dans une réunion que vous savez à quel problème vous vous adressez, qu'est-ce que vous cherchez à résoudre.

32:25 C'est un tout petit life hack, mais ça change tout. Donc dans les startups, il y a un petit peu moins ce problème. Dans les grosses boîtes, il y a beaucoup ce problème. Et il y a aussi vérifier que c'est le vrai problème et que ce n'est pas une solution déguisée en problème. Donc ça, c'est un petit, premier petit point. Deuxième petit point, c'est une prise de conscience qu'à chaque fois que vous amenez une solution, à un problème, en fait, vous créez des nouveaux bébés problèmes. Alors, il faut juste en être conscient. Un exemple clé, par exemple, c'est vous mettez en place un cache. Maintenant, vous avez un problème d'invalidation de cache. Qu'est-ce qui se passe quand les infos changent? Qu'est-ce qui se passe quand les infos changent? Et il y a aussi vérifier que c'est le vrai problème et que ce n'est pas une solution déguisée en problème. Donc ça, c'est un petit, premier petit point. Deuxième petit point, c'est une prise de conscience qu'à chaque fois que vous amenez une solution, à un problème, en fait, vous créez des nouveaux bébés problèmes. Alors, il faut juste en être conscient. Un exemple clé, par exemple, c'est vous mettez en place un cache. Maintenant, vous avez un problème d'invalidation de cache. Qu'est-ce qui se passe quand les infos changent? Qu'est-ce qui se passe quand les infos changent?

33:26 Et il y a aussi vérifier que c'est le vrai problème et que ce n'est pas une solution déguisée en problème. Ça, c'est un petit, premier petit point. Deuxième petit point, c'est une prise de conscience qu'à chaque fois que vous amenez une solution, à un problème, en fait, vous créez des nouveaux bébés problèmes. Alors, il faut juste en être conscient. Un exemple clé, par exemple, c'est vous mettez en place un cache. Maintenant, vous avez un problème d'invalidation de cache. Qu'est-ce qui se passe quand les infos changent? Qu'est-ce qui se passe quand les infos changent? Et il y a aussi vérifier que c'est le vrai problème et que ce n'est pas une solution déguisée en problème. Donc ça, c'est un petit, premier petit point. Deuxième petit point, c'est une prise de conscience qu'à chaque fois que vous amenez une solution, à un problème, en fait, vous créez des nouveaux bébés problèmes. Alors, il faut juste en être conscient. Un exemple clé, par exemple, c'est vous mettez en place un cache. Maintenant, vous avez un problème d'invalidation de cache. Qu'est-ce qui se passe quand les infos changent? Qu'est-ce qui se passe quand les infos changent? Et il y a aussi vérifier que c'est le vrai problème et que ce n'est pas une solution déguisée en problème.

34:30 Donc ça, c'est un petit premier petit point. Deuxième petit point, c'est une prise de conscience qu'à chaque fois que vous amenez une solution, à un problème, en fait, vous créez des nouveaux bébés problèmes. Alors, il faut juste en être conscient. Un exemple clé, par exemple, c'est vous mettez en place un cache. Maintenant, vous avez un problème d'invalidation de cache. Qu'est-ce qui se passe quand les infos changent? Qu'est-ce qui se passe quand les infos changent? Et il y a aussi vérifier que c'est le vrai problème et que ce n'est pas une solution déguisée en problème. Donc ça, c'est un petit premier petit point. Deuxième petit point, c'est une prise de conscience qu'à chaque fois que vous amenez une solution, C'est juste un exemple, mais donc il y a une sorte de fuite en avant à chaque fois qu'on déploie des solutions. Donc on se méfie et on est économe. On essaie d'être le plus économe possible sur tout ça. Le troisième point, et ça nous amène même à la définition de l'architecture en général, c'est qu'on essaie autant que possible d'avoir des décisions réversibles. Et quand on doit prendre des décisions irréversibles, comme s'engager sur un choix lourd de frein, moi, coup de technologie, on doit bien avoir conscience qu'on se ferme des portes. Et quand on veut changer tout à tout moment, ce qui est quand même le propre du logiciel, on essaie de garder des options ouvertes. Donc, on prend conscience, on essaie d'être conscient sur cet aspect de décision irréversible. Et puis, l'architecture idéale, c'est quand toutes les décisions sont réversibles, c'est qu'il n'y a plus vraiment, il n'y a plus d'enjeu, tout va bien, on maîtrise. Alors ok, tout ça c'était l'architecture en général, et si on fait attention à tout ça, la vie se passe plutôt pas trop mal. Mais qu'est-ce qui se passe quand on passe à l'échelle? Quand on passe à l'échelle, on va regarder ça avec une petite histoire. Il était une fois une entreprise, par exemple une start-up qui démarre, Early, early stage avec un big ball of everything. Tout est un. On a une équipe avec quelques personnes qui font tout. On a un gros composant qui fait tout aussi dans la technologie de votre choix. Et puis, on a tout le monde qui peut toucher à tout. Il n'y a pas de limite. Chacun fait ce qu'il veut. On est polyvalent. J'ai connu ça deux fois dans ma carrière, j'adore. Tout le monde peut toucher à tout. Et donc, ça s'évolue assez bien, finalement, puisqu'on ajoute du code. Et à chaque fois qu'il y a un nouveau besoin, on met du code en plus dans un coin. Et ça dépote. Pour aller en prod, on met tout en prod d'un gros paquet, d'un coup, on va en live, pouf, s'il y en a un, c'est facile, on peut même au début le faire à la main, mais on ne va pas le faire longtemps à la main, bien sûr, on automatise. Et l'aspect super important, le plus important, c'est surtout que comme il est un, on peut tout optimiser d'un seul tenant. On ne peut optimiser holistiquement, c'est un mot barbare, mais ça veut dire qu'on peut changer tout, partout, et même changer tout, il n'y a qu'un impact qui touche à tout. d'avoir un système d'un seul tenant. On peut optimiser global. C'est vachement important. C'est ce qui nous permet de faire des pivots, d'innover et de faire des changements radicaux. Et donc la vie est belle dans ce système d'un seul tenant. Le temps passe et au bout d'un moment, un jour, on découvre que notre système d'un seul tenant, ça ne va plus si bien. On a trop de monde et on se marche dessus. On interfère sur le travail de chacun. Si on a constaté qu'on interfère, l'alternative, c'est qu'on a mis en place des solutions, on va se coordonner pour ne pas interférer.

35:36 Mais ça, ça nous coûte aussi beaucoup, beaucoup de temps, beaucoup d'efforts. Et finalement, on finit, si on continue juste comme ça, on finit par passer son temps à se coordonner et on ne délivre pas grand-chose. On a une impression de ralentir. L'impression que tout ce qui allait vite, ça va plus vite maintenant, on devient lent. La frustration, la tristesse se développent. Et donc, la solution, vous la connaissez, c'est bien sûr de dire, on va essayer de revenir au début en découpant notre système. Donc, on prend notre truc 1, on le coupe, et puis on en fait plusieurs. De 1, on passe à 2, 3, 4, 5. On passe à plusieurs. De un composant, on passe à plusieurs composants. Et d'une équipe, on passe à plusieurs équipes. Alors remarquez, là, je les ai mises en correspondance, d'ailleurs, ce qui est un cas heureux encore. Et on passe d'un gros truc frustrant à plein de petits trucs manageables. Et donc d'une grosse frustration à... On revient au cas général. Du début, mais dans chacun des bouts. Alors, ça c'est l'histoire, c'est un peu une histoire de bisounours.

36:39 Vous savez par contre que les technologies pour faire tout ça, elles sont là, elles fonctionnent. Le pass serverless, container, les orchestrateurs, des CICD pipelines locales à chaque bout, tout ça, vous savez faire. Il est pratique qu'ils vont avec. Pareil, vous savez faire. Les faire en microservices, les architectures event-driven pour intégrer tout ça, faire que ça communique, les API par-dessus avec les gateways, les BFF pour regrouper des trucs sur des écrans, tout ça, vous savez faire. Mais reste la grosse question, la question à un milliard. Dont on ne parle pas assez en général autour de nous et dans les conférences, c'est comment on découpe, où est-ce qu'on met ses contours. Donc le reste du talk, c'est dédié à ça en fait. C'est un sujet sur lequel on intervient énormément pour tous nos clients. Et donc, c'est la question de, je les mets où les pointillés là? Je les mets où? Alors, la réponse, je vais faire un petit peu un troll, ça fait depuis 2005 que je pratique Domain Driven Design, qui en fait a amené une réponse sous la forme de la notion barbare de bander de contexte en 2003.

37:44 Et c'était bien avant que les microservices soient cool. Et donc, une grosse idée, c'est cette idée-là, c'est de découper en bouts, mais avec un truc en plus. Pour vivre heureux, vivons cachés. Ça, c'était le confinement. Malheureusement, là, on peut anticiper. Mais pour vivre heureux, surtout, on veut vivre dans des bulles. autonomie où on peut faire ce qu'on veut sans demander de compte à grand monde autour. On a un mandat et on fait, ça suffit, et on fait dans notre mandat. Le truc, c'est que si on se trompe sur les contours, ça va nous coûter très cher. Ça va nous coûter très cher quand on, par exemple, si vous mergez du code, par exemple, si vous vous trompez de contour, vous allez devoir committer ici, committer là. Et le merge va conflit, conflit. Et la même chose au runtime. Si vous décomposez en bout un peu n'importe comment, vous allez être très chati entre composants au runtime et vous aurez plein de soucis de performance, de disponibilité aussi, des canins qui sont par terre, etc. Donc, ça craint. Si vous découpez mal... Vous n'avez pas vraiment découpé, vous avez coupé des trucs en plusieurs bouts, et maintenant, ils essayent de continuer à travailler ensemble.

38:45 C'est terrible. Donc, le pire, c'est quand vous devez évoluer, modifier d'un côté, mais vous devez aussi modifier de l'autre. Et ça, à chaque fois. Et là aussi. Et là aussi, etc. Vous voyez un peu la frustration? Ça, c'est l'exemple d'un découpage raté. D'ailleurs, entre parenthèses, vous le savez a posteriori sur vos historiques de commits. Quand vous avez systématiquement des commits dans chacun des repos en même temps, des co-modifications, on les appelle, c'est que vous avez raté le découpage. Alors comment on s'y prend pour découper et comment on s'y prend aussi pour, comment on s'y prend pas pour découper? Alors la façon de découper les plus faciles et les plus évidentes, c'est celle qu'il ne faut pas faire. Vous voyez, c'est l'endroit où il y a des pointillés, ça donne envie de tirer et hop, ça vient tout seul. Ce qu'on veut vraiment faire et ce qu'il faut apprendre à faire, c'est découper sur des critères qui... Ils sont moins évidents. Il faut de l'énergie et il faut un peu de focus pour ça. Ça s'apprend. Alors comment ne pas faire? Déjà découper par ce que vous avez comme vos couches techniques. Ça c'est un très mauvais découpage, ça craint complètement. C'est facile mais c'est nul. Donc ne faites pas ça, déjà celui-là il est assez évident, ne le faites pas. Découper par technologie.

39:47 Vous avez du Mongo dans un coin, vous avez du Cassandra dans un autre, vous avez du Node avec une base Orac derrière dans un autre, vous avez des EJB, non je rigole. Découper comme ça, c'est une idée qui peut marcher par hasard. Ça donne des résultats aléatoires. Si par hasard vos technologies tombaient bien, vous avez de la chance. Si ça ne tombait pas bien, vous n'avez pas de chance. Le pire découpage possible, par contre, c'est le plus facile. C'est découpé par entité. Votre produit parle de clients, de produits, de purchases et de users. Chacun dans un composant, ça c'est le pire. C'est facile, mais ça ne marche jamais. Ça vous donnera systématiquement les pires résultats. Pourquoi? Parce que tous vos use cases au runtime, ils font toujours intervenir un client, un produit et une transaction qui les réunit, s'ils vous aident dans la distribution. Donc c'est un découpage qui a vraiment des grandes, grandes chances de toujours foirer. Alors comment on s'y prend pour de bon? On prend un peu de recul et on se pose la question de c'est quoi nos zones fonctionnelles? Des trucs comme paiement, catalogue, billing. Et puis, on prend vraiment du recul, c'est-à-dire qu'on prend un point de vue métier.

40:49 Donc, on en parle avec toutes les leaders, la C6, dans les grosses boîtes, et on se dit, c'est quoi nos différents domaines, métiers, nos zones métiers, nos zones d'expertise? Comment vous les pensez? Et on travaille à ce niveau-là, et ensuite, on décline sous la forme d'un découpage technique. Ça, c'est la grosse idée. Dans le domaine de run design, ça s'appelle DDD, ça s'appelle domain driven, ça veut dire dirigé par le domaine. Le domaine, c'est le métier. Donc si vous êtes dans la location de voitures livrées à domicile, comme lui dit, c'est ça votre domaine. Votre domaine, c'est la gestion des carciteurs, c'est la gestion des locations, la gestion des réseaux qui sont en dessous, qui fournissent les voitures. Ça, c'est ça les domaines métiers. Ça n'a rien de technique. Donc un exemple, on y commet. Il y a un exemple ici en découpage en plein de bouts. C'est un exemple archétypal, mais c'est un équin. Il ne faut pas copier-coller. Mais quand on en connaît un, ça peut aider à faire d'autres. Du coup, la question, comment identifier nos bouts de découpage? C'est ça qu'on appelle un bandit contexte, après tout. En fait, on remonte au niveau métier et c'est ça qu'on identifie.

41:51 On va chercher à identifier les sous-domaines métiers. Comment on les trouve? C'est là que Domain Driven, le bouquin, Eric Evans, en 2003, nous avait donné un énorme indice. L'énorme indice, c'est de regarder le langage. Alors, je sais, le langage, on l'écoute plutôt, mais faire attention au langage. Par exemple, si vous avez un système qui a tous ces mots-là à l'intérieur, ces mots-là, vous les avez aussi dans vos features, dans vos post-it, vous les avez partout dans vos emails. Vous avez des baskets, des items, des transactions, des agents, des anomalies, des payment events, etc. Je les ai colorés pour montrer qu'on a ici des champs lexicaux. Comme à l'école, comme en première au bac de français, vous avez des champs lexicaux. Ces champs lexicaux, c'est un des plus gros indices que vous avez pour suggérer des zones homogènes de fonctionnalités, des zones de use cases, autrement dit des sous-domaines métiers. Ici, vous auriez le shopping cart. Qui est en fait le processus de pipeline d'aller jusqu'à la conversion.

42:55 Vous avez le paiement et vous avez la détection des fraudes de paiement. Alors, L'attention au langage, c'est aussi des choses aussi simples que dire un bon domaine. Quand il est nommé avec un nom, ça devrait terminer en« ing» ou en« shen». Billing, shipping, recommendation, navigation, etc. Parce qu'on substantive des verbes. Donc ça, on pourrait détailler pendant des heures tout ça, parce qu'il y a énormément de heuristiques et d'états de l'art, mais là je vais passer juste en surface pour vous intéresser au sujet et vous donner envie de creuser. L'autre façon de décomposer, mais qui rejoint la première, c'est le découpage sur le but. Si vous prenez une même chose du vrai monde, par exemple un client, Si vous la considérez pour différents buts, alors cette chose devient différentes choses. Ça paraît très abstrait comme ça. Prenons un exemple. Votre client, vous le projetez selon votre but. Vous allez projeter différents aspects de ce client. Son adresse de livraison, est-ce qu'il est poli quand il appelle le support? Est-ce que le cycle de décision est rapide quand il s'agit de conclure la vente? En B2B, par exemple.

43:56 Et donc, par exemple, ce qu'on appellerait un livre, Quand c'est un livre dans le catalogue, il n'a rien à voir avec un livre pour livrer, pour la livraison. Pour la livraison, un livre, il n'est plus tellement livre, il est juste un machin avec des poids, des dimensions, des restrictions d'envoi dans certains pays. Pour la recommandation, un livre n'est plus du tout un livre, c'est un truc acheté en même temps que d'autres trucs. Et donc, qu'est-ce qu'on est en train de dire? On est en train de dire que c'est la même chose du vrai monde, un livre, on va la modéliser différemment dans chacun des sous-domaines, dans chacun des contextes. Et ça, c'est une idée complètement hérétique quand on a fait de l'architecture ou du développement depuis longtemps, puisqu'on cherchait l'unique. Mais donc, c'est un petit deuil à faire, on va abandonner ça. On va remodéliser plusieurs fois les mêmes choses du vrai monde pour différents buts. Et ça, entre parenthèses, ça va vous donner la liberté, la souplesse pour avoir des modèles du code plus simple dans chacun des contextes qui sont en même temps plus pertinents. Et ça vous redonne de la souplesse pour aller en sophistication, qui peut être un élément différenciateur. Puisqu'on parle de différenciateur, justement, parmi tous vos domaines métiers, ils ne sont pas tous égaux en importance stratégique pour votre entreprise.

44:58 Certains sont des sources secrètes. Alors que d'autres sont juste des choses nécessaires. Les choses secrètes et les choses nécessaires, vous ne voulez pas les mélanger. Les choses secrètes, vous voulez sans arrêt les améliorer, les optimiser, aller vite, innover. Les choses nécessaires, vous les faire au moins cher, et c'est tout. Donc on ne mélangera pas. Alors concrètement, quand on se pose la question de découper son système en tout ça, en sous-domaine, tout le monde a déjà des idées en tête. Et donc la première démarche, c'est de se poser la question, c'est d'expliciter tout ça, mettre sur la table comment les gens pensent. Quand je le fais en conseil, je le fais avec des interviews, en interviewant plein de sachants qui vont me dire comment ils pensent leur système. Et on fait une sorte de synthèse de tout ça, sous forme de petits dessins, des dessins de patates, traditionnellement. Pour qu'ils rendent compte un petit peu de tout ça et qu'ils convergent vers quelque chose de consensuel qui inclut les savoirs de chacun. Une autre pratique qui marche très bien pour ça aussi, c'est bien sûr travailler au mur avec des post-it, notamment sous la forme d'event storming. Donc c'est un truc à essayer, c'est un des takeaways, si vous voulez, de cette présentation. Le résultat, c'est donc tout un... Des cartes, ça ressemble aux bonnes vieilles cartes d'archi.

46:01 C'est juste qu'elles ont un cahier des charges quand même assez strict. C'est tout ce qu'on vient de voir avant. Comment on s'en sert de toutes ces cartes? On ne s'en sert surtout pas comme d'un truc qu'on va faire d'un coup pour être parfait et pour atteindre la cible. Surtout pas. On ne va jamais découper pour le plaisir de découper. On va se dire, voilà, c'est ce qu'on pense, que le système devrait être un jour, si on arrivait à finir, mais on sait très bien qu'on ne finira pas. Et maintenant, tous les projets transformants, à chaque fois que je vais faire un projet de Réa, écriture d'un bout, de rifacto d'un bout, de croissance d'un autre endroit. Je vais en profiter pour les réaligner sur cette carte que je me donne comme cible. Mais donc, je vais faire des bouts opportunistiquement. Je ne vais surtout pas travailler en avance. Pas de stock, on n'a pas le temps de faire du stock, on n'a pas le temps d'améliorer au cas où. On va améliorer pour un truc qu'on doit faire tout de suite. Et alors, bien sûr, votre legacy ne correspond pas à tout ce découpage parfait. Il est col... Voilà, là, ici, j'ai mis des dessins au hasard. C'est la forme d'un legacy, en général. C'est un mélange de n'importe quoi qui passe n'importe où. Et donc, on en est conscient et on vit avec.

47:03 Et puis, c'est comme ça. De toute façon, le legacy, c'est un problème de riche. On ne va pas s'en plaindre. Mais on sait que, donc, progressivement, on va essayer, quand on touche à un endroit, de réaligner. C'est tout. Donc l'idée, c'est de découper au fil de l'eau, au fil de la croissance de l'entreprise, de découper un peu comme une division cellulaire. Là, j'ai mis une blague à la con. La division cellulaire, non, ce n'est pas ça. La division cellulaire, ce n'est pas des cellules qui font une division au tableau. C'est en fait une division où à chaque fois qu'on grossit, hop, c'est le moment de se rediviser. Et puis à chaque fois que les bouts divisés ont regrossi, hop, on les redécoupe à nouveau. Et à chaque fois, etc., etc. Donc, c'est juste à temps. On découpe au moment d'en avoir besoin et surtout pas trop tôt. Ok. Et donc, une fois qu'on a découpé en plusieurs bouts, on a plusieurs avantages. On peut échapper à cet effet, un effet dont vous êtes probablement victime, qui est la tyrannie du 1. La tyrannie du 1, c'est le fait de faire un choix d'une technologie, d'une solution, d'un type de style, d'une façon de penser uniforme partout, de la même façon. Et c'est très pervers. Plus on devient sophistiqué, plus c'est pervers.

48:04 Plus ça ne marche pas. Donc un exemple de la tyrannie du one, c'est de dire j'ai une seule archi. Et je la décline partout. Non, là, on va en mettre une archi par patate. On va changer de style d'archi. La technologie de stockage, polyglotte. Par patate, on peut changer. Là, j'ai un peu exagéré quand même. Ça ne doit pas être la fête des slips. Mais on change de... Si vous êtes sur le cloud, bien sûr, vous changez aussi la... C'est la granularité. Le sous-domaine, c'est la granularité du choix du type de composant que vous prenez. Qu'est-ce qui mérite le plus de faire de la thèse de perf? Par exemple, ce sera ici. Et pas partout, pas nécessairement partout. Donc Stéphane l'a dit, pour découper, pour tester en perf de façon pertinente, avoir des sous-ensembles, ça aide à le faire. On retombe un peu dans nos contextes ici, sur la bonne unité. Votre démarche d'amélioration de l'existant? Ici, on fera une réécriture, mais seulement sur cette patate. Au-dessus, on laisse tel quel et on va extraire tantôt en service, tantôt en libre, parce qu'il y a encore des libres dans un système. Et puis, quand est-ce qu'on le fait? À différents moments. Y compris opportunistiquement. Et puis, vos API internes, elles sont aussi sur chaque bout. Donc, j'ai montré beaucoup de trucs, et je n'ai pas encore montré de petits chats, donc c'est toujours ma maman.

49:10 Donc voilà un petit chat qui est censé vous faire sourire. Vous seriez là, tous, toutes, un petit chat pour les CTO. Cadeau. Alors, après tout ça, quand imaginons qu'on a bien réussi à penser notre découpage jusqu'à un certain point, parce qu'on refera un découpage après, puis on refera après, etc., ce ne sera jamais terminé. Il reste quand même quelques points que je dois mentionner, quelques challenges qui restent. C'est les contrats, les data sharing et le déploiement unit. À chaque fois que vous avez découpé, maintenant, vous n'avez plus un, vous avez deux morceaux ou trois morceaux. Entre ces morceaux, de fait, vous avez un contrat qui est le protocole, ou vous l'appelez comme vous voulez, moi je l'appelle contrat, mais c'est une interface en Java par exemple, c'est une interface en Node, mais entre systèmes c'est une structure REST, un structure JSON, un structure Alt-Typing, si vous faites du TypeScript. auquel chacun des côtés s'engage à respecter. Donc c'est un bout de stabilité pour que chaque côté puisse changer librement, sans avoir besoin de se coordonner.

50:13 Par contre, il faut quand même se coordonner sur le contrat. Donc le contrat, il a un coût particulier, c'est le coût de cette coordination. Et malheureusement, le contrat, il est plutôt fait au début. Et donc, c'est très difficile. Il faut parier un peu. Et c'est ça la difficulté du contrat. Donc, vous en avez partout des contrats. Et un des tech-aways, ce sera d'identifier ce que vous avez. Gagnez, soyez conscient de tous les contrats que vous avez. Et vous en avez à l'intérieur de votre système beaucoup entre vous-même et vous-même. Et ces contrats, c'est ce qui vous tue votre agilité si vous ne les pensez pas proprement comme des choses à respecter à tout moment. Et donc la règle d'or des contrats, c'est vous ne les cassez pas, vous les respectez à tout prix. Ça, c'est le principe essentiel. Donc, on pourrait en parler longtemps, mais il y a des règles de l'art. Il faut être en JSON, en Avro, en Protobuf ou whatever. Il y a des façons de respecter les contrats. L'idéal, c'est de les tester aussi. Mais donc, je n'ai pas le temps d'en développer, mais c'est un point d'attention. Dès que vous découpez, vous avez des contrats entre les bouts et il faut les soigner. L'autre point, dès qu'on découpe, c'est qu'on va devoir partager des données. Et là, la règle d'or, c'est sachez qui fait autorité pour chaque bout de donnée.

51:18 L'adresse de facturation du client, qui est l'autorité de ça? Probablement le billing, mais ce n'est pas forcément certain. C'est une question à se poser chacun. De plus en plus, avec les gens à qui je travaille, on se commence. a mentionné ça sous forme de licence. Et si on explicitait la licence de chaque type de données, par exemple, interdit de redistribuer. Si je voulais passer, vous pouvez l'utiliser pour vous-même, mais pas le droit de la repasser à quelqu'un d'autre. Ce serait un exemple de règles qu'on pourrait se donner. Et comment partager les données concrètement? Tout marche, un appel gate, une vue de base de données, ou alors bien sûr du messaging, mais là il faut des règles, il est immutable, il est versionné, event-driven messaging, etc. Donc il y a plein de façons de le faire. Et puis une fois qu'on a découpé, est-ce que ça veut dire qu'il faut forcément en faire plein de services? Pas forcément. On peut en faire bien sûr des microservices pour chaque, mais on peut aussi se contenter d'un package, un module à l'intérieur d'un monolithe. Le majestique modular monolithe qui reste une façon très efficace de travailler même en 2020.

52:19 N'ayez pas honte si vous en avez un. Et donc ça m'amène à mon call to action sur lequel je vais conclure. À partir de là où vous êtes, demain, commencez à considérer si vous deviez couper, vous mettriez vos frontières où? Ici. Si ensuite, prenez conscience aussi de tous les contrats que vous avez, même implicite, même entre vous et vous, et soignez-les. Et puis posez-vous la question aussi, qui possède vraiment, qui a vraiment l'autorité pour chaque type de données? Trois questions super puissantes qui vont vraiment démultiplier votre efficacité sur une architecture à l'échelle. Un autre call to action, bien sûr, c'est d'acheter mon livre. Voilà, il est beau, il est en papier, il est lourd, il est à l'ancienne. Et il parle de documentation sans en faire, pour tous les gens qui veulent bouger vite avec un système qui évolue vite. Et puis, petite pub, sans honte, si ce sujet vous intéresse, on en fait une suite un peu plus longue qui s'appelle Découper pour mieux scaler, mardi prochain. C'est gratuit, c'est sur Eventbrite et je partagerai le lien sur mon Twitter et éventuellement ailleurs juste après.

53:25 Merci de votre attention et donc je suis ouvert pour des questions s'il nous reste un petit peu de temps. Merci beaucoup, Cyrille, pour ta présentation. On va prendre une petite question. On va laisser après Arnaud passer. Je rappelle à tout le monde qu'il y aura une session de questions-réponses avec les speakers à la fin de la dernière présentation, donc la présentation à venir. J'ai une question de Marek qui pose la question suivante. Marek, connais-tu le Volatility Base Decomposition de Juval Lowy? Qu'est-ce que tu en penses? Il y a des choses en commun avec ce que je viens de dire, mais pas complètement quand même. Alors, en commun que, bien sûr, on cherche cette volatilité, ce monsieur, il a fait une approche basée sur la volatilité. Déjà, c'est pour nous expliquer ce que c'est que le volatility-based decomposition. Alors, je ne parle du tout de son approche, mais son approche, c'est de regarder les axes de changement. Il y a juste des changements. Qu'est-ce qui a tendance à changer? Et c'est bien une question clé en découpage, c'est qu'est-ce qui a tendance à changer ensemble?

54:31 Et qui sont les donneurs d'ordre des changements? Ça, c'est ma question la plus puissante en découpage. Qui sont les donneurs d'ordre de changement? Je n'ai pas le temps de tout mettre dans cette presse, mais c'est une heuristique super puissante. Et donc, si vous avez, par exemple, un dossier d'octroi de crédit, vous pouvez autoriser ou pas des dossiers de crédit, mais la décision est basée tantôt sur des règles de risque de prêteur. Et là, le décideur, c'est le risque prudentiel. Si la décision, c'est juste de la compliance ou de l'antifraude, ce n'est pas du tout les mêmes donneurs d'ordre. En fait, ça se retrouve mélangé dans la décision. Mais ce n'est pas les mêmes donneurs d'ordre. Donc, on a bien des sous-domaines différents et je ne les mélangerai pas. Donc, ça rejoindrait de ce point de vue-là la volatilité. Ce n'est pas le même type de volatilité. Il y en a un qui est une volatilité qui vient de la réglementation, alors que d'autres, c'est une volatilité qui vient du risque de défaut. Des emprunteurs. Rien à voir. Ok, j'ai une dernière petite question pour toi. En fait, la communauté voudrait savoir si c'est toi qui avais fait la photo avec le sopalin coupé à la scie. Non, pas du tout. Non, je l'ai volé sur Internet. On trouve tout sur Internet.

55:33 Vraiment tout. Merci beaucoup encore, Cyrille. Merci à toi, Ludi. À bientôt pour les questions. À bientôt pour la question, oui. Arnaud, peux-tu monter sur scène, s'il te plaît? Oui, salut Arnaud. Donc, je te laisse la scène. Alors, à partir du moment où j'aurai lancé la presse, je ne vais plus rien voir. Donc, je ne pourrai pas répondre. Si jamais il y a des éléments dans le chat, j'essaierai de regarder ça à la fin. Et aujourd'hui, on va essayer de discuter d'un sujet qui n'est pas forcément simple, justement, puisqu'on va parler de complexité, on va parler surtout de sa relation avec la notion de localité. Alors, pour ça, après, pour me connaître un peu plus, moi, je travaille pour une entreprise qui fait de la finance de marché qui s'appelle Algeo Group. Vous pouvez me trouver sur Twitter sous atlobase. Et j'ai également un petit site internet sous l'obase.mi. Alors quand on parle de complexité et de localité, c'est lié à une problématique qui n'est malheureusement pas toujours prise en compte quand on réfléchit à ces systèmes.

56:37 C'est le fait que la complexité, ce n'est pas quelque chose qui est linéaire en termes de scale. Alors dit comme ça, ça paraît un peu barbare, mais on va essayer de l'expliciter un petit peu. En gros, ce que l'on essaye de dire, c'est que lorsque le système augmente en taille, on a tendance à penser que la complexité va avoir une relation linéaire avec cette montée en taille. C'est-à-dire que si jamais mon système double, je m'attends potentiellement que ma complexité double. Si mon système fait 10 fois sa taille, potentiellement je m'attends à avoir une complexité qui fait 10 fois la taille. Et d'ailleurs c'est aussi une problématique qu'on a souvent en perf, puisqu'en perf on a aussi tendance à penser à cette relation linéaire, alors que malheureusement ce sont des sujets où la relation a plutôt tendance à partir sur une joute. Joli exponentiel où assez rapidement, avec la taille qui augmente, la complexité devient énorme. Et pour bien se représenter ça, j'aime beaucoup prendre l'analogie suivante, c'est de parler de petites maisons. Par exemple, si jamais on imagine quelqu'un qui souhaite fabriquer une petite maison de jardin, on peut voir qu'au niveau de l'outillage et des techniques qui sont impliquées, ça n'est pas très très complexe.

57:44 C'est-à-dire que quelques planches, une scie, un marteau, des clous, et on arrive à faire un truc qui tient à peu près debout. Quand on commence à parler d'une maison individuelle, les techniques peuvent être plus ou moins similaires. Si on est en train de construire un chalet, on pourrait utiliser un outillage similaire, mais on sent déjà qu'il y a une montée en complexité assez conséquente et qu'il y a des contraintes qui ne sont plus tout à fait les mêmes. Et que si on ne fait pas gaffe, on risque de se prendre le toit sur le coin de la figure. Et si par contre on continue à monter comme ça sur la taille et qu'on arrive sur des problématiques de type gratte-ciel, mais là on voit bien que les contraintes qui se posent sur ces systèmes n'ont plus rien à voir avec celles d'une maison individuelle. Là on commence à se poser la question de comment est-ce qu'on permet à des gens de monter 40 étages, donc il faut penser à des systèmes d'ascenseur, comment est-ce qu'on fait pour amener de l'eau sous pression aussi haut, comment est-ce que l'on s'arrange pour qu'on ait potentiellement des systèmes anti-incendie, parce que quand la personne est au 40ème étage, elle ne peut pas sauter par la fenêtre du premier. Pour réussir à sortir. Et donc, il y a des contraintes structurelles qui apparaissent sur ce type de projet avec la taille.

58:49 Et pareil, ce n'est pas pour ça Rien qu'on n'a pas de gratte-ciel en bois, c'est que là aussi, tout ce qui est matériaux, tout ce qui est technique de construction n'a plus rien à voir. Et le problème qu'on a dans le logiciel, c'est qu'autant avec ce genre de projet dans le BTP, on s'en rend compte quand on a dépassé la critique parce que le système s'effondre, ce qui n'est pas souhaitable, mais c'est finalement ce qui finit par arriver quand le système grossit trop, il s'effondre sous sa propre complexité. Dans le logiciel, c'est quelque chose de très intangible. Donc malheureusement, on ne voit pas cet effondrement, on ne fait que le ressentir et on se retrouve avec des logiciels qui ont une certaine envie quotidienne de mourir parce que tout simplement, leur complexité est devenue beaucoup trop conséquente. Alors, pour contrer ce problème, et ça maintenant, il y a beaucoup d'organisations qui s'en sont rendues compte, le principe, c'est d'essayer de construire des petites maisons individuelles et des petits abris de jardin qu'on va faire collaborer entre eux. C'est d'ailleurs souvent de là qu'arrivent les éléments liés aux microservices, etc.

59:50 C'est qu'on a tendance à avoir ça comme une solution pour sortir de ces systèmes qui étaient devenus beaucoup trop gros et qui commençaient justement à souffrir de cette taille et qui commençaient à s'en sortir. s'effondrer sous leur propre complexité. Le problème que l'on a quand on commence à travailler avec ce type d'architecture, et le fait d'avoir des petites cabanes de jardin qui collaborent les unes avec les autres, c'est qu'on commence à avoir un autre effet qui apparaît. Alors là, encore une fois, juste un point, mais je ne parle absolument pas de microservices, je parle... d'unités de code, de composants, qu'elles soient déployées sur le même serveur, dans la même JVM ou sur des serveurs différents. Mais en tout cas, le gros souci que l'on a ici, c'est que ce que l'on souhaite, c'est d'éviter à tout prix de commencer à multiplier les complexités de ces systèmes entre eux et d'essayer de garder un maximum les complexités en les additionnant. On va arriver par la suite pour voir un petit peu plus concrètement ce que ça veut dire, mais ici l'idée c'est que si jamais on multiplie les complexités de ces modules au lieu de les additionner, on retombe dans le problème initial, c'est-à-dire qu'on a de nouveau une courbe de complexité qui va devenir exponentielle avec la taille du système.

1:00:54 Donc c'est un point qui malheureusement, malgré le fait qu'on prenne une approche maintenant où on essaie de construire des plus petits systèmes, si ces plus petits systèmes se contentent de se multiplier entre eux en termes de complexité, on retombe sur le problème initial et on se retrouve avec un ensemble de petits systèmes qui malheureusement font un SI qui n'est plus maintenable. Si on veut continuer un petit peu sur cette métaphore du bâtiment, pour ceux qui ont pu jouer à SimCity ou à des jeux du type, on se rend bien compte qu'avec la mise en place d'une ville, il y a des choses qui se passent entre les bâtiments. Il y a tout un réseau d'eau, un réseau d'électricité, un réseau d'eau potable qu'il va falloir commencer à construire. Et c'est là où généralement se trouve la plus grosse difficulté de ces jeux. Et ce n'est pas pour rien, parce que dans un SI, c'est aussi souvent là que va se passer pas mal de problèmes. Et pour voir ça, je vous propose de regarder rapidement une cartographie simplifiée d'un système d'information. Donc très souvent, quand on arrive sur un système d'information, le premier retour que l'on a, c'est pour un petit peu avoir une overview de ce qui va se passer, c'est des diagrammes de ce genre-là.

1:01:55 Donc là, par exemple, on se positionne sur un partenaire qui aurait une plateforme qui fait principalement du e-commerce avec une gestion en interne de tout ce qui est shipping, fulfillment et gestion des stocks et un système de paiement. Et donc très souvent, quand on arrive sur un projet, c'est un petit peu l'overview auquel on a droit. Si vous avez la chance d'avoir des diagrammes d'urbanisation, très souvent, on va avoir ce genre de truc qui va apparaître. Des diagrammes qui sont souvent en noir et blanc pour pouvoir être imprimés sur l'imprimante laser du bureau et qui très souvent ont une superbe base de données quelque part qui s'appelle Data quelque chose et qui... Est présente, on ne sait pas trop pourquoi. Mais ce qui est déjà intéressant ici, c'est qu'on commence à voir qu'il y a un peu plus de trucs qui apparaissent. Le problème de ces diagrammes, et c'est d'ailleurs pour ça que très souvent ils ne servent malheureusement à rien, c'est qu'en fait ils masquent complètement ce qui se passe en réalité. C'est-à-dire que là, on voit nos petites maisons, mais on ne voit pas ce qui se passe entre ces différents sous-systèmes. Et très souvent, c'est là où la foire à la saucisse démarre. Parce qu'une fois que vous avez construit tous ces petits systèmes,

1:03:00 Si jamais il commence, et malheureusement c'est quelque chose qui est tout à fait naturel, c'est qu'en fait chaque équipe va commencer à essayer de récupérer l'information là où elle peut, d'aller chercher ce qu'il faut, d'aller prévenir machin qu'en fait il faudrait qu'il lance tel ou tel process. Et donc c'est quelque chose qui est tout à fait organique ce genre de construction. malheureusement, ça donne des systèmes qui deviennent très très fragiles. C'est-à-dire que là, dès qu'on commence à modifier quelque chose au niveau du SI, on peut péter par effet de bord des systèmes qui n'ont rien à voir. On peut tout à fait imaginer, par exemple, que le système de recherche tombe parce qu'il y a le système de gestion des stocks qui est tombé, ce qui serait quand même particulièrement idiot. Et surtout, on ne comprend pas, souvent d'un point de vue décideur ou même utilisateur, comment c'est possible que ce genre de système tombe alors que le bug se trouve à l'autre bout du SI. Et en fait malheureusement c'est très souvent qu'on n'a pas cette vision de la réalité de tout ce qui se passe entre tous ces blocs. Et ça, on peut l'avoir à la fois au niveau d'un monolithe, parce que tous ces flèches peuvent représenter des interactions qui se passent dans un monolithe, mais on peut aussi l'avoir si jamais on a une architecture sous forme de microservices ou plusieurs unités de déploiement.

1:04:05 Là, malheureusement, le choix monolithe ou microservice ne vous apporte pas une réponse directe là-dessus. Alors la question c'est qu'est-ce qui s'est passé? Et qu'est-ce qui s'est passé, c'est une bonne question parce qu'en fait, très souvent, ça arrive en fait, si jamais on zoome un petit peu, là on va zoomer juste sur quelques collaborateurs, on se rend compte en fait que souvent c'est des problèmes d'orchestration mal agencés ou de systèmes qui sont un petit peu trop curieux. Ici, par exemple, Par exemple, on a le système qui gère les commandes, qui va à la fois aller prévenir le système de paiement que l'on a une commande à faire payer. Ensuite, on va aller chercher auprès du système d'invoicing le fait que le paiement ait bien été effectué. Et donc, il y a une facture qui a pu être générée, qui est en statut paid. Et enfin, on va aller chercher le PDF associé pour pouvoir l'envoyer au système de fulfillment afin qu'ils puissent imprimer un papier qu'ils pourront mettre dans le carton. Et là, le problème que l'on a, c'est que de cette manière, l'order management s'intéresse un petit peu trop à ce que fait le système de paiement et de facturation.

1:05:10 Donc très souvent, une des solutions que l'on voit apparaître sur ce genre de problème, c'est de changer le sens des flèches. Ça, c'est un truc qui a été et est encore malheureusement très à la mode, c'est de passer dans ce qu'on appelle les architectures réactives. Alors là, on voit juste les flèches qui ont changé, mais très souvent, ce que vous voyez apparaître dans votre système d'information, c'est un superbe bus de messages ou votre magnifique Kafka qui, en fait, n'a pas apporté grand-chose, si ce n'est de changer l'ordre des flèches, mais le couplage est toujours présent. Et en plus, c'est un couplage qui est très amusant parce que maintenant, vous avez des problèmes du genre comment est-ce que je suis sûr que mon message a bien été reçu, Qu'est-ce qui se passe si par hasard j'envoie deux fois le même message ou si le même message est traité deux fois? Qu'est-ce qui se passe si j'ai un service qui est tombé et donc j'ai des messages qui commencent à s'empiler et au moment où il revient, il se fait DOS la tête parce qu'il a 10 000 messages à traiter qui lui arrivent dessus. Et donc vous n'avez non seulement pas résolu votre problème de dépendance, mais en plus vous avez maintenant des nouveaux problèmes qui sont très très chiants à résoudre. Parce que le problème initial, en fait, ce n'était pas le sens des flèches ou le fait que ces systèmes essayent de communiquer, mais en fait, c'était le fait qu'on a le système qui gère les commandes, qui s'intéresse au détail d'implémentation de ce qui se passe dans le système de facturation.

1:06:25 Et c'est ça qu'il faut chercher à éviter. En fait, il faut éviter qu'il y ait des éléments... qui se trouvent, comme l'a dit Cyril, dans des patates différentes, qui aillent s'intéresser un petit peu trop aux détails de ce qui se passe chez les copains. Et pour ça, il faut poser des frontières beaucoup plus claires et surtout des points uniques qui vont permettre au système de collaborer les uns avec les autres. Et pour ça, on peut tout à fait soit promouvoir un système existant, par exemple ici, on peut imaginer que la brique de facturation devient la frontière par laquelle tout va passer, ou alors on peut tout à fait construire un nouveau système qui va servir d'intermédiaire. Ici, je l'ai appelé aggregator, mais il faudra bien sûr lui trouver un meilleur nom. Mais l'idée ici, c'est qu'on va pouvoir soit réutiliser un système et dire, OK, maintenant, quand vous voulez parler au système de facturation, vous appelez ce truc et vous ne vous amusez pas à appeler ses copains, soit vous appelez maintenant une façade dédiée. Et sur ces intermédiaires, on peut remarquer qu'il y a en gros trois grands types. Alors bien sûr, après, il y a plein de petites différences dans les manières de l'implémenter, etc.

1:07:26 Mais on peut en tout cas réfléchir en fonction de trois grands types d'intermédiaires. Le premier grand type d'intermédiaire, c'est ce qu'on appelle des agrégateurs de données. Les agrégateurs de données, ce sont des systèmes qui vont fournir une vision unifiée de l'état d'un sous-module logiciel. Là, par exemple, on peut tout à fait imaginer que l'agrégateur de données est capable de dire« si jamais tu as besoin de connaître l'état d'un système, tu me demandes et je te dis où est-ce qu'on en est au niveau du paiement, je peux te donner la facture et je te dis même potentiellement où se trouve le document dans l'ES. Mais ce n'est pas à toi d'aller chercher cette information, c'est moi en tant qu'intermédiaire qui te donne cette vue unifiée de l'état du sous-système que je représente. Vous pouvez avoir une sorte de vision inverse, mais plutôt surtout une vision où on va aller donner des ordres dans le sous-système. Là, avant, on demandait de l'information. Là, maintenant, on va envoyer des ordres dans le sous-système. Et ça, souvent, ça passe par ce qu'on appelle des orchestrateurs. Donc, typiquement, si vous avez un système, par exemple, qui s'occupe de gérer le full film, on récupère une commande et on met ce qu'il faut dans les cartons en sachant où les trouver dans l'entrepôt.

1:08:30 Et on met la facture dans le carton et on envoie le tout par la poste. Potentiellement, vous avez des systèmes d'orchestration où il faut aller prévenir le système de gestion de stock qu'il va y avoir du déstockage. Peut-être que si jamais les stocks commencent à ne plus être très équilibrés, il faut ordonner des déplacements dans l'entrepôt. Peut-être qu'il faut même aller faire une commande de réassort. Et donc là, vous avez potentiellement un intermédiaire qui va pouvoir s'occuper de gérer un petit peu tous ces éléments métiers. Encore une fois, ce n'est pas à l'aplan d'aller se balader dans le détail du sous-système pour dire à machin, au fait, n'oublie pas de faire ton réassort, combien il te reste, etc. On va demander au système intermédiaire de bien gérer ça pour nous. Et enfin, le troisième type, ça va être un proxy avec une façade. Donc en gros, en fait, là, c'est une sorte de passe-plat, mais un passe-plat qui ne se contente pas que de passer les plats, mais qui en plus les adapte au monde extérieur pour éviter que le monde extérieur n'ait une vision trop détaillée de ce qui se passe à l'intérieur. C'est qu'en fait, le passe-plat va permettre de masquer, d'abstraire le détail de ce qui se trouve dans le sous-système et juste de... rerouter et de transformer les messages qui vont derrière.

1:09:33 L'avantage de ces trois types d'intermédiaires, c'est tout simplement qu'ils vont permettre de garder la possibilité de faire évoluer le sous-système sans que les systèmes extérieurs qui essayent de collaborer avec n'aient de problème. Puisqu'en fait, on va juste adapter la partie qui sert d'intermédiaire et à partir de là, on aura... Pas de soucis et aucun risque de péter des trucs dans le reste du SI. Une fois qu'on a parlé de ça, il y a un point qui est quand même très important, c'est qu'il faut faire... Très attention de réellement supprimer les dépendances et non pas de les masquer. Parce qu'on voit beaucoup d'entreprises, d'organisations qui malheureusement se fourvoient un peu là-dessus et qui se retrouvent à masquer leurs dépendances et non pas à les supprimer. On en a parlé très rapidement, mais notamment, il y en a un qui est quand même souvent une des grosses causes de ce masquage des dépendances, c'est notamment les grosses bases de données centralisées. C'est qu'en fait, on a un schéma d'architecture qui ressemble à ça, donc on a l'impression que tout le monde est content parce qu'on a des flèches qui paraissent assez propres, mais malheureusement, ce qu'on se rend compte, c'est que quand on ouvre le capot, en réalité, c'est ça qui se passe avec des systèmes qui vont aller piocher dans les tables du copain pour aller voir ce qui s'y passe, aller inscrire des données quelque part en espérant qu'un autre système aille regarder dans la base de données pour lancer quelque chose.

1:10:45 Enfin, généralement, c'est assez catastrophique. Souvent, c'est ce qui a amené justement les gens à changer l'ordre des flèches, ce genre de système, et puis surtout à se dire, en fait, on n'a qu'à passer par des bus de messages centralisés. Et ça, malheureusement, actuellement, c'est là-dessus que beaucoup, beaucoup de gens se mettent des œillères parce que malheureusement, le bus de messages centralisés, il n'a rien changé. On a toujours tout le monde qui essaye de parler avec tout le monde et de faire n'importe quoi, partout, tout le temps. Et en plus, vous ne savez même plus qui potentiellement utilise vos événements. Donc, c'est encore plus rigolo parce que vous pouvez potentiellement juste faire un changement et vous vous rendez compte qu'il y avait une équipe dont vous ne soupçonniez pas l'existence qui utilisait cet événement et qui maintenant râle puisque vous venez de casser son système. Alors ensuite, on a des personnes qui se sont... On dit, si le problème, c'est d'avoir un bus, on n'a qu'à mettre plus de bus. C'est donc, en fait, on crée des bus de bus qui transmettent des messages dans des bus, qui redonnent ça à d'autres bus. Et malheureusement, c'est généralement toujours le même problème, si ce n'est pire. Puisqu'en plus, là maintenant, vous commencez à avoir de vrais problèmes, à devoir maintenir une architecture de bus qui se complexifie énormément l'opérationnel et qui devient de plus en plus fragile.

1:11:54 Tout ça pour dire que n'utilisez pas ce type de solution en espérant avoir résolu vos problèmes de dépendance, vous avez juste caché les dépendances sous le tapis. Donc ça fait très joli sur les schémas d'archi, mais malheureusement derrière ça ne va absolument rien résoudre au niveau de vos problèmes. Pour continuer, n'oubliez pas que tout ceci ne présume en rien des unités de déploiement. Cyril en a déjà parlé, je vais ré-enfoncer le clou. Ça ne veut pas dire que chacune de vos patates doit devenir un microservice. Ça ne veut pas dire que vous devez tout déployer de manière extrêmement unitaire. Vous pouvez tout à fait décider des déploiements. Mais surtout... Au moment où vous faites le déploiement, faites très attention, parce que ça, c'est quelque chose que l'on voit de plus en plus maintenant avec les superbes systèmes Kubernetes, etc., c'est que les sous-systèmes commencent à connaître les détails de déploiement des autres sous-systèmes. En fait, ils commencent carrément à connaître leur adresse dans la topologie réseau du système. Ils commencent à avoir une réelle compréhension du détail de déploiement de toute l'infrastructure.

1:12:55 Et donc là vous avez en plus un couplage qui se met au niveau de l'infrastructure. Et donc là, en termes de tentatives de refactoring ou de montée de version ou de changement, etc., ça devient catastrophique puisque vous avez carrément maintenant l'infra qui s'est retrouvée complètement bloquée parce que tout le monde sait où se trouve tout le monde. Et donc, dès qu'on essaye de changer l'endroit où trouver quelqu'un ou qu'on se dit, finalement, ces deux-là, on pourrait les mettre ensemble. Au contraire, on va les mettre chacun de leur côté. Vous avez potentiellement des applicatifs qui cassent en cascade. Et c'est absolument affreux. Donc ici, c'est typiquement là où vous allez avoir des solutions en base de proxy. C'est qu'en fait, vous fournissez des reverse proxy qui, à certains points dans l'infra, vont être capables, eux, de rerouter précisément vers les sous-systèmes et non pas d'ouvrir toutes les routes réseau à tout le monde, tout le temps, n'importe comment. Pour conclure là-dessus, en gros, très souvent, ce que l'on voit, c'est que les organisations ont tendance à comprendre qu'elles ne doivent plus faire un énorme truc.

1:13:57 Donc, on commence à avoir du découpage, mais malheureusement, ce découpage ressemble souvent à ça. Et en fait, ça, c'est la version avec les flèches un peu masquées du schéma que je vous ai montré au début, parce qu'en fait, en réalité, quand on a ce genre d'architecture, en vrai, c'est ça qui se cache derrière. C'est qu'en fait, tout le monde communique avec tout le monde. Là où en réalité il vaudrait mieux avoir effectivement des systèmes qui se protègent, qui fournissent des systèmes, qui fournissent donc des visions des sous-systèmes qu'ils peuvent communiquer au niveau supérieur du SI. Ça n'interdit pas d'avoir des bus de messages, ça n'interdit pas d'avoir des bases de données, mais ça reste dans les différents sous-éléments. Et quand vous avez des bus plus généraux qui apparaissent, ils reçoivent des messages qui sont déjà transformés et ce n'est pas directement le détail des applicatifs qui s'y connectent. Et bien sûr, ça c'est quand on a deux niveaux, mais on peut tout à fait rajouter un troisième niveau. Vous pouvez tout à fait, après avoir de grandes aires applicatives dans votre récit, et donc pareil, ces aires, vous les protégez en mettant à nouveau des systèmes de traduction.

1:15:00 des intermédiaires qui vont se charger de ne pas révéler au reste du système d'information le détail d'implémentation de ces sous-systèmes. Si on reprend, on a très souvent des sous-systèmes au niveau applicatif qui sont chargés de réaliser une fonction ou un ensemble de fonctions qui est assez groupé. On a ensuite souvent un grand domaine métier, par exemple le domaine de la vente en ligne. Et ensuite, vous avez le reste du système d'information. Vous pouvez avoir les systèmes Cyrille et ce genre de choses qui vont apparaître. Et il faut faire très attention de bien hiérarchiser ces différentes informations les unes par rapport aux autres. Moi, je vais m'arrêter là. Merci beaucoup. Ce QR code vous renvoie vers un petit questionnaire. Vous pouvez répondre de manière anonyme pour me donner vos feedbacks sur la conférence. C'était une première, celle-ci, pour moi. Merci encore. Et maintenant, normalement, nous devrions avoir quelques minutes pour des questions. Merci beaucoup Arnaud pour cette présentation. En effet, nous avons quelques questions. Donc la première question d'Antime, en se basant sur la philosophie des DD, dans quel bandit contexte se situe l'orchestrateur?

1:16:08 Alors l'orchestrateur, il se situe à la frontière du bandit contexte qu'il est censé orchestrer. Donc, il se trouve toujours colocalisé avec les systèmes qu'il orchestre. L'erreur, c'est de poser l'orchestrateur à l'extérieur du bandit contexte dans lequel se trouvent les éléments qu'il s'apprête à orchestrer. Et donc, de cette manière, d'avoir un orchestrateur qui va aller chercher du détail dans les autres bandits contextes, justement pour réussir. à orchestrer son métier. Donc, il se trouve avec les éléments qu'il orchestre et il se trouve à la frontière, généralement. D'accord. Il y a une autre question de Nicolas, qui pose la question à Nicolas Tricot. Est-ce que mettre en place ces trois types d'intermédiaires ne génère pas de single point of failure dans ce type d'architecture? Alors, en fait... Déjà, il faut bien voir que ces intermédiaires ne sont pas mécaniquement des intermédiaires qui sont déployés de manière unitaire. Ça peut tout à fait coexister avec d'autres éléments de l'applicatif, mais c'est simplement qu'on commence à être très clair sur à quel endroit on attaque un sous-système. Après, cet intermédiaire peut être déployé avec le reste du sous-système. Il va être géré de la même manière que le reste, et si le sous-système tombe, lui tombera avec, mais de toute manière, si on ne l'avait pas, ça n'aurait quand même pas marché.

1:17:16 Il y a quand même un avantage, c'est que très souvent, quand on a des services qui se parlent dans tous les sens, on a justement beaucoup de mal à retracer des potentiels problèmes, des potentielles erreurs. Et ces intermédiaires peuvent justement permettre aussi de gérer ce genre de cas. Ils sont capables potentiellement de dire, attends, là on a un système qui est parti en RAD, donc on va arrêter de l'appeler, on va aller prévenir les applicatifs qui sont à l'intérieur que malheureusement on va être en version dégradée. Donc au contraire, ils peuvent faire partie d'une politique pour justement minimiser et diminuer ce risque de spoof. Après, bien sûr, si jamais il y a des risques de spoof, ça veut dire que c'est intermédiaire, il faut leur mettre ce qu'il faut pour qu'ils ne soient pas des spoof. Donc ça veut dire que potentiellement, il faut qu'ils soient déployés effectivement sous forme de plusieurs instances. Nous, en fin de compte, Effectivement, on travaille beaucoup sur ces questions, puisqu'on n'a pas le droit d'être down. Si on est down plus de quelques... Nous, c'est en millisecondes que ça se compte, avant que les clients commencent à râler. Et donc mécaniquement, nous par exemple, on a systématiquement trois systèmes qui sont en train de tourner en temps réel et on est capable de faire des basculements à chaud entre ces différents systèmes.

1:18:19 Donc après, c'est juste à vous de vous adapter. Mais ces éléments-là peuvent encore une fois être déployés avec le reste du sous-système. C'est souvent ce qui se passe. Simplement, on indique que maintenant, c'est une porte d'entrée logique. Et derrière, c'est une gestion classique de quand on a des problèmes, effectivement. C'est d'avoir plusieurs instances qui tournent en même temps. Et au contraire, ça donne en plus des petits éléments logiques où on va pouvoir avoir une gestion. De ce qui peut se passer avec le reste du SI et donc de pouvoir plus facilement gérer des cas où le reste du SI commence à avoir des soucis de son côté. J'ai une question, justement, quand je regarde ta présentation. N'est-ce pas délocaliser la complexité encore dans les systèmes tiers? En fait, c'est une bonne question, mais la problématique, en fait, c'est pas tant de... Il s'est masqué la bonne complexité, en fait. C'est réussir à apporter une abstraction qui permet réellement de venir apporter le niveau de détail attendu, c'est-à-dire pas un niveau de détail trop fort, parce que là, on va rentrer dans des problèmes de couplage entre les systèmes. Bien sûr, après, l'objectif, ce n'est pas non plus de s'amuser à créer des abstractions pour créer des abstractions.

1:19:22 Il faut créer des abstractions qui ont du sens. Après, on revient par contre plus sur les problématiques qu'avait abordées Cyrille. Ça, ça passe par un bon découpage et de savoir effectivement quels sont effectivement quels sont les grands sous-systèmes, quels sont les contrats que l'on va avoir entre ces sous-systèmes, Il n'y a pas mécaniquement que un intermédiaire pour chaque système, il peut y en avoir plusieurs. Mais voilà, à chaque fois, c'est d'être bien au carré sur quels sont les contrats que l'on a, quels sont les points d'entrée et de ne pas laisser tout le monde parler à tout le monde dans tout le SI. Parce que là, par contre, vous avez... Un problème, c'est que votre récit est devenu ce qu'on appelle un monolithe distribué. c'est qu'en fait, dès qu'on touche à un truc d'un côté, on a des machins qui pètent en cascade de partout. Et ça, pour avoir déjà... intervenu dans ce genre de contexte, c'est vraiment, vraiment pas amusant. Je te remercie beaucoup Arnaud. Je vous rappelle Stéphane et Cyril pour nous rejoindre sur scène pour la session de QA finale. Je vais reprendre la question auxquelles on n'a pas répondu plus tôt.

1:20:24 Chérie, tu avais des questions? Et bien sûr, d'autres questions. Vous pouvez continuer à vous poser des questions. Aujourd'hui, vous avez les trois speakers qui peuvent répondre à des questions croisées sur chaque domaine, justement. Question de Damien Leroux. Damien posait la question de comment éviter que la perte devienne un enjeu. Pour revenir sur ta présentation, on s'y va. La perf, elle est un enjeu, ça dépend de ton métier, de ton business. Si tu fais un site d'e-commerce qui a vocation à être à fort trafic, la perte c'est forcément un enjeu si tu fais une application qui traite des flux financiers si tu fais une application qui est dans la tech la performance c'est un enjeu si tu fais une application qui doit faire du data mining la perte c'est un enjeu si tu fais juste une application de gestion

1:21:30 qui a 2-3 utilisateurs et qui est utilisé de temps en temps et qui a un trafic qui est très stable et très visible, la perte n'est pas forcément un enjeu. Si tu fais une application de gestion de caisse de retraite, à moins que le Covid fasse exploser le nombre de décès, ton trafic va être stable. Les enjeux de performance sont liés à ton business. J'aurais tendance à dire que quand on a des problèmes de perf, on le sait. Parce qu'en fait, on se trouve dans un domaine métier où les mecs sont obsédés par la perf. En finance, on ne se pose pas la question. Les mecs ne se disent pas où ce serait bien qu'on attende deux jours pour réussir à avoir notre prêt d'exécuté. Non, les mecs te disent, si en 4 millisecondes, on n'a pas la réponse, allez vous faire foutre. Oui. Alors après, c'est aussi contextualisé. C'est ce que j'expliquais sur le MVP. La perte peut ne pas être un enjeu à un moment et puis le devenir après. Ça dépend aussi de ton niveau de maturité, de ton marché.

1:22:35 Si tu es juste en train de construire ton truc et de décoller, ta solution, elle peut tenir la route à ce jour, mais elle peut ne plus tenir la route par rapport à ce qui va se passer, aussi bien simplement avec ta croissance prévisible espérée de ton business ou même simplement tout à coup, ça y est, tu décolles ou c'est un truc même temporaire, tu te prends un buzz et là, tu loupes le coche. le... Voilà. Justement, si je cherche le traducteur dans la présentation, comment cette réflexion du découpage, de la complexité, de la performance se rejoignent? J'ai bien aimé ce qu'Arnaud a dit. Si vous avez une architecture qui est complexe, il y a des chances que les enjeux de perte ne soient pas forcément les mêmes sur vos différentes briques. Justement, ça peut vous permettre d'isoler les composants qui sont vraiment sollicités et critiques, sur lesquels il y a des enjeux de perf, d'autres composants qui sont moins sollicités et moins critiques.

1:23:43 Moi, tu viens de répondre à la question, quel impact du DDD sur la scalabilité et les paires? Désolé. On va faire monter Kevin sur scène. Kevin, tu as une question? Kevin, tu nous rejoins? Bonjour, merci pour les présentations. J'ai une question principalement pour Arnaud et puis pour Cyrille. C'est intéressant de découper son système de cette façon-là. En effet, on vient réduire la complexité technique, mais inversement, proportionnellement, on... On augmente la complexité de monter en compétence de nouveaux développeurs. Je l'ai vécu par exemple avec un développeur que j'ai fait venir dans ma boîte, avec un système découpé de cette façon-là. Comprendre l'ensemble du système avec la big picture, ça devient plus difficile. Et plus difficile de l'onboarder dans le système. Quels seraient vos tips pour réussir à contrebalancer un peu ça?

1:24:47 En fait, comment tu voulais commencer, Cyrille? En fait, oui, je pense qu'on a compris. L'idée, c'est que, moi, j'ai mis en évidence les petits bonhommes dans les patates. Parce que l'idée, c'est bien de découper aussi des équipes. Donc, les équipes ne devraient pas avoir à tout savoir. L'élément principal de la réponse, c'est que toute l'idée, c'est de faire en sorte que chacun n'ait pas besoin de tout savoir. Pour rebondir, il y a quelque chose qu'on appelle souvent la charge cognitive d'équipe, qui reprend bien ça en fait, c'est de dire qu'à partir du moment où dans une équipe, les développeurs commencent à avoir besoin de connaître trop de choses, c'est que sans doute, il y a justement trop de trucs qui commencent à s'accumuler à un endroit et qu'il est temps de faire un split et de redéfinir des frontières. Au contraire, justement, d'avoir cette complexification que l'on pourrait voir, j'ai tendance à trouver que moi, au contraire, ça simplifie beaucoup de choses, parce que normalement, on a des interfaces qui sont plus simples, on a des sous-systèmes qui sont plus simples. Réussir à faire comprendre à un développeur qui vient d'arriver pourquoi est-ce qu'en fait, dans ce cas-là, il faut qu'il attende tant d'acknowledgement avant de lancer un autre message, parce qu'en fait, il y a machin à l'autre bout qui attend un truc et qui va en fait retourner un type de message, c'est catastrophique à apprendre.

1:25:56 Alors bien sûr... On ne le voit pas immédiatement, et ça s'apprend souvent de la douleur, mais j'ai tendance à penser que ce type d'approche montre plus les problèmes qu'on en avait, ça les révèle plus qu'en réalité ça en crée de nouveau. En fait, c'est même une des motivations, c'est d'encapsuler. Et à la fin de ta presse, Arnaud, quand on voit des sous-zones qui elles-mêmes cachent tout ce qui est derrière, on retrouve encore cette volonté que tout le monde n'ait pas besoin de savoir ce qu'ils consomment, n'ont pas besoin de savoir comment c'est fait dedans, ils ont besoin d'être experts de leur zone à eux. Arrêtez de tout brancher dans votre CRM, c'est catastrophique et ça coupe tout le SI, je n'en peux plus. Voilà, c'est un message personnel. On ne t'entend pas? Et cela pose la question du contrat des services. Donc, ce contrat, on l'écrit comment? Et surtout, on le maintient comment, en fait, au fur et à mesure?

1:26:57 Bien sûr, de la complexité du système, parce qu'à un moment donné, les sous-systèmes, même si ce sont des découpés, augmentent en complexité. Alors, les contrats, bien sûr, c'est un point d'attention. Il y a des pratiques, par exemple, pour améliorer les contrats d'emblée, c'est de demander aux gens, c'est d'avoir accès, si on a accès aux ceux qui s'en servent, aux consommateurs, même si c'est des collègues, ou si c'est des clients, c'est plus dur, mais de quoi vous avez besoin? Donc, d'aller chercher du factuel plutôt que de parier. Donc, Consumer Driven Contract, c'était ça l'idée. Ce n'était pas de faire des mocks, des services virtuels ou des trucs qui nous testent. C'était bien une démarche d'aller chercher des besoins. Ensuite, quand même, l'autre approche, c'est que si on a complètement foiré, on recommence et on fait une V2. Et la V2 s'ajoute à côté et ça revient à recommencer, parce que le versionning n'a jamais rien résolu. Ça permet de savoir qu'il y a un problème et ça ne résout rien. Donc ça, sur les contrats. Après, on peut les rendre rétrocompatibles. Si on a du legacy, on va mieux réussir les contrats puisqu'on a de l'historique sur lequel on peut regarder pour voir comment ça a marché jusqu'à présent et s'en inspirer.

1:28:00 Et donc, moins parier. D'accord. J'ai une question pour toi, Cyril, de Sacha Moura. As-tu rencontré des entreprises qui ont tout découpé et qui ont fini par obtenir l'ensemble de trucs pas maintenables? Si oui, comment auraient-elles pu l'éviter? Alors, moi, non. Mais il y a un biais, évidemment. Je rencontre des entreprises qui ont compris que DDD était un élément de réponse et qui font appel à moi avant d'arriver là. De témoignages indirects, oui, j'en ai entendu parler. C'est vrai que c'est tout. Et puis récemment, il y a aussi l'article très visible sur« On revient de microservices à l'extrême». Oui, si on découpe trop et si en plus on a découpé par entité, là on doit regretter assez fort. Clairement. Donc oui, ne faites pas ça. Et donc, j'ai bien insisté dessus, c'est ne découpez pas pour le plaisir de découper. Découpez quand votre équipe est devenue trop grosse, quand vous êtes 15 à maintenir un composant, c'est que c'est le moment de découper en 2 x 7 ou en 3 x 5. Là, je n'avais absolument pas le temps, mais l'architecture technique est indissociable de l'architecture socio-technique.

1:29:03 Et donc, des questions de qui travaille dessus. Et donc, une motivation pour découper, c'est bien de pouvoir faire en sorte que chacun, dans chaque groupe, puisse se spécialiser quand même un peu sur cette partie-là. Et en n'ayant pas besoin de connaître les autres parties. Si on garde ça à l'esprit, on ne peut pas faire d'énormes... Je pense que c'est une question que vous vous trouvez de Marek, qui pose la question, est-ce qu'il n'y a pas des moments où faire du DDD est un trade-off qui impacte les perfs ? Stéphane? Non, je ne pense pas. Alors, là où ça peut faire peur, en fait, c'est plus… Par exemple, s'il faut commencer à renoncer à des transactions, si on se retrouve à découper des choses où avant on avait une sorte de base de données monolithique et 100% transactionnel, où là, on se retrouve à isoler les domaines parce que c'est devenu trop gros, mais on n'est plus capable de faire des transactions distribuées.

1:30:09 Et donc, on se retrouve à introduire des notions d'acknowledgement et d'orchestration. Il y a forcément, à ce moment-là, dans un sens, on va dégrader les perfs, mais sauf que c'est pour répondre à un problème qui est que l'application était plus tenable comme ça. Et là, l'impact est assez violent. Surtout si on venait du legacy, on raisonnait uniquement en transactionnel et là il va falloir raisonner différemment en termes de consistency à terme et de renoncer aux transactions. Et il faut être capable quand on va splitter ce genre de monolithes. Globalement transactionnel et le splitter en sous-ensemble, il va falloir renoncer à ces transactions et repenser le fonctionnement des différents sous-éléments. On ne peut pas juste splitter un ensemble transactionnel en différents sous-éléments. Il faut considérer toute l'orchestration.

1:31:11 Moi, j'ai vu parfois des horreurs avec une application comme ça, un monolithe splitté en plusieurs, et avoir des problèmes d'orchestration pour essayer de retrouver, pas vraiment mettre en place d'orchestration, et donc mettre en place des slips dans le système A, parce qu'il fallait que lui dispatchait des heures dans le système B, Mais le système A plan, il appelait aussi le système B, donc il fallait absolument que ce que faisait le système A, ça passe avant ou ça passe après. Et c'était, voilà, forcément, tiens, on met un slip de 100 millisecondes, tiens, ça peut être en prod, on va le passer à 200 millisecondes, ça passe toujours, on a toujours 1% d'erreur, on va le passer à une seconde, parce que c'est, voilà, c'était démentiel. C'est plus des... Donc oui, il y a des impacts sur les perfs, et puis il y a des gros impacts sur l'architecture, notamment, je pense, sur la gestion des transactions. Mais l'objectif, c'est de gagner quelque chose derrière, c'est d'améliorer une situation qui était plus tenable. Oui, en fait, l'architecture est un ensemble de trade-offs, en fait, par rapport aux requirements.

1:32:18 J'ai une dernière question pour nous, mais je pense aussi pour Cyril aussi, parce qu'on est vraiment sur les sujets de découpage, de Didier, Didier Schoen. Les busts de messages sont toujours une erreur qui vont cacher les choses ou c'est juste à bien utiliser. C'est bien utiliser les bons outils pour le bon usage. C'est toujours le contexte, le contexte, le contexte, le contexte. C'est juste, ça n'est pas une solution magique. En architecture, et même de manière générale dans le développement, on a beaucoup, beaucoup une tendance à faire ce qu'on appelle des full pendulum effects. C'est qu'en fait, on est dans une situation A, et en fait, vu qu'on a des problèmes, on va à l'inverse opposé, dans une situation B, et ça donne... Des catastrophes aussi, parce qu'en fait, la bonne réponse ne se trouve jamais dans les extrêmes en termes de solutions. C'est des boîtes qui passent d'un énorme monolithe absolument immonde à un truc où ils vont déployer un microservice par requête HTTP. C'est complètement con dans les deux cas, malheureusement pour eux. Et la bonne réponse se trouve quelque part entre ces deux extrêmes.

1:33:20 Et malheureusement, les solutions, c'est toujours ça. Il n'y a jamais de bien ou de mal. Il y a des moments où c'est mieux et des moments où c'est moins bien. Et là, il faut juste faire... Sinon, on n'en parlerait pas. En fait, ce qui est trop facile, on n'en parle même pas. Donc, je prends une dernière question, mais vraiment une dernière question, en fait, c'est de Benjamin, en fait, est-ce que vous avez des recommandations pour maîtriser sur la durée DDD en dehors des boulots et real books? C'est assez problématique pour ça parce que c'est beaucoup d'heuristique, c'est beaucoup d'expérience sur des métiers très différents. C'est beaucoup de contexte d'entreprise, de métier, des contraintes. Et donc, c'est très difficile de réussir à... À apprendre DDD en dehors de coder et de concevoir des systèmes. Bien sûr, il y a plein de livres, il y a des vidéos, il y a énormément de choses qui sont proposées, mais rien ne remplace l'expérience.

1:34:20 Et c'est notamment un problème très souvent qu'on a sur certaines personnes qui parlent de DDD, alors qu'en fait, on se rend compte que l'expérience n'est pas forcément multiple. Et donc, ça donne des angles qui sont uniques. Et donc malheureusement, il n'y a pas de solution magique. Il ne s'agit pas non plus de dire que c'est incroyablement difficile, etc. J'ai plein de collègues, confrères, clients qui apprennent vite, qui ont des bons réflexes, qui ont des... Par exemple, dans le chat, certains ont parlé de programmation objet. Le fonctionnel ne s'oppose pas à l'objet, les deux sont bien. Avoir un background en objet, ça aide quand même bien à penser. C'est la grande échelle quand même, très fort. La localité, l'encapsulation, la cohésion, on se retrouve, c'est les mêmes idées dans tout ce qu'on vient de présenter. Il faut vraiment prendre mon discours comme c'est compliqué, attention. Mais en fait, c'est juste un changement de philosophie. On garde les mêmes langages, on garde les mêmes outils, sauf qu'au lieu d'essayer d'adapter le métier à l'outillage qu'on a, en gros, j'ai un framework, j'essaie de faire rentrer mon métier aux choses pieds dedans.

1:35:28 Je ne sais pas trop où ça se met ça, mais bon, peut-être que ça rentre dans tel package du framework. En fait, on va juste se poser la question inverse, c'est de dire quel est mon métier et à partir de là, quels sont les outils techniques que j'ai à ma disposition pour réussir à l'exprimer. Donc en tant que tel, rien de compliqué, on ne change rien, on change juste la façon de poser le problème. Merci beaucoup à tous. Thierry, Stéphane, Arnaud, ce sera le mot de la fin. Pratiquer, pratiquer, l'architecture se pratique. Je vais redonner la main à Noémie avant de commencer la session de networking. Oui, tout à fait. Alors déjà, merci à toutes. Bravo Ludi parce que c'était un exercice pas évident, c'était la première fois que Ludi animait un Meetup Tech.Rocks et elle l'a très bien réussi. Alors moi je vous partage une conclusion, ça va prendre deux minutes, c'est juste pour vous rappeler. Par la suite, juste après, vous pouvez échanger au sein de tables virtuelles. Les tables sont limitées à six personnes.

1:36:29 Et quand vous êtes sur une table, n'hésitez pas à enclencher votre caméra, votre micro. C'est plus sympa pour les participants et forcément pour discuter. Vous pouvez nous donner vos avis, votre avis sur les meetups. On les prend avec plaisir et on adapte aussi évidemment notre programme en fonction de vous. Pour rappel, la semaine prochaine, on se retrouve autour des enjeux de la relation CTO-CPO avec un super programme. Merci à toutes et à tous. Merci aux speakers. Et on se retrouve la semaine prochaine. Bonne soirée. Bonne soirée à tous.