[0:00]Salut à toi et bienvenue sur le podcast Aopen, le podcast qui parle développement et nouvelles technologies, le tout réalisé par une bande de Tecos. Allez, c'est parti.
[0:18]Salut à tous et bienvenue dans le 39e épisode du podcast d'Open. Aujourd'hui, on se retrouve pour décortiquer l'un des sujets favoris de Philippe, c'est la scalabilité des applications. On va bien évidemment ici parler de performance, architecture, haute disponibilité et vous partager nos retours d'expérience et les bonnes pratiques sur cette thématique. Du coup, la team du jour, j'ai mes fidèles acolytes, il y a donc Philippe. Bienvenue. Et il y a Arthur. Bonjour bonjour. Voilà, on a en comité reste aujourd'hui pour Bon on savait que Philippe de toute façon, elle allait monopoliser toute la parole pour parler de son sujet. Donc on s'est dit ça sert à rien de d'inviter trop de monde quoi. Donc du coup bah Philippe, je vais te poser des questions à Arthur moi. On a Arthur aujourd'hui. Du coup, Philippe, je vais te laisser commencer par bah parler des bases comme d'habitude. La scalabilité des applications, tu peux nous donner une définition générale du terme. Alors, je vais essayer de donner une définition qui soit compréhensible par tout le monde. Alors, pour ceux qui sont pas fans des anglicismes, la scalabilité, on pourrait au plus proche la traduire par la capacité d'une application à être mise à l'échelle. Qu'est-ce que ça veut dire par là ? C'est quand on va parler de scalabilité, on va parler de tous les sujets qui permettent de faire en sorte que votre application globalement, elle réponde vite et dans toutes les situations. C'est un sujet qui peut paraître évident à à notre époque parce qu'on a des applications sur lequel on est habitué à ce que ça évite les Facebook, les les Instagram, toutes les Amazon, tout ça, ça va hyper vite. Mais en fait, c'est un sujet extraordinairement complexe de rendre disponible rapidement une application à large échelle dans le monde, n'importe où où vous soyez et quel que soit votre périphérique. Donc la scalabilité, c'est toutes les technologies, tout ce qu'on va pouvoir mettre derrière pour faire en sorte que quand vous cliquez, ça réponde hyper vite et dans toutes les situations. Et aussi que ce soit optimisé au niveau qualité, enfin au niveau prix aussi parce qu'on peut toujours se dire qu'on met une blinde de serveurs, mais la nuit bah personne est dessus donc vous payez pour rien. La journée en août, il y a personne donc vous payez pour rien et c'est aussi voilà, trouver le juste équilibre entre trouver les moments où il y a besoin de puissance, les moments où il y en a un peu moins besoin et équilibré entre la taille de votre infrastructure et les besoins aussi. Parce que la scalabilité du coup, il y a plusieurs notions qui sont un peu associées type, bah, tu parlais de performance. Oui, alors en fait la scalabilité, c'est un terme vague qui veut tout ou rien dire et la performance c'est encore pire. Parce que qu'est-ce que qu'est-ce qu'on qu'est-ce qu'on considère comme une application de performance c'est ça c'est un peu personne dépendante quoi. Euh, mais de manière générale, vraiment, c'est vraiment être capable de ou si on donnait une une définition la plus générique possible et qui peut tout le monde, c'est que globalement, avec des mots utilisateurs, c'est que l'ap soit vite dans n'importe quel contexte. Et disponible. Voilà. OK et du coup la disponibilité enfin parce qu'on parle beaucoup aujourd'hui de disponibilité haute disponibilité, c'est c'est quoi euh Alors, en fait, une ce qu'on va ce qu'on va parler de haute disponibilité, généralement on parle de 3 9 ou 4 9 ou 5 9. Pour démystifier ça, c'est le pourcentage de disponibilité de l'application sur une année. D'accord, donc on va par de base, on va dire 99 % du temps. D'accord, ça veut dire que pendant 1 % du temps, l'application sera pas disponible. Mais en fait, quand une application est disponible 99 % du temps, ça veut dire que il y a 1 % du temps où elle l'est pas et en fait sur une année où il y a plus de 300 jours, ça veut dire qu'en 4 jours, elle n'est pas disponible. Donc ça veut dire que 99 %, c'est pas une ce qu'on appelle une haute disponibilité, c'est une bonne disponibilité mais c'est pas haut. C'est généralement la disponibilité qu'on qu'on a pour les applications métiers internes, on s'autorise quelques jours d'arrêt de l'application dans l'année pour faire de la maintenance des mises à jour et compagnie. Quand on va parler de 2 9, 3 9, 4 9, c'est le nombre de 9 après la virgule, donc elle est disponible 99,9 % du temps, 99,99, 99,999, ainsi de suite. D'accord et plus on avance dans le nombre de 9, plus c'est très compliqué à faire et plus c'est c'est comme disait Arthur, c'est horriblement cher parce que du coup, ça nous met un nombre de contraintes de dingue. Ne serait-ce que mettre une mise à jour d'application sur un contexte d'application triple 9 ou 4 9, c'est vraiment euh ça devient un peu sport quoi. Et puis c'est c'est de plus en plus enfin, plus tu auras le de neuf plus c'est c'est au final, ça réduit de pas beaucoup parce qu'au final je crois que 4 9 c'est genre quelques heures et 5 9 c'est quelques minutes. Mais au final bon, après ça tout dépend, on peut parler de si c'est quelques minutes dans dans la nuit, on s'en fout, mais si par exemple on met je sais pas en plein mois de en plein Black Friday pour un Amazon et que les 2 heures elles se trouvent à ce moment-là, c'est pire. Un peu compliqué. Ouais là c'est plus problématique effectivement. Ah j'allais dire, ça dépend finalement des euh, enfin, on reviendra plus tard sur sur quelles applications on se pose plus ou moins la question et et quelle quel métier, mais effectivement, euh ouais, sur un Black Friday ou le premier jour des soldes, c'est compliqué de se dire, mon bah ce jour-là, ce sera le jour d'un disponible, donc à l'année. Ce sera dans 4 jours. Non ça a des impacts réels. Moi j'avais un client récemment qui qui est passé à la télévision sur lequel ça fait un un entre guillemets un mini buzz et qui il a eu un pic de charge monstrueux. L'application s'est effondrée. Bah c'est des 20 en moins quoi. Parce que c'était pas la charge habituelle quoi. La réputation aussi les gens ils vont voir, ils voient que c'est down bah ils reviennent plus quoi. Ouais, réputation, chiffre d'affaire, enfin, plus la panique générée derrière. Que du bonheur. Scalabilité, on entend souvent scalabilité horizontale et scalabilité verticale. C'est c'est quoi la différence entre entre les deux. Alors, euh, c'est assez simple, globalement la scalabilité verticale, c'est l'approche qu'on a tous nativement, c'est-à-dire grosso modo, ça va pas très vite, il y a pas ça tient pas la charge, je vais accélérer la puissance de la machine. En gros, c'est ça, c'est-à-dire que c'est c'est exactement le réflexe du particulier qui travaille sur son ordinateur, il trouve que Word ça commence à ramer, il va acheter un nouvel ordinateur à Fnac, il va plus vite, le processeur est plus performant, ça va un peu plus vite. Ça c'est ce qu'on va appeler la scalabilité verticale, c'est-à-dire j'augmente la capacité unitaire d'une machine d'un d'un CPU, d'un téléphone, ce que vous voulez. Ça c'est la verticale. L'horizontal, c'est une approche inverse, c'est-à-dire en fait, on va pas augmenter la puissance unitaire du périphérique, mais on va multiplier horizontalement, c'est-à-dire on va rajouter des machines. Dans le cas d'une partie d'un particulier qui utilise Word, ça marche pas parce qu'on peut pas utiliser Word sur deux machines, mais dans le cas de serveurs, on peut tout à fait répartir la charge sur un ensemble de serveurs. Donc la scalabilité horizontale, c'est la multiplication des ressources pour arriver à faire la tâche à demander. OK et aujourd'hui du coup, si si on on fait un petit point historique. la scalabilité finalement ça a évolué comment ces dernières années et pourquoi est-ce qu'aujourd'hui on parle peut-être plus de de scalabilité horizontale aussi que de verticale. Alors effectivement, c'est un bon sujet, il y a une vingtaine d'années quand on commençait à parler un peu de performance, il y avait pas vraiment de problème de de j'ai envie de dire de d'horizontalité puisque grosso modo, les processeurs allaient de de plus en plus vite tous les 18 mois, la loi de Moore, on changeait de machine. Et grosso modo, quand votre service informatique, on lui demandait de d'accélérer la machine, globalement ce qu'il faisait, c'est qu'il allait acheter un nouveau CPU, une nouvelle RAM, ce que tu veux, il changeait la machine petit à petit. D'accord et on était dans un contexte où peu d'utilisateurs utilisaient les applications. Je rappelle dans un système d'information, il y a même si vous avez 1000 personnes qui utilisent un logiciel, d'accord, ça n'a absolument rien à voir avec des millions de personnes à travers internet qui utilisent un logiciel. Donc globalement, on arrivait plus ou moins à se satisfaire de machines plus ou moins performantes un peu plus le temps. En optimiser un peu le code, on amélioré un peu le CPU et globalement, c'était c'était ça une mission de performance. Sauf que maintenant, les applications, elles sont accessibles à un nombre d'utilisateurs qui est de plus en plus conséquent et ne augmenter la puissance d'une machine, ça a une limite qui est la capacité du processeur le plus puissant du marché. D'accord et globalement, les processeurs ils ont pas beaucoup évolué ces dernières années. On sait pas à faire des processeurs qui vont beaucoup plus vite que 4 GHz, on sait pas à faire des processeurs qui ont 100 cœurs, 120 cœurs, même si on arrive dans quelques cas à le faire, mais c'est pas le cas. Donc la seule moyen de qu'on a trouvé pour être capable d'aller plus vite et de répondre à la charge, c'est de multiplier les serveurs et c'est là où on commence à parler de scalabilité horizontale. Ça fait un petit moment que ça enfin ça fait quand même de nombreuses années que c'est mis en place, sauf que euh mettre une scalabilité horizontale, c'est pas juste multiplier les ordinateurs, ça a des impacts partout. Euh ça les impacts en particulier en programmation, en conception, en architecture du développement de l'application. Donc c'est pas euh vous pouvez pas aller voir votre informatique et prendre un programme qui a été développé il y a 20 ans en arrière et lui dire bah on va multiplier les serveurs et ça va marcher. C'est pas si simple que ça, il faut repenser l'architecture dans un ensemble. Et de plus en plus, euh on a une fusion entre le développement, l'architecture et la manière dont ça va être hébergé. Depuis très très longtemps, on en avait rien à faire, c'est-à-dire il y avait l'équipe développement qui développait et puis il y avait l'équipe infrastructure qui mettait des machines et il se parlaient pas ou juste au moment où il fallait mettre le serveur en prod. Maintenant, on a vraiment une fusion entre ces deux équipes avec tout ce qui va tourner autour du DevOps, tout ce que pour là-dessus. En gros, on va designer des des briques applicatives, ce qu'on va appeler des services, des micro-services, peu importe, qui vont être très très très très très proches de la manière dont ils vont être hébergés pour être justement scalable à l'infini.
[10:10]OK et ensuite du coup après un sur un AWS s'occupe de tout et euh Alors ils s'occupent de tout euh alors il y a pour revenir un petit peu en arrière pour la pour en tout cas pour je vais parler juste de la haute disponibilité, comment c'était fait avant. Vous aviez une machine et vous aviez une deuxième machine de relais. Quand la première plantait, vous vous rebranchiez sur la deuxième machine et ça repartait. Ça c'était un système à l'ancienne, mais ça ça ça nécessite d'avoir une coupure le moment où vous basculez dans un autre. Dans il y a une quinzaine d'années en arrière, on a fait des systèmes ce qu'on appelle virtualisé, c'est-à-dire que globalement, vous aviez plusieurs machines qui tournaient des machines virtuelles donc c'était des équivalents de ça c'est des c'est comme des ordinateurs mais virtuelles qui s'exécutait sur les machines qui étaient en dessous. Et le système, l'hyperviseur était capable de basculer une machine virtuelle sur un des host donc les hosts c'est les machines physiques qui tournaient dessous. C'est toutes les stratégies de ce que vous utilisez sur VMware, ce que vous avez entendu Vsphere, VMware, toutes les techniques de l'hypervision, ce que vous voulez. Et après, on a encore monté d'un cran au-dessus, c'est-à-dire que globalement maintenant, on a des petites des petits services qui tournent dans des VM, d'accord, ce qu'on va appeler des Docker, des cubes pour Kubernetes, ce genre de choses, des micro-conteneurs qui eux vont être déployés dans des machines virtuelles, on a pas enlevé ce qui avait en dessous, mais à travers le monde entier. C'est-à-dire que globalement, si vous achetez sur Azure ou AWS un petit conteneur Kubernetes, vous lui dites bah je veux que mon petit conteneur il soit disponible dans le monde entier. Et auquel cas, il va dupliquer ce petit conteneur à travers la virtualisation dans les tous les data centers de d'Azure ou d'AWS et eux ils en ont un peu partout sur la planète. Donc du coup, automatiquement, votre application va devenir disponible partout. Mais ça utilise toutes les stacks applicatives qui existaient auparavant, c'est juste qu'on est remonté d'un cran. Et puis c'est aussi l'avantage des des gros hébergeurs de cloud, c'est que ils ont techniquement des ressources infinies et dans quasiment tous les pays hormis l'Asie, ce qui fait que ben voilà, quand tu étais sur OVH et que tu voulais avoir je sais pas tu te dis je vais avoir un pic de beaucoup de serveurs, bah il fallait je sais pas si les font, mais c'était compliqué. Maintenant ils le font, mais c'était compliqué. Mais ils le font voilà, mais à l'époque tu louais des machines des hosts et tout. Tandis que AWS, tu veux muter par 10 ton ta capacité, tu peux le faire en deux clics. Euh et tu choisis où tu mets tes VM, tu choisis un peu un peu ce que tu veux. Et euh et c'est aussi la puissance de frappe euh de ces de ces clouds, c'est que ça euh C'est que c'est pas infini mais pour l'utilisation qu'on en a, ça paraît infini parce qu'on peut instancier un nombre de machines incalculables au moment où on a besoin. Et on peut installer, on peut le faire de manière programmatique sur Et ils offrent ils offrent tout un tas de services que nous on a pas, c'est-à-dire la haute la vraie haute disponibilité, c'est eux ils ont des équipes si ils l'aissent propres, bah c'est eux qui s'en occupent de faire ça. Et en général, il te ils ont un pourcentage de disponibilité, je crois que c'est 4 9, AWS ou 5 9 où il t'assure dans le contrat que tu as quand tu prends une VM que tu auras 4 9 et si tu as pas 4 9, tu as des compensations, mais il t'assure à on va dire quasiment 100 % que tu auras 4 9 par de de haute disponibilité quoi. Et après, c'est à toi si tu veux avoir plus de disponibilité derrière de de faire le l'essentiel pour avoir des trucs qui se dupliquent et cetera, plusieurs euh plusieurs VM différentes qui sont prêtes à prendre le relais en plus de celle de AWS et cetera. OK du coup après c'est de toute façon c'est toi qui gère ton ta stratégie entre guillemets de de scalabilité quoi. Si si on vient un peu d'un côté un peu plus pragmatique terre à terre, euh aujourd'hui euh le le thème de scalabilité, est-ce que ça touche finalement toutes les entreprises ou est-ce que c'est un sujet qui est réservé peut-être à ceux qui ont euh euh des applications enfin euh à travers le monde, des gros Facebook des choses comme ça. Alors effectivement, les gens qui sont amenés à travailler avec le public de manière générale, ils ont les plus grosses audiences. Donc qui dit plus grosse audience, dit des besoins de machines supérieures. Mais néanmoins, euh n'importe quelle application maintenant se doit d'être scalable parce que dans le même dans le système d'information, on véhicule et on traite de plus en plus de données, de plus en plus de documents, de plus en plus de choses. Et on est très très rapidement maintenant à la limite de ce que sait faire une machine physique. On est à la limite pour deux raisons principales, c'est que nous en tant que développeur on prend beaucoup moins, enfin les gens prennent beaucoup moins d'attention à ce qu'ils font. C'est que globalement, on instancie un nombre d'objets incalculables et compagnie et on utilise de plus en plus de services de haut niveau qui consomment de plus en plus de mémoire. On est beaucoup moins optimisé intrinsèquement que ce qu'on faisait avant, donc mécaniquement, on a un besoin de ressources qui est beaucoup plus grand. Donc la scalabilité touche vraiment ben maintenant dans toutes les applications, il y a un volet performance scalabilité quoi. Donc j'allais dire même pour les admettons je sais pas une entreprise qui a son ERP qui tourne pour 50 collaborateurs admettons, la scalabilité c'est un sujet euh C'est un sujet alors on va pas forcément dans pour ce cas particulier, on va pas forcément parler de scalabilité horizontale ou compagnie parce que pour 50 utilisateurs normalement techniquement une machine serveur est capable de le traiter. Par contre, on va plutôt travailler la scalabilité intrinsèque de l'application pour qu'elle soit répondre rapidement parce qu'il y a pas pire que pour un utilisateur. Aujourd'hui, on est tous utilisateurs de Facebook, d'Amazon, on a tous envie que ça réponde en moins de 15 millisecondes et quand on est sur un ERP qu'on crée une facture et que ça met 15 secondes, bah les gens ils ont envie de se tuer quoi. Ouais, et il faut quand même que l'application idéalement elle soit faite pour être scalable le jour où l'entreprise explose, qu'elle puisse rajouter des machines s'il faut pour. Faut pas que ce soit bloqué, sinon après il faut refaire l'appli quoi.
[20:07]Ouais, et il faut qu'on puisse Donc des fois, il faut savoir aussi transiger avec le métier pour dire bah oui, techniquement, on est capable de le faire, mais l'expérience utilisateur de ça, ça va avoir un impact monstrueux sur le reste. OK et donc ça typiquement, il vaut mieux le décider au début du projet pour le coup, c'est problématique ou est-ce que finalement ça se gère au long court dans l'application ? Alors, je voudrais bien vous dire que les gens le pensent dès le début, mais c'est pas vrai. C'est le truc qu'on ajoute au fur et à mesure avec les Dev et Tout. C'est ça. Alors ça c'est l'idéal. Et c'est là. euh voilà, globalement, les applications, elles ont des cycles de vie, on les fait évoluer, on les améliore. Mais en fait, après, il y a cette phase de maintenance évolutive classique, où en fait, bah, les métiers veut rajouter des fonctionnalités petit à petit, puis personne remet un peu en cause le l'architecture et puis euh, petit à petit, on rajoute des trucs, des trucs, des trucs, des trucs, il y a des développeurs qui passent qui connaissaient pas bien ce qui a été fait avant et on se retrouve avec un truc qui a un bozou qui commence à ramer un peu. Donc euh, c'est plutôt euh, comme on dit, une un la maîtrise des performances plutôt un chantier au long cours, de se poser des questions à chaque fois de de les de les suivre à chaque fois. Euh, et là-dessus, je je renvoie au podcast qu'on a fait sur l'observabilité ou ce genre de choses qui permettent d'avoir une évolution dans le temps des performances tout ça. Enfin, je vous laisserai la pub pour notre propre podcast maintenant, c'est le Génial. C'est le futur. C'est bon. Mais ouais, donc ça se au long cours, mais il y a il y a quand même tu disais tout à l'heure, typiquement, on peut pas prendre une application d'il y a 20 ans et euh et se dire du jour au lendemain, il faut que ce soit super scala Enfin et cetera. Il y a des bonnes pratiques à adopter de base quand même. Alors, il y a des bonnes pratiques de base. Une application d'il y a 20 ans, codée intelligemment peut tout à fait être scalable. Euh c'est pas euh les technologies du passé peuvent être amenées sur des trucs scalables. Par contre, il y avait des il y a des framework, des mauvaises pratiques qui ont été faites il y a 20 ans qui ne rendent le truc intrinsèquement non scalable. Et aussi les mauvaises pratiques de maintenant qui rendent les les performances qui sont dans ce cas-là parce que oui c'est vraiment juste un problème de de conception. Pour pour faire simple, si on veut si on veut faire une scalabilité horizontale, c'est-à-dire être capable de multiplier les serveurs, il faut que notre traitement unitaire soit toujours stateless. Alors sans état, c'est-à-dire que globalement vous puissiez faire une requête et elle soit indépendante du serveur dans lequel vous faites la requête. D'accord, pour ceux qui nous écoutent et qui sont un peu plus codeurs, ça veut dire qu'il faut que vous ayez pas vous ayez pas de session, vous ayez pas de de singleton, faut pas avoir des accès à des à des ressources qui sont pas partagées. Donc ça demande une conception un peu un peu particulière. Mais une fois que vous respectez des des concepts des concepts assez basiques, c'est-à-dire grosso modo, bah que ça soit full stateless et que vous ayez euh une architecture reste ou soupes qui soient correctement dessinée, globalement, il y a pas de raison que votre application soit pas scalable. Mais on se rend compte que elle ne se souvent pas scalable pour 2 % du code qui a jamais été pensé comme ça. Voilà. Donc ça demande un peu de réflexion et surtout dans la partie architecture des choses. D'accord et est-ce que aujourd'hui par rapport à bah aux aux clients en tout cas que vous avez aux projets que vous faites, est-ce que vous voyez que c'est vraiment une thématique qui est qui est vraiment importante et et connue et prise prise en compte au niveau des des équipes projets dans les entreprises ou ou est-ce que finalement c'est quelque chose qui passe peut-être à la trappe et que les utilisateurs hurlent pendant un moment avant que que ça passe ? Je pense que si, bah, je pense que euh Arthur, tu m'arrêteras, mais moi j'ai l'impression que c'est plutôt le le ressort, c'est plutôt j'ai des utilisateurs qui se plaignent et du coup ça ça remonte à la DSI et ça nous retombe dessus quoi. Euh, mais après on peut faire des choses, bah, je pense aux applications sur lesquelles tu bosses actuellement, bah, on a amélioré sensiblement les choses et du coup euh Ouais, mais c'est parce qu'en fait, l'application avait pas été pensée dès le début pour avoir autant d'utilisateurs. Et euh, et il l'avait dit que de toute façon, c'était une problématique que ils avaient en tête, mais que ils avaient pas les moyens de de mettre en place. Mais euh, mais voilà, et des choses toutes bêtes, c'est par exemple des paginations sur des listes qui euh, en fait, faut toujours se dire, est-ce que la liste peut devenir infinie théoriquement ? Donc, si elle peut devenir infinie théoriquement, donc c'est-à-dire je sais pas si on met des factures ou quoi, elle sera forcément possiblement infinie. Tandis que si on a juste une liste de type de facture, elle sera pas infinie vu que le type de facture c'est fini. Donc, il faut toujours se dire voilà, il faut c'est c'est souvent le le but du enfin le le développeur qui doit le faire, mais est-ce que ça, ça peut être infini, est-ce que ça, ça doit être ça doit être scalable, est-ce que ça, il faut que je fasse attention au nombre de données qu'on récupère. Et si c'est pas fait, bah, au bout d'un moment, ça casse et il faut refaire le développement quoi. Ouais, et surtout c'est assez pernicieux les performances parce que quand on développe généralement, on a pas de volumétrie de données importante. Donc toutes les petites erreurs qu'on voit pas en terme de perf, bah elle s'accumule et ça devient lent ou d'un moment quoi. Donc il faut vraiment être être vigilant et essayer de réfléchir avec les avec euh et et je pense que c'est vraiment un problème global, c'est-à-dire que bah, il faut réfléchir avec le métier pour pour penser des fonctionnalités plus simples, plus cohérentes pour éviter d'avoir des requêtes qui ramènent la terre entière ou des choses assez complexes à faire. Plus c'est simple à penser et à concevoir plus ça ira vite. Simple c'est simple. Comme d'habitude. Vous vous pensez que ça va évoluer comment cette thématique de scalabilité ? Est-ce qu'il y a des alors peut-être avec ce que fait parler tout à l'heure d'Azure à WS, est-ce que la barre est encore plus loin ? Moi, je pense qu'on va vraiment vers une fusion du développement et de la partie euh hébergement. Et du coup, on va de plus en plus être limité dans notre capacité de développement pour que ça soit compatible et cohérent avec ces grandes ces grands fournisseurs de services qui sont les hébergeurs actuellement. De toute façon après pour l'instant, je pense les plus gros progrès qui a à faire, c'est surtout côté base de données parce que au bout d'un moment bah on peut pas vraiment dupliquer des bases de données et avoir les mêmes données de partout. Donc eux, je sais que AWS, ils ont commencé à faire de la scalabilité verticale sur les bases de données, mais en direct, ce qui euh je crois n'est pas possible avec du MySQL ou du Postgre. Mais euh, voilà, c'est on peut pas en fait, on peut pas faire la scalabilité horizontale sur des bases de données parce que euh bah si si il faut il faut que toutes les données soient soient redondantes. Du coup, il faut à chaque fois dupliquer les données et cetera. C'est très très compliqué et c'est vraiment le le plus gros problème de la scalabilité en ce moment, c'est les bases de données pour que tout le monde ait les mêmes données en même temps exactement au même temps, c'est quasiment impossible du coup. C'est assez c'est assez dur ouais, et puis il faut dans une base de données, il y a des notions de transaction qui sont très fortes, c'est-à-dire que globalement on doit pas perturber les données. Autant dans le traitement, on peut on peut se permettre de rater des choses, autant sur la donnée, il faut qu'elle soit ça et ça complexifie beaucoup de mine à l'échelle de beaucoup d'applications. Sachant que souvent dans une application alors dans une application qui est très bien codée, c'est toujours la base de données qui va devenir le nœud limitant de la scalabilité au moins horizontale. Donc il faut euh c'est vraiment un point d'attention quoi. Il y a d'autres types de bases de données, on va peut-être pas en discuter là qui sont des bases de données no SQL, ce genre de choses qui sont plus orientées sur une scalabilité au détriment de plein de plein d'autres choses. Mais euh la base de données le SGBD relationnel tel qu'on le le pratique tous et qui restera la norme pour la majorité des applications de gestion et compagnie, elle a encore du mal à passer à une vraie scalabilité facilement en tout cas horizontale. Non, je pense que je sais pas s'il y a déjà des choses qui sont en route, mais je pense qu'on attend vraiment une révolution au niveau base de données pour ce qui est de performance en tout cas, enfin surtout scalabilité parce que c'est de la performance sur des petites des petits volumes mais au niveau scalabilité si on tombe sur des milliards de lignes, c'est ça devient compliqué mais en même temps c'est logique, enfin C'est des milliards de lignes. Oui. Bon, encore de belles optimisations à venir dans le métier. Toujours. On s'ennuie pas. Ouais, il y a de quoi faire. Euh avant de de clore le sujet, vous avez un conseil peut-être à donner à des gens qui nous écoutent, alors que ce soit des des développeurs pour le coup ou euh ou des gens qui qui soient amenés à à gérer des des projets applicatifs. Oui, on peut moi je pense à citer, je pense que l'étape 1 d'un problème de performance, avant de se poser les questions d'augmenter les machines et d'augmenter la puissance des serveurs, c'est de se poser la question c'est est-ce que mon application est bien codée et correctement codée ? Parce que vous pouvez claquer des milliers de dollars en augmentant les serveurs, ça n'aura pas d'impact. Donc travaillez sur les traitements unitaires, travaillez sur les le traitement unitaire qui est lent dans votre application, essayez de comprendre pourquoi il est lent et essayer de l'améliorer. Ça c'est vraiment l'approche métier n'allez pas claquer votre argent n'importe où, commencez par le code, le code, le code, le code, c'est quand même ce qui fait 99 % de la performance. Euh et pour les développeurs, moi ce que je conseille, c'est comme on l'a dit avec euh avec Arthur, c'est essentiellement des problèmes de relation avec la base de données. Dans tous les frameworks, on a pu en parler, il y a des ORM qui permettent de faire cette relation là. Laissez votre débugger avec les requêtes qui passent et posez-vous la question de est-ce que c'est bien normal que quand j'affiche une page, j'ai 50 requêtes qui se passent en base de données. D'accord, posez-vous cette question et ne masquez pas la réalité de ce qui se passe parce que souvent quand on arrive sur des missions de performance, le développeur se rend pas compte que ces trois pauvres clics à l'intérieur de son application, elle a généré 150 requêtes à la base. Alors qu'on pourrait tout à fait les agréger en une ou deux requêtes bien construites. Donc en tant que développeur, ne masquez pas la réalité, regardez tout et posez-vous les questions de est-ce que c'est pertinent. De la même manière, c'est c'est la même remarque que je fais à tous les développeurs et qui est plutôt pertinente, c'est que quand ça s'affiche lent et que le développeur dit ouais ben c'est compliqué et qu'on regarde et qu'il a transité 2 méga de données entre le front et le bac, la question c'est est-ce que tu penses que tu as 2 millions de lignes de données à afficher à ton écran ? Et là, il va vous répondre non et vous dites est-ce que c'est cohérent du coup de d'envoyer cette donnée là. Donc, posez-vous les questions, essayez d'être rationnel sur là-dessus. Et rappelez-vous qu'on était capable de faire des systèmes de facturation dans les années 70 avec 30 kg de mémoire. Donc faut relativiser quoi. C'est ça. Pour moi, quand on fait du surtout du front et qu'on récupère des données à chaque fois qu'on récupère des données, il faut toujours se poser la question de est-ce que j'ai pas trop, est-ce que dans le futur j'aurai pas plus et toujours à essayer de se dire OK, comment est-ce que je peux faire que quoi qu'il arrive, ça va tourner même si j'ai je vais récupérer 1000 lignes, est-ce que c'est bien pertinent de récupérer 1000 lignes, est-ce que je récupérerai pas plutôt 10 et au final, je fais les les loading. Toujours essayer de penser euh que dans dans si il y a 1 million d'utilisateurs ça marchera encore. Alors après il y a des choses qui sont possiblement impossible mais voilà toujours se demander est-ce que ça marchera avec un million d'utilisateurs ? Conclusion, réfléchir avant d'agir. Toujours la même chose. Et on peut pas palier aux problèmes de conception par des ordinateurs plus puissants, ça ne marchera pas. Il n'y a pas de mode performance comme souvent les clients l'attendent. Stop aux idées reçues. Ça. Punchline. Bon ben merci du coup les gars pour votre avis sur le sujet. Euh on va passer à la rubrique coup de cœur, coup de gueule. Arthur, tu avais un coup de cœur à nous partager aujourd'hui. Ouais, un petit coup de cœur, bon c'est pas vraiment pour le développement, c'est plus bah pour voilà pour la conception avant, c'est c'est Adobe XD donc c'est un un logiciel de la suite Adobe. Adobe pour les intimes, qui sert à faire des maquettes en fait avec euh avec en fait page par page et euh ce qui est vraiment bien c'est que pour un logiciel Adobe, c'est très simple d'utilisation. C'est-à-dire que si vous prenez un illustrateur, un Photoshop, vous allez rien comprendre en arrivant. Tandis que là, c'est c'est assez simple le toute l'interface est très simple à comprendre. Euh et vous avez des systèmes de vous pouvez créer en fait des maquettes interactives où vous pouvez faire des clics sur des boutons euh que vous pouvez envoyer au client qui a carrément une une maquette de l'application interactive où il va avoir les pages qui défilent, tout ce qui va avec et en plus euh vous allez aussi avoir euh pour les développeurs, le CSS qui est euh qui va être exporté depuis votre maquette. Donc si vous mettez une couleur, il aura les couleurs. Si vous mettez les images, il aura les images. Euh donc il y a plein d'outils de maquettage comme Zelda plein ou euh ou comme ça, mais euh ouais, il y en a Figma et cetera. Mais moi j'utilise Adobe XD et c'est vraiment euh très agréable à utiliser, c'est il y a beaucoup de raccourcis, enfin vraiment avec quatre raccourcis clavier, on fait quasiment tout et euh et c'est vraiment très très agréable et ouais euh même pour moi qui ai jamais fait de qui ai jamais vraiment utilisé de logiciel Adobe ou quoi. Ça se prend bien en main, ça se prend très bien en main en quelques vous faites deux pages et c'est fini. Vous avez capable de faire. Ouais, c'est ça. Tu es capable de faire un espèce de prototype assez rapide et tu peux l'envoyer c'est interactif et cetera. Et même il y a un système de d'interaction où les tu peux envoyer une prototype interactif avec des commentaires où le client peut dire là, j'aimerais bien que le bouton soit un peu plus à gauche et comme ça, il y a pas besoin de faire des réunions toutes les 2 minutes pour pour pour mettre à jour le prototype. Et euh et je trouve que c'est vraiment bien. Moi j'aime bien maintenant en amont des développements faire une maquette pour parce que c'est compliqué quand on est développeur de penser le design pendant qu'on fait l'application, on perd beaucoup de temps où on se dit tiens là je fais une liste et au final ouais non, elle sera un peu mieux à droite, du coup, on rechange le CSS et pour moi, c'est beaucoup de temps perdu quand on rêve de faire le design enfin d'imaginer une sorte de design en tant que développeur déjà, on est pas souvent très très fort très fort voilà, on est pas très très fort en terme de design. Et du coup, c'est toujours bien d'avoir une petite maquette pour pas avoir à réfléchir. On fait les trucs instinctivement et au moins ça laisse plus de temps pour optimiser les performances. Voilà, la boucle est bouclée. Toujours comme d'habitude. Et moi, j'ai le droit à un coup de cœur ou pas. Vas-y, allez, cadeau. Euh moi c'est pas encore un coup de cœur mais c'est un petit pointeur sur un truc qui est en train d'arriver et que je suis assez excité. Euh alors je sais pas s'il y a des lecteurs parmi vous mais vous avez des tablettes ce qu'on appelle des Kindle ou des Kobo avec des écrans passifs là-dessus. Et ils sont en train de sortir ça va arriver sur la fin de l'année, des écrans d'ordinateur avec cette même technologie d'impression en inc et du coup c'est le gros intérêt c'est que vous avez des écrans qui n'ont pas de d'éclairage et de rétro-éclairage et du coup ça devrait être hyper agréable à lire au détriment du fait que ça soit en noir et blanc. Mais ils vont sortir cette fin d'année. Alors ça pour l'instant, ça coûte très cher, ça coûte entre 2 et 3000 € pour des écrans 23 pouces. Mais moi, je suis assez excité parce que je beaucoup de mal à lire sur des écrans lumineux, je trouve ça très désagréable. Et du coup, il y a peut-être des chances qu'on ait des écrans euh qui soient pas à l'aide justement et qui soient très à l'aise. Et puis je trouve que l'avantage aussi c'est que on peut on peut voir l'écran même en plein soleil. Après, on peut pas le voir la nuit, mais bon, avec une lumière euh ça ça suffit, mais voilà, il y a pas mal d'avantages. J'avais euh ma mère qui avait une une Kindle et franchement, c'est vraiment très très bien.
[33:22]Mais après euh je sais pas si c'est niveau affichage, si c'est peut-être peu performant. Alors, maintenant, ils ont faire des trucs assez assez chouettes. Je sais pas si tu peux afficher un film ou beaucoup d'images. On peut afficher un film mais vous avez des taux de rafraîchissement qui sont de l'ordre de 20 Hz, ce qui est ce qui est plutôt suffisant pour le travailler. Assez peu. Oui, pour le travailler, c'est suffisant. Par contre pour jouer, c'est enfin c'est impossible. Noir et blanc. Ouais. On a un peu de noir et blanc. Tu peux jouer à des vieux jeux quoi. Je joue à des vieux jeux. Par contre pour des moi je pense qu'il y a un gros avenir à cette technologie là. On en parlera dans les prochaines années parce que pas forcément que pour les dev mais pour tous les gens qui sont amené à être sur un écran toute la journée. Ouais, mais tu vois, par exemple pour un designer Non, mais si, mais oui, pour des gens qui ont des gens qui sont au burrotique, en comptabilité, qui sont amenés à être des écrans toute la journée, dont on sait maintenant que ça défonce les yeux de regarder des écrans toute la journée. Je pense qu'il y a vraiment un truc intéressant là-dessus. Euh même si c'est pour l'instant qu'à l'état de prototype, je suis assez excité par l'idée de m'acheter cet écran à la fin de l'année si j'ai si j'ai Mais tu crois qu'ils font des écrans portables ou ce sera que du fixe ? Euh pour l'instant c'est des écrans comme ça, hein. Ouais, c'est des écrans fixes, ils font pas un PC portable avec, c'est ça. Non, pour l'instant, il y a que deux constructeurs qui le font et il y a même des des téléphones portables maintenant qui sont sortis comme ça. Après de toute façon, ils vont tester, ils vont ils vont avoir les premiers retours utilisateurs, puis comme d'habitude. Il y a des petits écrans, mais sur des grands écrans, ouais, ça va être Moi je suis assez excité par cette technologie là parce que bon, en tant que développeur, moi la couleur, je m'en fous.
[34:54]Mais c'est beau les couleurs. Tu nous ramèneras ça, on fera un test. Ouais. On va tester. Comme d'habitude. La boucle est bouclée. Toujours comme d'habitude. Bah ouais, hein.
