Bonjour à tous, bienvenue, bonjour les devs, bienvenue sur cet épisode de Double Slash,
le podcast indépendant qui parle de développement web, Ediya, et on fait un épisode spécial
architecture logiciel, ça veut dire archi logiciel, on va dire, et comme d'habitude,
nous sommes avec Alex, salut Alex ! Salut Patrick, salut tout le monde, et un petit
épisode architecture, bon justement on va parler de tous ces concepts là, de tous
ces concepts à mettre en place en amont, où on va essayer de raisonner, de réfléchir
comment on va justement structurer toute notre appli, parce que c'est un peu difficile
de changer d'architecture, si on s'est trompé dès le départ, c'est un peu compliqué,
donc l'idée c'est pas de brosser, de vous donner toutes les stacks techniques, c'est
pas le but, c'est de bien comprendre l'architecture, les grosses briques, donc ça va être un
épisode où on va parler de concepts, ça va être très très très abstrait, on va essayer
de mettre ça et de faire quelque chose le plus concret et de ramener ça avec des exemples,
mais je pense que c'est hyper intéressant en tant que devs de ne pas se tromper quand
on a une architecture, notre logiciel.
Quand j'étais à l'école, j'aimais pas les cours théoriques, j'étais plutôt,
donc là pour le coup on va pas coder, on va pas montrer du code, on va parler vraiment
de théorie, mais c'est hyper important quand on lance, quand on a le projet de faire un
développement, de se poser dès le début au lieu de plonger dans le code directement,
allez vas-y je vais coder ci, je vais prendre cette stack, finalement la stack on s'en fout,
l'important c'est de se poser et de décider comment on va faire l'architecture de son système
pour qu'il soit durable dans le temps. Exactement, parce qu'on peut se tromper sur un
langage ou les choses comme ça, on peut changer des briques, par contre si on s'est trompé sur
l'architecture ça va être très très très difficile, on va parler de base de données,
on va parler d'API, on va parler de blocs, mais tout ça en fait c'est assez abstrait et on va
essayer de vulgariser un peu tout ça. Est-ce qu'on pourrait déjà, allez on commence, c'est quoi une
bonne archi déjà ? C'est une archi bien faite. C'est la question un peu piège où en fait on
pourrait, je pense qu'il y a autant de manière de faire que de... de... de... de de ces développeurs qui
pourraient... La bonne réponse, ça serait une archi qui correspond à ton projet, j'ai envie de dire.
Exactement, exactement. Donc en fait la bonne réponse ça serait... ça dépend quoi et... et... et
d'où l'intérêt en fait de se poser des questions, de dire ok ça dépend mais ça va dépendre de quoi.
Et... et c'est en fait où il faut admettre en fait que potentiellement en fait on va avoir
différentes archis, on va avoir différentes manières de faire. Chaque en fait structure qu'on
va apporter va avoir des avantages et des inconvénients et en fait ça va être à nous en
fait de... en tant que développeur de faire ces concessions-là et de créer en fait quelque chose
qui répond aux besoins. Mais... mais là-dessus je suis complètement d'accord avec toi.
Le premier truc c'est quoi ? C'est de... de réfléchir... d'analyser le projet en fait,
de... de voir... quels sont les besoins tout ça ?
Exactement. Et... et en fait une fois de plus nous en tant que développeur, notre job en fait
c'est de... de... de vraiment se poser des questions, de dire... et d'aller voir notre client et de lui
poser des questions et de... de répondre aux besoins. Et donc moi je vois déjà tant... de ma...
de... de... de... par... par... par notre expérience on voit que quand même souvent et comme tu l'as dit
souvent on se jette sur notre clavier, on construit des usines à gaz, on fait des trucs surdimensionnés,
ouais ça se... ça se cale à l'infini, tout. Ouais mais en fait quel est le besoin ? Quelle est la vision
business ? Et... et si on est en face d'un industriel avec des... des entrepôts, des millions de références,
est-ce qu'on va amener la même solution à notre vendeur du coin qui veut vendre trois
d'huiles essentielles sur internet ? Tu vois ? Et... et... et... et donc en fait on peut pas amener la
même solution technique que... que si on ne prend pas en compte en fait les besoins du client. Et
je vais vous laisser sur le podcast mais partir... partir du métier en fait, partir du... du... du
métier et récupérer toutes ces informations business pour en fait évaluer la maturité du
projet et la fiabilité en fait des informations que ton client va te donner. Par exemple soit...
ok on est une start-up, on a pour objectif de vendre ou d'avoir tant de users. Ok. Donc soit par
projection, dans ce cas là, ok on va calibrer, on va architectureer pour avoir le temps de user
par... par mois, par seconde, par... par jour ou par tout simplement observation. On parlait en off tout
à l'heure de... de... d'un retour d'expérience où moi le client est venu en disant moi ma
contrainte c'est ça. Je fais tant de chiffres d'affaires, j'ai tant de commandes par jour sur...
sur mon e-commerce dédié pour les professionnels. Bon bah en fait on peut largement architectureer
basé sur ce qu'il a déjà observé avec les contraintes qu'il a et à partir de là en fait on
peut largement construire. Donc la première... la première brique en fait c'est écouter et
partir du besoin et pas partir de notre tête. Ouais alors après il y a un truc qui est... tu vois
c'est... il y a deux... il y a deux choses là tu vois c'est... t'as le client qui a des contraintes,
qui a déjà des contraintes donc là c'est facile parce que tu sais où il en est tout ça tu peux
déjà réfléchir à une archi qui va supporter cette contrainte et évoluer donc tu sais que ça
fonctionne et après t'as le mec qui arrive avec sa... sa superité de start-up qui se dit
ah je vais devenir millionnaire machin, bidule et en fait tu sais pas vraiment si ça va marcher ou
pas alors il faut prévoir qu'éventuellement ça marche mais au début faut commencer petit machin
donc ça c'est moins évident en fait en général. Exactement exactement et donc c'est est-ce que tu
t'ouvres des portes pour le futur ? Est-ce que tu te fermes des portes pour le futur ? À quel moment
tu... tu mets en système en fait ce système de scale si tu veux et souvent les start-up on se
concentre déjà sur le besoin, sur répondre au problème et après sur une mise à l'échelle et
donc la chronologie est hyper importante. C'est ça et puis le 2... ouais parce que le 2ème cas du
mec qui a une start-up qui veut être millionnaire, l'erreur à ne pas faire c'est de surdimensionner,
de penser trop à scale et machin tout ça et du coup de se concentrer que là-dessus alors que
c'est une erreur en fait déjà. Exactement tu perds du temps et tu perds du temps business et nous en
fait en tant que dev on a souvent une envie de faire les choses nickel du premier coup mais ça ne
marche pas on n'y arrive jamais et donc en fait il faut admettre que notre logiciel il va être bon
de 0 à 10 par contre de 10 à 100 il nous faudra d'autres briques et de 100 à 10 000 en fait et
bah ça sera une autre architecture et donc c'est pour ça qu'on est en train de toujours en
fin de refaire des v1 et des v2 ou des v3 parce qu'on change l'architecture et donc de manière un
petit peu plus globale et si on prend encore un petit peu plus de distance sur notre architecture
on pourrait résumer en fait l'intégralité de notre logiciel en fait sur trois concepts hyper
importants qui sont les trois actions principales qu'on va faire. En clair on va transporter de la
données et là tu vas me dire ouais putain Alex c'est pas très compliqué. Tu reviens sur les DB
ça va pas nous reprendre la tête avec la DB. Non promis promis on va pas parler de DB même si on
va en parler un petit peu mais dans l'idée en fait ces trois concepts là il faut comprendre que
ces trois concepts là interagissent tout le temps tout le temps et ça va être à nous en fait de
bien architectureer ça. Quand on parle de transport de données pour toi ça t'évoque quoi ?
Transport de données je sais pas tu veux dire un formulaire qui se remplit ou une commande et
puis ça faut que ça aille dans un endroit pour être stocké c'est ça que tu veux dire ?
Ouais alors ça en fait ça c'est le premier niveau on est complètement d'accord qu'on va
avoir un transport de données entre l'interface graphique et le serveur donc souvent c'est une API
tout simplement en fait on va avoir une API ok on va transporter de la données mais on peut voir
aussi ça de manière sur notre machine en fait du transport de données entre le CPU,
la RAM et le RISC entre le front et le back évidemment mais aussi entre notre réseau,
entre tous nos systèmes, si on a différents dockers par exemple et bien notre réseau de toutes
nos machines en fait comment ils vont avoir et transporter toutes ces informations là.
Ça c'est intéressant donc ça c'est vraiment tout ce qui est transport après on va avoir tout ce
qui est stockage donc là je suis désolé Patrick on va être obligé de parler de DB mais en fait
comment on stock la donnée est-ce que on va stocker de la donnée de manière définitive
temporaire est-ce que ces données on va les structurer dans quelle base de données est-ce
que c'est du noSQL du KV enfin du clé valeur ou est-ce que c'est des fichiers en fait et dans
ce cas là il va falloir qu'on stock ça sur des des S3 ou un stockage de blob par exemple
mais on va aussi avoir on va stocker de l'information de manière temporaire je pense par exemple
aux événements analytics ou à des choses comme Kafka ou des choses comme ça ça va être des
événements qu'on va stocker alors qu'on va transporter et stocker pendant une période
X et donc en fait ça c'est un concept ok on va stocker de l'information.
Ouais il y a différents besoins de façon c'est en fait c'est le besoin qui va faire que tu vas
prendre tel ou tel DB comment tu vas stocker et je pense par exemple tu sais sur les services
à la demande comme type netflix ou quelque chose comme ça quand tu regardes un film tu as un moment
donné tu vas arrêter et il sait où par exemple ta connexion va couper et il sait à quel moment
ça a coupé tu vas reprendre tout ça et ça c'est stocker en fait le timestamp est stocké quelque
part voilà petit tapis au fur et à mesure que tu vis la vidéo là et donc ça c'est des bases de
données spéciales qui vont stocker ça et tout voilà mais c'est ça dépend de gens et exactement
et c'est là où ça va être super intéressant parce que tu vas pouvoir en fait tu dis ok pour telle
fonctionnalité j'ai besoin de stocker cette information là quel est le meilleur endroit
pour la stocker quelle est la manière la plus efficient et exactement exactement deuxième point
stocker la donnée et le troisième le troisième concept la troisième action tout simplement c'est
transporter transformer de la donnée transformer de la donnée déjà on le fait quand tu disais
tout à l'heure ben de mon formulaire à mon api en fait ben j'ai transformé de la donnée en
interface graphique et je l'ai transformé en gisane quoi tu vois alors si mon api et gisane
et machin tu vois mais je vais transformer de la donnée pareil quand je vais valider de la donnée
que ça soit en grave que elle ou si je fais du du du rpc ou du time du du type en fait si je
vais tipez mes informations bah en fait je vais transformer pour que ça soit clean pour que en
fait au moment où je reçois ces informations ça soit hyper hyper clean de la même manière en
fait je vais transformer ma vidéo youtube je vais l'eploder en 4k et youtube en fait va la transformer
en 180 en 720 en 480 pour pour pour les portables donc en fait je vais transformer toute cette donnée
là il rentre aussi les images dans tout ce qui est donné aussi absolument absolument exactement
je vais je vais je vais la transformer à la volée où je vais la stocker exactement et pareil sur
le stockage on n'a pas parlé des cdn et des choses comme ça mais on y reviendra on y reviendra
tout à l'heure mais sur la transformation aussi on va on va avoir en fait l'exploitation des données
intelligibles qu'est ce que ça veut dire bah tout simplement ok je vais avoir plein de lignes de
commande pour un e-commerce par exemple je vais avoir plein de lignes de commande sauf que au moment
où je vais faire un dashboard bah en fait je vais lire ces données là et je vais les dire ok
bah le panier moyen c'est ça le nombre de commande c'est ça bah tout simplement c'est à les
extraire ces informations là les transformer pour que visuellement en fait on est à une interface
qui soit intéressante donc je vais transformer ces données là et donc ça en fait c'est des briques
conceptuelles quoi ouais t'as aussi le par exemple tu veux avoir un e-commerce t'es un logisticien tu
veulent devoir lui envoyer sous un format particulier l'envoi des commandes etc donc il faut les transformer
aussi exactement et et et si c'est là où tu dis ok en fait est ce que cette transformation est
temporaire est ce qu'elle est juste est ce que je vais la stocker comme ça ou je vais juste la
transformer je vais lui envoyer et puis basta et en fait cette notion de toujours ces trois actions
transport stocker transformer en fait là tu vois on est très très très loin de est ce qu'on fait
du rust où est ce qu'on fait du go est ce qu'on fait du php est ce qu'on met du laravelle où on fait
on fait du web socket avec machin tu vois et en fait ça nous permet de prendre un tout petit
peu plus de distance et de relativiser et de bien comprendre la définition du problème
qu'on résout en fait tu vois ce que je veux dire souvent souvent quand tu justement quand tu fais
cette phase d'études déjà du besoin plus de l'archi et ensuite c'est justement ensuite tu fais le
choix de stack etc qui sont adaptés à ton truc voilà ça c'est dans le bon ordre en fait et pas
l'inverse tu vois je choisis ma stack et après je m'adapte en fait où je transforme ma stack parce
que je veux que ce truc fasse tout exactement mais je suis persuadé que tu connais l'expression quand
t'as un marteau dans la main en fait tout tous tes problèmes sont des clous tu vois en fait non
tous tes problèmes se résout avec des clous tu vois parce que en fait le seul truc que tu as dans
ta main c'est un marteau et en fait l'idée c'est essayer de comprendre ce qui se passe pour dire
ok ben pour le transport la meilleure brique techno qu'on pourrait faire c'est ça est-ce que c'est
celle-ci que je dois mettre en place ben oui ok il faut que je monte en compétence là-dessus ou on
pourrait faire comme ça comme ça comme ça parce que après il y a aussi il y a aussi un concept qu'on
n'a pas encore abordé mais c'est tu dois aussi composer avec ton équipe de foot quoi tu vois c'est
pas oui c'est c'est c'est c'est c'est à dire ok tu peux jouer un championnat mais il va falloir
que tu joues avec l'équipe qui est sur le banc quoi et donc il va falloir que tu composes avec tout ça
donc tous ces choix techno en fait ils vont arriver après mais là tu peux pas tromper c'est sur le
transport le stockage et la transformation ça t'as pas le droit de te tromper parce que tu peux
dire que c'est lié à ton équipe à tes compétences en interne et tout ça de façon ça on peut
témoigner tous les deux mais combien de fois on a des demandes de projet où ils ont déjà choisi
le stack et tout bien avant d'avoir savoir ce qu'ils voulaient faire ou le besoin que ce soit
et on te dit ouais je veux utiliser ça ok d'accord ok et on l'a tous fait et la question c'est ok qui a
décidé de ça le le board ok ok et y a qui au bord ok c'est des mecs c'est que des marquetteux ou
du business tu vois et ils ont l'habitude de ça donc ils veulent garder ça c'est un on sens
total on est complètement c'est c'est malheureusement une c'est souvent comme ça la plupart des projets
c'est ça et après pour leur faire autant de raisons c'est compliqué après tu leur dis
écoutez si vous m'embaucher bah en fait c'est parce que j'ai des compétences tu vois ces compétences
là en fait si si vous si vous êtes pas en capacité moi mon devoir de conseil c'est ça quoi donc ce
que vous faites là c'est n'importe quoi ou c'est pas bien et bah après si on peut pas travailler
ensemble c'est pas c'est pas gênant ça c'est une dimension business on va dire exactement
donc une fois qu'on a bien compris ces concepts là ok on va pouvoir en fait passer à la deuxième
grille de lecture en fait qui est quels sont en fait les prérequis fonctionnels et les prérequis
non fonctionnels qu'est ce que ça veut dire bah tout simplement les prérequis fonctionnels c'est
vraiment pour le coup un un cahier des charges ou un cahier de feature c'est à dire ok le client
il va se mettre sur sur telle telle interface il va cliquer là et ça va faire ça va générer
ce genre de résultats et j'attends d'avoir sur l'autre page d'autres résultats ça c'est l'approche
très très fonctionnel et donc il va nous falloir en fait construire comment on va résoudre ce
problème là avec des briques techniques et la partie non fonctionnelle bah c'est la partie
justement ce qu'on ne voit pas donc ça va être la scalabilité la performance la disponibilité
le nombre de requêtes par seconde donc ça c'est tout ce qui est tout ce qu'on ne voit pas donc la
partie non fonctionnelle donc là la partie fonctionnelle elle s'organise en fait souvent c'est un peu
toujours la même chose on se rappelle transport stockage transformation mais transport transport
bah la chose la plus basique c'est c'est quoi c'est la pays on est d'accord et donc en fait
bah ça veut dire qu'on va mettre un front donc on va pouvoir designer et pour le coup je vous
invite vraiment à essayer de visualiser quelque chose vraiment de manière très très graphique où
on met juste un carré on dit ok front un carré api une flèche ok l'api elle va dans le front du
front elle va au bac ok et cette api là en fait elle va si on prend notre exemple par exemple de
youtube ok je veux je vais je vais me connecter à ok donc ça veut dire que j'ai une brique
d'authentification briques d'authentification donc j'ai une api qui va gérer mon authentification est
ce qu'elle est synchronisée est ce qu'elle est monolithique est ce qu'elle est en micro service ça
pour l'instant on ne peut pas le savoir parce qu'on n'a pas d'autre information mais côté
fonctionnelle on va avoir une briques d'authentification on va avoir une brique pour envoyer je vais
uploader ma vidéo donc je vais avoir en fait une brique pour uploader ma vidéo donc une api
pour uploader et cette vidéo il va falloir la stocker donc je vais avoir un stockage type type
fichier pour enregistrer les données sauf que ma vidéo elle va avoir un titre elle va avoir des
informations des catégories des commentaires des choses comme ça donc je vais avoir une db je vais
ok et troisième troisième point il va falloir que cette vidéo en fait elle soit optimisée sur les
les différentes les différentes dimensions bah ces différentes dimensions là je vais avoir en
fait un worker ou quelque chose un service en tout cas une brique qui va en fait transformer de la
ok ça c'est on va dire la vision assez logique basique et en fait en visualisant en fait tout ce
process là en fait on dit ok bah il nous faut une api pour ça une api pour ça une api pour ça un
worker pour faire ça quelle est la meilleure stack techno pour faire ce ce système là et on va pouvoir
passer en fait au au tamis comme ça toutes les fonctionnalités et on va construire en fait notre
architecture basée sur ces grands sur sur ces grands concepts là et à chaque fois qu'on utilise en
fait une nouvelle brique et bah on la visualise et on la met dans ce diagramme ou ce flow on peut
appeler ça comme on veut aujourd'hui on a plein d'outils pour faire ça mais ça va nous permettre
en fait d'avoir une une trace de de toutes ces briques techno en fait qu'on est venu rajouter et je
vous invite fortement à le faire non pas avec en mettant le nom du langage ou du framework ou de
de en fait il faut vraiment que ce soit totalement agnostique pour se poser les bonnes questions
après dans un deuxième temps de quelle est la meilleure techno qui répond à ce problème là
c'est clair oui de toute façon tu as cette sa tu peux le faire même sur un papier avec papier crayon
il n'y a pas besoin de s'endordir quoi que ce soit tu te poses sur une table tu prends un papier
un crayon et tu réfléchis il fait des carrés et puis il y a des flèches et puis voilà et sans faire
les rudis et essayer d'impressionner le client c'est pas le but mais le fait de l'impliquer
en tout cas basé sur l'expérience que j'ai le fait de lui montrer l'architecture de dire ok
avec des mots hyper simples toi ça t'oblige à vraiment faire de l'abstraction plus plus plus
et surtout de te dégager du jargon techno-technique et tu lui dis bah voilà il ya une interface vous
arrivez sur votre ordinateur il ya une interface elle va communiquer avec un serveur ce serveur il
va gérer l'authentification il va gérer la base de données il va là on va on va avoir un autre
serveur qui va traiter la donnée tout ça en fait tu lui expliques comment tu vas faire ton
métier et ça permet de simplifier de vulgariser et un client alors ça c'est pareil mais c'est
un client qui comprend ce que tu fais c'est rare en fait qu'il n'apprécie pas ça le rassure
exactement ça va rassure et c'est hyper important alors c'est vrai quand on est salarié on s'en fout
mais quand on est à son compte ça fait vraiment la grosse différence non c'est important et puis ça
permet aussi de ne pas oublier des choses tu si tu lui expliques voilà il ya l'authentification
machin le stockage on va transformer des trucs les vidéos par exemple tout ça tout ce que tu as
expliqué là et lui va dire mais est-ce que ça va faire ça ah oui ça on avait pas pensé ah oui
effectivement tu vois donc ça permet aussi de rien oublier et ça c'est la partie où souvent
on est on est assez lucide on parce qu'on sait faire c'est très très très fonctionnel et on a
plutôt l'habitude nous en des développeurs de de en tout cas créateurs de solution c'est plutôt
facile de mettre ça en place par contre toute la partie non fonctionnelle tu vois souvent ça
va être le boulot un peu des dévops tu vois c'est barbu les barbu pas de troll pas de troll les
gars pas les mecs à la cave au dernier au moins un la partie non fonctionnelle c'est ok en fait
comment on va déployer toutes ces solutions là pour que toutes ces briques là en fait passe
certaines au tamis si tu veux de la scalabilité de la performance et donc le fait d'architecturer
correctement en fait va nous permettre de de passer en fait toutes ces prérequis et c'est ce
non fonctionnel parce que en fait on a respecté toutes les bonnes pratiques et c'est important
en fait quand on parle de de scalabilité de comprendre en fait c'est une mise à l'échelle c'est
à dire ok on va passer de de 100 requêtes par on va de 100 commandes par jour à 4000 commandes
par jour alors ça va pas se faire du jour au lendemain ça va souvent ça monte de manière
incrementale et progressive mais c'est de dire comment on va faire pour passer à l'échelle et si on
a mal conçu et si on a mal programmé et on a mal architecturé les briques fonctionnels donc les
briques qu'on utilisait tout à l'heure et ben la mise à l'échelle va être très très très très
très difficile et donc d'où l'intérêt en fait d'essayer de faire bien du premier coup même si on
a vu tout à l'heure que c'était quasiment impossible c'est rare de faire bien du premier coup
c'est très présent de jour c'est très présent de jour tu peux avoir aussi le côté ton site
fonctionne la plupart du temps correctement et puis ton e-commerce par exemple puis quand t'en vois
par contre d'une newsletter parce que t'as beaucoup d'inscrits bah là ça fait monter en charge et il
faut résister à cette charge donc et que le site continue à tourner parce que sinon ça n'a rien
envoyé une newsletter tu vois donc si les gens arrivent dessus et que le site marche plus et c'est
la disponibilité exactement mais ça en plus on a tous connu des petites boîtes qui avaient un petit
wordpress tout ça ça c'est le côté effet passe à la télé il y a un reportage sur le 20h
sur cette petite boîte tout ils ont un wordpress pour leur site internet il ya tout le monde qui se
connectent dessus le serveur est en pls terminé des nids de service et bah tu as raté l'occasion de
transformer ta pub et donc comment tu fais pour garder une haute disponibilité on va en parler
quand on parle de de scalabilité et de monter à l'échelle en fait il faut bien comprendre la
définition il ya deux vers il ya deux possibilités en fait de de de de de de de mise à l'échelle en
fait on parle souvent de scalabilité horizontale et horizon et verticale ces deux concepts qui
sont assez simples à comprendre faut-il encore en fait les expliquer de manière assez simple et
la scalabilité verticale en fait l'idée c'est on va mettre une plus grosse machine tout simplement
si vraiment on simplifie ok bah on va mettre une une plus grosse machine on met plus de machine
ça marche horizontal en fait on va mettre plus de machine justement en fait au lieu d'avoir une
plus grosse machine on va mettre une deuxième machine une troisième machine une quatrième machine et
en fait chaque scalabilité que ça soit horizontal ou verticale a des contraintes spécifiques par
exemple si on met une plus grosse machine donc on joue en vertical on met une plus grosse machine
peut-être qu'elle va être surdimensionnée pour 90% du temps mais dans les 10% du passage à la
télé elle va répondre au besoin est-ce que c'est intéressant ou à l'inverse si on reprend notre
exemple de youtube en fait au moment où je ce qui me prend de la ressource en fait c'est uniquement
la transformation des vidéos c'est ça qui me croque de la ressource et donc est ce que je vais
d'obliger de grossir ma machine uniquement pour cette fonctionnalité là est ce que je n'aurais
pas intérêt à sortir et à dégager cette fonctionnalité là pour pouvoir la sortir sur
une machine dédiée ou sur un et pour pouvoir en fait jouer la scalabilité en horizontal
mettre plus de worker quand j'en ai besoin quand je transforme et comme ça cette fonctionnalité là
en fait je peux la la scaler beaucoup plus facilement parce que j'ai c'est uniquement ça qui me
prend de la ressource par contre à l'inverse sur de l'horizontale il va falloir en fait que je
distribue mes informations entre toutes mes machines c'est à dire quand j'ai dix mecs qui se pointent
bah si j'ai deux ou trois machines je vais faire ok les deux premiers je vais sur ils vont sur la
machine a les deux suivants ils vont sur la machine b les trois autres ils vont sur la machine c donc
ça veut dire qu'on va introduire un load balancer ça veut dire qu'il va falloir que si par exemple
j'ai un système de chat en fait et bah vu qu'ils sont sur des machines différentes bah ils vont pas
avoir ils vont pas partager les mêmes infos donc il va falloir avoir un système pour synchroniser
voilà tout ça c'est des c'est des complexités qu'il faut garder en tête que de toute façon la
scalabilité qu'elle soit verticale horizontal c'est pas facile ça vient avec des contraintes
on parlait juste avant l'épisode de l'exemple des emails tu es un gros spam tu es un gros
spammeur et t'envoi un million d'emails par semaine et à ce moment là est ce que tu mets pas ça
sur un service séparé sur une machine qui va gérer que l'envoi des emails plutôt que d'être
sur le serveur principal etc donc absolument et d'où l'intérêt en fait de penser
cet archi là des dire ok on va on va le sortir comme ça demain si on a besoin de ce qu'il est
on pourra le faire de telle manière on va jouer sur du vertical ou sur de l'horizontale autre point
et on sait toujours que dans notre business ce qui est toujours compliqué c'est la base de données
c'est souvent en fait le goulot d'étranglement de tout notre système comment on scale de la
de la db pareil toujours soit sur du vertical soit sur de l'horizontale avec des grands concepts
l'idée c'est pas de vous expliquer comment on fait ça aujourd'hui mais c'est le concept de
sharding le concept de réplique et de donc de sharding en clair je vais prendre ma base de
données de a à m ça va sur la base de données 1 et de m à z ça va sur la base de données 2 j'ai
donc réparti en fait mes données sur sur deux bases de données donc c'est beaucoup plus c'est beaucoup
plus light ou sur 3 ou sur 4 ou sur 5 ça amène plein de problèmes on est d'accord ou je je réplique
un pattern qu'on voit souvent aussi c'est le le le master et le le slave j'envoie sur une base de
données qui va écrire et je vais lire sur une autre du coup je vais répartir la charge on est
on est bien d'accord que là c'est une vision ultra simplifiée c'est beaucoup plus complexe que ça
mais l'idée c'est ok quelle technique je peux faire pour utiliser et en tout cas pour scaleer la base
de données le sharding le réplique et les masters lave c'est c'est c'est un peu le concept et le
dernier point ouais vas-y moi ouais pendant souvent c'est les problèmes aussi qu'on peut avoir quand on
a mal pensé la débaie on n'a pas encore parlé on en prendra sûrement après quand un mal pensé
ta débaie des fois peut demander beaucoup plus de ressources alors que juste parce qu'elle a
mal pensé après on peut en parler maintenant parce que c'est totalement pertinent quand
tu dis ta mal pensée ta débaie tu penses surtout à la structuration de tes tables la structure
des tables tout ça des relations et des requêtes qui en découlent forcément donc des fois ça
fait péter ta débaie alors que t'as pas forcément beaucoup de trafic mais tout a été mal mal conçu
dès le début des enquêtes qui sont énergivores et du coup tu es débaie d'objet j'ai déjà connu ça
c'est pour ça que je m'en parle des index j'ai déjà connu des oua déjà les index par exemple
mais j'ai aussi connu des je suis bossé dans une boîte on avait un système de forum qui était
pas forcément bien pensé au niveau de la débaie et qui demandait justement des beaucoup de serveurs
de débaie pour répondre à toutes les requêtes et pourtant c'était pas un trafic de ouf c'était
50 000 visites mais voilà juste parce que le système était mal pensé bien structuré ces tables
et pareil ça c'est genre d'information si tu t'es piné sur ta structure de table c'est compliqué
de la faire bouger quoi très très très très très très très compliqué et troisième point on a
déjà un peu abordé sur sur sur cette notion de scalabilité horizontale ou verticale mais en tout
cas si tu as des process donc que ça soit la transformation d'email ou la transformation
de l'envoi d'email ou de transformation de vidéo bah tout simplement en fait tu vas pouvoir mettre
en place des des workers qui sont dédiés à ça après tu vas pouvoir mettre des systèmes de que
ou des choses comme ça sous réserve en fait que ce service là a été isolé et dédié par contre
si il est intégré à ta grosse stack bah ça va être difficile tu vas être obligé de le sortir
quoi donc beaucoup plus facile de le faire évoluer si en tout cas ce service qui est
potentiellement énergivant difficile à à ce qu'il est ou qui est le goulot d'étranglement de tout
ton système bah autant le sortir très très vite pour éviter qu'il soit aussi qui soit trop trop
au goutier à ce qu'il est quoi c'est c'est primordial ça par contre ne enfin ne fait
de jamais tu es une transformation d'image de n'importe quoi de document tout ça en live en
direct quand quelqu'un le bloe dans un truc comme ça c'est toujours des que tout le temps tout le
temps il faut tout différer quoi sinon là tu fais péter ton truc et puis pour le pour l'utilisateur
c'est pas agréable d'attendre exactement et et aujourd'hui on a on n'a n'importe quel framework
il ya des systèmes qui gère très très très bien ça quoi toujours ouais tous tous ils se
intégrent tous ça en fait donc donc pour le coup c'est totalement l'angage agnostique framework
agnostique et quasiment tous on sait système là faut-il encore l'avoir pensé dès le départ
pour éviter d'avoir d'avoir ce type de problème là une autre une autre bah justement
manière de toute façon est extrêmement extrêmement lié à un autre point aussi sur
ces prérequis en tout cas sur ces besoins non fonctionnels bah c'est la performance tu l'utilisais
tu t'es évoqué le point tout à l'heure si on ne met pas ce système là en place si on met pas un
système de cu en fait potentiellement on va avoir des performances de merde et ça va dégrader l'expérience
d'utilisateur et en fait ce qu'il faut moi j'aime bien voir la performance sous sous un pris
m'en fait d'un d'un tuyau en fait un tuyau un tuyau de canalisation en fait il va avoir un diamètre
donc c'est le volume d'eau en fait qui va pouvoir traiter en instantanée donc pour nous dans notre
dans notre jargon ça va être le volume de requête le volume de couérie qu'on va pouvoir
absorber le nombre de de terrabites qu'on va pouvoir traiter en en en live donc en instantanée et
après en fait on va avoir donc le diamètre et après on va avoir la longueur du tuyau là ça
va être en fait le temps en fait qui va nous falloir pour traiter ces données là donc la
performance en fait c'est avoir un tuyau hyper large le plus court possible voilà et là c'est le
top le top de la performance et donc plus plus on a un tuyau hyper long plus on va on va avoir de
la latence et donc il existe plusieurs méthodes pourquoi tu rigoles non ça pourrait déformer
par contre on parle de longueur des tuyaux on parle d'être au plus proche de l'utilisateur ou
plus proche du donc là on parle de alors en fait en fait le concept de longueur en fait ça va être
la latence entre le moment où il fait une action et de de de de réaction donc potentiellement en
fait ce qui ce qui pourrait ce qui va pouvoir rentrer en compte en clair ça va être par exemple
chaque opération une inscription à l'adb ton cue l'envoi de ton email tout ça en fait ça va
prendre du temps et donc c'est la somme de toutes ces actions qui va faire que cette action
lente donc ça c'est un premier moyen un premier moyen en fait de réduire ta latence en fait c'est
de réduire la charge entre chaque opération donc c'est à dire que tu prends chaque opération et tu
l'optimise par exemple l'envoi d'email est ce que tu peux le différer oui tu peux le mettre sur
une cue est ce que la transformation de ta vidéo tu peux la mettre sur une cue oui donc tu la mets
sur une cue est ce que ton enregistrement de la de de la db en db tu veux le faire avant de lui
envoyer la réponse ben oui en fait tu veux être sûr que quand tu lui dis oui c'est bon que toi tu
la bien enregistré donc ça tu peux pas le différer ok est ce que est ce que t'as sur sur sur
ta db est ce que tu lui tu lui demande de retourner taquée d'information où tu lui dis juste c'est
bon c'est pas bon c'est est ce que c'est bien est ce que c'est pas en fait c'est un premier moyen
d'optimiser cette latence en fait c'est de réduire la charge par opération via via bah toutes les
techniques qu'on a pu qu'on a pu évoquer et après un autre moyen de réduire cette latence c'est de
réduire le temps d'exécution de chaque tâche par exemple un exemple typique qu'on connaît tous c'est
bah une requête à la db ça prend du temps si j'en si j'ai 50 fois cette même requête je vais
calculer 50 fois bah je vais pouvoir la mettre en cache donc là au lieu d'avoir on va dire 50
millisecondes de calcul là je vais avoir que 10 millisecondes parce que en fait elle est
dire je l'ai caché donc j'ai mis un système de cache ce qui va me permettre en fait d'augmenter ma
vitesse de d'exécution de cette requête là et donc par par mathématiques en fait je vais réduire
cette latence tu vois ouais oui tu peux très bien tu peux mettre en cache ne serait-ce que dans
l'application fronte ne serait-ce que si la requête a exécuté plusieurs fois tu gardes le premier
résultat et puis voilà sans faire d'appel réseau d'ailleurs exactement donc tu vas en fait le concept
sous-jacent c'est vraiment réduire le temps d'exécution de une seule tâche de la même manière
en fait un autre exemple possible c'est ce qu'on utilise aujourd'hui next nuxt fait la même chose
c'est on va chunker en fait les parties de js de chaque page ce qui fait qu'on va lui envoyer
on va en fait à chaque appel on va envoyer uniquement la page ce qui fait que on est venu
découper et on récupère toutes ces toutes toutes ces les informations de la page au fur et à
mesure de notre navigation ce qui fait que le temps de chargement de la page est beaucoup plus
minime et donc on est venu optimiser le temps de chaque requête donc ça c'est c'est un premier
moment en cache des éléments l'image et compagnie tu t'évites des appels aussi au serveur et donc
exactement qu'on ferait ton serveur pour des toujours les mêmes requêtes exactement exactement
et le dernier point tu l'as déjà évoqué tout à l'heure c'était en fait bah cette notion de réseau
de transport de réseau sur notre réseau en fait comment on va optimiser si en fait j'ai un cdn
qui est aux états unis j'ai ma db qui est à hong kong et j'ai mon serveur qui est en europe
bah tout ça ça va être compliqué tu vois en plus moi j'ai utilisé des dns différents donc des
noms de domaines différents donc il va falloir déjà je vais avoir une latence juste parce que je
vais avoir un nom de dns donc comment je vais structurer mon réseau au sein de mes dns au sein
de mes machines au sein de mon écosystème en fait pour que ça puisse être hyper rapide est-ce que
j'utilise des cdn spécifiques pour pour les pour les images qui sont vraiment optimisés et hyper
rapide est est-ce que je vais mettre ça sur des data centers régionalisés c'est-à-dire quand
la personne vit en europe bah toutes les infos sont en europe est est-ce que ça vient aux états
unis et bah je vais répliquer ces informations là aux états unis pour éviter en fait d'avoir à
traverser l'océan à chaque fois donc c'est vraiment cette notion de transport de réduire le
transport de données en essayant de jouer au plus proche de l'utilisateur ouais bah ça c'est
quand tu poses des questions et que tu vois ton client où sont situés ces c'est enfin où sont
ces utilisateurs si c'est des utilisateurs si c'est un client français qui a des utilisateurs
utilisateurs que en france ça ne sert à rien de répliquer ou d'aller chercher un serveur
est-à-unis tu le prends en france machin ou au plus proche en tout cas à wb c'est francfort ou
l'onde je crois si je me trompe pas et puis après par contre oui c'est ton client à des moi j'ai
un client qui a des différents sites portugais etc donc comme c'est de voilà on utilise clave
clair devant pour essayer d'avoir des trucs au plus proche etc donc voilà parce que oui
effectivement ça peut les latences peuvent vraiment augmenter fortement et si tu as quelqu'un
qui est au brésil et qui se connecte sur un serveur qui est en suisse par exemple et mais ça
non on le voit pas mais ça se ressent vraiment très fortement sur l'utilisateur bien sûr bien
et aujourd'hui tu vois t'as évoqué claude flair mais aujourd'hui tu as des
tu as des systèmes de de de de workers qui vont être répliqués un peu partout et donc tu vas
pouvoir exécuter du du du js au plus proche de l'utilisateur et donc en fait ton runtime donc
vraiment l'exécution de ton code se fait au plus proche de ton utilisateur et pour ceux qui n'ont
pas écouté l'épisode qui doit commencer à dater un petit peu mais c'était un épisode sur le
edge computing c'est quoi ce derrière là et ouais il date cet épisode là mais en fait l'idée
c'est d'aller exécuter l'information au plus proche de l'utilisateur et aujourd'hui on est même
passé en fait à des services type turceau ou comme claude flair en déwan qui sont en fait du
sq light mais ça va être répliqué au plus proche quoi donc c'est au c'est vrai l'exécution de ton
code et la base de données va être au plus proche de ton utilisateur et ça en fait bah ça va te
permettre d'augmenter en fait ta performance et donc de réduire cette latence donc si t'as bien
fait ton job et bah en fait tu tu viens optimiser le nombre d'informations que tu peux traiter en
parallèle tu viens optimiser chaque action et tu tu la répliques et tu mets ça au bon endroit
pour que pour que ça soit rapide et cette notion de performance est totalement taclée quoi même
si c'est jamais si simple que ça on est bien d'accord non c'est aussi simple et puis attention
ouais parce que souvent on peut prendre des offres gratuites ou très très basse en prix sur certains
providers ou bah on n'a pas trop le choix au niveau des délocalisations des serveurs et c'est un
peu dommage quoi des fois d'avoir un serveur très loin quand tu l'utilises en France voilà
et attention à ça aussi c'est important quoi et et malheureusement au départ c'est jamais cher
par contre la scalabilité peut vite te coûter très cher oui oui ça faut aussi on parle pas du budget
mais c'est quelque chose à anticiper ouais par exemple tu vois par exemple sur l'AWS c'est
connu pour avoir avoir du mal à très difficilement calculer le coût qui va venir donc c'est bien de
d'arriver à savoir le coût tout ça même pour le client tout ça parce que c'est vrai que sur si on
a beaucoup de visites il y en a beaucoup de ça se scale beaucoup ça peut être très très très très
cher ça c'est le truc à prévoir c'est clair exactement d'où l'intérêt en fait potentiel
de sur toute cette partie non fonctionnelle le troisième volet c'est vraiment essayer de garder
de la disponibilité et donc dans cette disponibilité bah c'est ok si j'ai 100 personnes qui se connectent
en même temps combien de personnes vont avoir une 200 un succès quoi et donc ça c'est hyper
important d'avoir ce type d'information là donc ça veut dire que bah on est obligé de
monitorer ça me paraît hyper indispensable et souvent il y a un standard qui est utilisé ce
qu'on voit en fait qui est le service level agreement ou et c'est là exactement avec les
standards et le vocabulaire utilisé c'est combien de neuf en clair donc t'as 99,4% et en fait ce
qui est petite anecdote mais quand le client tu lui dis bah voilà le but c'est d'être à 99,9
donc 39 ça c'est le standard 39 et là il te dit ouais ouais c'est bien alors bien sûr c'est
largement suffisant bon c'est largement suffisant mais déjà juste 1% dans l'année ça veut ça veut
quand même dire 3 jours virgule 6 3 jours virgule 6 donc ça fait 80 je sais plus combien de tête
je me rappelle plus mais plus de plus de 85 heures et là tout de suite le client il te regarde et
dit ah ouais mais là ah ouais quand même ça fait beaucoup quoi tu vois et donc en fait le but c'est
d'aller d'aller augmenter son nombre de neuf en fait pour pour en fait avoir 99,9999 pour se tendre
vers 100% qui est une utopie totale parce que t'as de c'est exactement mais en fait mettre en
corrélation pour reprendre notre exemple de du e-commerce avec 3 huiles essentielles pour le
petit shop du coin si lui il est sans site et par terre pendant 12 heures ou une journée c'est pas
50 000 références et qui tombe par terre sur une journée poste pré-noël juste avant noël ou un
e-commerce qui tombe par terre pendant les soldes là c'est pas la même là c'est pas là tu vas
passer un mauvais quart d'heure là d'où l'intérêt en fait de bien comprendre ce concept de s l a
de 399 de 499 599 et de de monitorer en fait toutes ces informations là et il y a même aujourd'hui
des des frameworks qui te permettent en fait de pouvoir tester cette charge serveur en fait de
dire ok je vais exécuter 1000 requêtes en 6 multanés et combien de pourcentages vont avoir un
succès c'est un petit framework s'appelle cassis qui marche plutôt bien et tu en fait tu vas
pouvoir tester ta charge serveur donc c'est plutôt plutôt intéressant ouais après il y en a sans doute
d'autres pour le coup c'est celui que je que moi perso j'utilise mais évidemment il va falloir
qu'on mette en place un système de bug tu vois de remonter d'information parce que on va pas si on
a des bugs si on attend que notre utilisateur nous envoie un petit mail en disant j'ai voulu
faire ça et en fait ça ne marche ça n'a pas marché tout ça ça n'arrivera jamais personne le
frein donc on n'a pas l'info et commercialement c'est hyper intéressant aussi en fait de si ton
client envoie l'information en disant oui on a notifié qu'il y avait un bug et là tu dis
oui effectivement ce bug a commencé à tel jour à tell heure il a été fixé par tel comit à tell
heure il a été déployé et bah ça en fait commercialement c'est super bon quoi donc être
en avance en fait sur les remontées client ça c'est super super intéressant autre point qui
peut être intéressant aussi à mettre en place pour aller justement aller chercher à optimiser
cette performance c'est ce concept de tracigne en fait où aujourd'hui on a des outils qui nous
permettent en fait de voir entre le moment où la requête est arrivée sur notre serveur et la
requête est partie toutes les étapes sur laquelle il y a eu le goulot des étranglements on va
pas revenir sur l'épisode qu'on a fait sur les logs mais en tout cas c'est un type de log qui peut
être super intéressant et je m'excuse d'avance pour le mot que je vais utiliser qui fait bon dire
patrick c'est le grand concept c'est l'observabilité on sait que on sait que t'aime pas ce genre
d'infos alors je reviens l'art de logger c'était l'épisode 115 c'était en juillet 2025 donc c'est
vraiment pas vieux si vous voulez écouter si vous voulez encore écouter exactement et on en parle
de l'observabilité je crois on en parle parce qu'il faut en parler mais en tout cas sur une
architecture si on veut passer à l'échelle ça me paraît difficile de faire sans de ne pas logger
on est au petit bonheur la chance quoi c'est vraiment tu es obligé de savoir ce qui se passe dans
ton app de toute façon puis voilà justement tu es obligé de savoir tout ce qui se passe combien de
temps ça prend tout ça et voir le payier optimiser le code tout ça c'est une obligation
surtout si tu as des ambitions clairement et mais une fois de plus c'est vraiment le business qui
va déterminer qui va déterminer tout ça et il n'y a pas de de de de recettes magiques en mode ce
pattern là il marche partout tout le temps bah non en fait ça dépend on a essayé là essayé de
de brosser de manière très très large et de manière très globale si on se pose toutes ces
questions là et si on découpe de de de telle manière qu'on respecte toutes ces best practices
analyse de qu'est ce qui est fonctionnel qu'est ce qui est non fonctionnel qu'est ce qui est du
transport qui est du stockage qui est de la transformation si on arrive à découpler toute
notre application avec ces grands principes là clairement je pense qu'on peut pas trop se tromper
et après ça sera à nous de composer la stack technique pure en disant bah là on va mettre du
centri là on va mettre une db pose gré et là on va mettre du redis là on va mettre du laravelle
echo là on va mettre du php là on va mettre un microservice là on va faire du monolithique voilà
ça après il ya d'autres contraintes qui vont rentrer en jeu par contre sur l'architecture
fonctionnelle non fonctionnelle je pense que on a bra on a fait un peu le tour et si on respecte les
grands concepts généraux qu'on a évoqué je pense qu'on peut pas se tromper moi c'est clair
de façon c'est c'est bon pour tous les projets que ce soit des petits projets ou gros projets
ambitieux tout ça voilà se poser réfléchir le besoin comment ça va se s'architecturer puis
voilà quoi c'est vraiment une une étape à faire à chaque fois en fait c'est un préroquis avant de
se lancer dans le code tu vois exactement on est devenu mur t'as vu on est on est des vieux
comme patrick on est des vieux réfléchir avant de coder t'as vu c'est fou quoi yes écoute patrick
je te propose qu'on en reste là sur cet épisode architecture logiciel on remercie tous ceux
qui sont restés là jusqu'au bout de l'épisode pensez à nous mettre un petit pouce un petit like
ça fait toujours plaisir on remercie un grand merci à tous nos sponsors qui le font
via le github sponsor et à tous ceux qui prêchent la bonne parole et qui font la promotion pour nous
de double slash on vous dit à très vite ciao ciao ciao