Bienvenue sur le podcast Artisan Developer,
l'émission qui combine technique et agilité pour partager la passion du code.
Aujourd'hui je suis avec Christophe Chaudier. Christophe bonjour.
Bonjour.
Lors de la préparation de cette interview, tu m'as parlé des douze facteurs
qui empêchaient de passer à l'échelle et ça m'intéresse vachement parce que je me dis
en tant que développeur,
autant je ne vais pas forcément me soucier de la scalabilité tout de suite
parce que des fois ça ajoute une complexité que je n'ai pas envie de tu porter.
Par contre je suis sûr que si je l'anticipe bien faire ne coûte pas forcément plus cher
dès le début et tu m'as parlé des douze facteurs et je trouvais ça intéressant.
Est-ce que tu peux nous en dire plus sur ces douze facteurs ?
Oui en fait pour passer à l'échelle souvent on utilise le cloud et donc on ne va pas envoyer
notre code sur un seul serveur mais sur une ferme de serveur et ces serveurs sont des serveurs
jetables. Ça permet justement de pouvoir augmenter de manière horizontale la capacité de l'application
et pour ça on est fait en suivi douze facteurs et notamment l'un des facteurs les plus
intéressants et obligatoires pour justement passer à l'échelle c'est que le code doit être
jetable et sans état c'est à dire que le code en lui même doit pouvoir tourner sans stocker
d'informations sur le serveur sur lequel il est exécuté.
C'est vraiment le point c'est vraiment si quand tu regardes les projets des développeurs que tu
accompagnes c'est vraiment le point qui ressort en premier lieu à chaque fois quand il y a une
question de scalabilité ? Moi c'est le point sur lequel j'insiste le plus parce que une application
avec état on gros si on stock des fichiers sur un des serveurs avec le serveur plante ou est jeté
par le data center parce qu'il est corrompu on va perdre les données donc ça on ne peut pas perdre
les données c'est pas possible il faut les stocker dans une base de données ou dans un service de
gestion de session ou quoi que ce soit mais c'est vraiment le point le plus important pour moi.
Ok donc c'est vraiment cette idée qu'un serveur doit être jetable, pouvoir être up ou down facilement
Là tu parles du serveur d'application. Je parle du serveur physique mais ça peut être le serveur
physique pour moi le serveur physique ou le conteneur dans lequel s'exécute l'application
puisque de plus en plus on va vers les conteneurs. Et c'est quoi du coup les autres les autres bonnes
pratiques que tu recommandes ? Si on suit les 12 facteurs une bonne pratique c'est déjà héberger
son code sur un gestionnaire de code donc souvent guide d'explicitement nommé et le nom et les
versions des dépendances logicielles notamment quand on utilise rubis les gemmes avec leur version
pas juste le nom de la gemme parce que en fait à chaque fois qu'on va réinstaller ou déployer
l'application on n'est pas sûr du numéro de la dernière version donc on sait pas si le code
va être compatible avec la dernière version de la gemme par exemple. Le troisième facteur c'est
la configuration si on doit configurer quelque chose dans l'application on doit pas le faire dans le
code on doit utiliser les variables d'environnement qui sont fournis par le serveur puisque ça
ça va être embarqué d'une autre manière en fait ça va être déployé et configuré
au moment du déploiement mais le code en lui même ne doit pas contenir la configuration. Pareil si on
fait appel des services externes on ne doit pas hardcoder évidemment les accès aux services
externes et se baser sur la configuration et tout ce qui est justement build, relize et déploiement
ne doit pas non plus être sur le même dépôt on doit bien séparer les choses l'application
d'un côté les dépôts de déploiement de l'autre. C'est quoi que t'appelles les dépôts de
déploiement ? Par exemple mon code il est hébergé dans un dépôt dans un dépôt guide et il ne peut
être mélangé au code de l'application sinon après il peut être embarqué sur les serveurs et on
peut avoir des informations qu'on voudrait pas voir apparaître sur les serveurs par exemple.
Après pour moi les autres facteurs si je suis encore les tous facteurs on a les processus
donc l'application doit tourner de trois l'application ne doit être qu'un seul processus au sens
au sens un service on est beaucoup dans des architectures microservice dans le cloud sinon si on
a une application monolithique on va avoir du mal à passer à l'échelle donc vraiment une application
un service un processus et une fonction une grosse fonction une petite fonction mais une fonction on
va pas mélanger par exemple la gestion des utilisateurs de la gestion des mails dans des très
grosses applications. Quand tu dis grosses on parle de volumétrie on est d'accord ? Oui on parle
de volumétrie et d'applications qui gère plusieurs millions d'utilisateurs. C'est vrai que moi je
suis plutôt dans le spectre des projets que j'accompagne je suis plutôt dans la phase
démarrage initial c'est vrai qu'il y a finalement malheureusement la loi des 90 % de taux de perte
s'applique là aussi donc il y a finalement assez peu de clients qui atteignent la phase où ils explosent
puis quand ils explosent en général ils recrutent leur équipe interne donc c'est vrai que c'est pas
forcément des problématiques que je vois tous les jours. J'ai pu voir dans des vies passées mais
plus tellement depuis que j'accompagne des projets et c'est vrai que moi du coup dans les phases
initiales je suis plutôt partisan d'une approche monolithe parce qu'on se simplifie quand même
énormément les choses si on commence à partir sur des microservice avant de savoir ce qui a
besoin d'être optimisé je trouve que ça ajoute une complexité et un coût qui est hyper lourd
puis je sais pas ce que t'en penses, je suis curieux de ton avis. Non tu es tout à fait
raison dans la phase de prototype on va dire de toute façon on ne va pas héberger notre code sur
des fermes de serveurs on va vraiment utiliser les passes ou un seul serveur sur lequel on va tout
installer et c'est pas le moment en fait de penser l'application pour des contraintes de
performance par contre quand la start-up ou l'application va devoir adresser plusieurs milliers
de clients là il va falloir se poser des questions de performance de comment est-ce qu'on va
architectureer l'application pour justement pouvoir pouvoir la rendre plus veloce et pouvoir
la rendre élastique sur chacun des composants. Oui et là on commence à parler microservice.
Exactement mais au début en effet c'est pas le bon moment c'est le moment de faire de faire
tourner l'application et d'avoir des utilisateurs. Ok si on continue dans les recommandations des
12 facteurs où est-ce qu'on en est ? Alors il y en a quelques-uns que moi je suis pas forcément
donc l'association des ports c'est en gros un service égal à un port mais comme je suis plutôt
en microservice donc chaque service peut avoir le même port c'est pas gênant mais si on était
sur un seul serveur en effet il faudrait séparer les ports du serveur par service.
L'agéton de la concurrence parce que évidemment quand on a plusieurs versions de l'application
qui tourne il faut que chaque version de l'application qui tourne doit pouvoir gérer la concurrence
si on ajoute un utilisateur avec une version de l'application et qu'un autre utilisateur arrive
et qu'une autre version de l'application vient inscrire l'utilateur si la concurrence est pas
gérée il y aura collision. Je sais pas si j'étais très clair sur ce point là. Oui ce que j'entends c'est
que sur les ressources qui sont ce que j'ai compris c'est que quand il y a plusieurs instances de la
même application il faut s'assurer que deux instances qui tapent sur des ressources les mêmes
ressources en même temps et que ça gère la concurrence en fait. Oui c'est tout à fait ça.
Ok cool j'ai bien compris alors. Je t'ai parlé du côté jetable de l'application,
celui là c'est vraiment le plus important. La parité DEV PROD en gros les environnements
d'éploiement et de production doivent être les plus proches possibles là. Je pense que
t'as déjà entendu ou dit mais ça marche sur ma machine alors que ça marche pas en production.
C'est souvent parce qu'il y a soit des systèmes qui sont différents soit des versions de
package installées qui sont différents et du coup garder un environnement de dev qui est
extrêmement proche de la production c'est très important. C'est pour ça que moi je conseille
vraiment les développeurs de développer à l'intérieur même de conteneurs dockers et pas d'exécuter
leurs codes sur leur machine. C'est vrai que nous on n'a pas trop de soucis là parce que on a eu assez
peu de surprises il y a des différences. C'est vrai que Ruby et surtout Rails nous
prémuliez déjà de pas mal de choses parce qu'avec le bundler ils gèrent toutes les problèmes
de version tout ça donc on a déjà très très peu de surprises. Et finalement moi je fais très
attention à ce que staging soit vraiment une copie hyper proche de prod, voir c'est la même chose.
A quelques détails près quand même parce qu'en staging tu veux pas forcément les emails pour
devraient, que les sms pour devraient des petits trucs comme ça mais c'est vrai que moi j'ai trouvé
que la complexité de devoir gérer son docker sur sa machine ou alors c'est peut-être juste parce
que je sais pas faire mais fabriquer l'image tout ça était apporter plus d'inconvénients que les
quelques fois où j'ai eu des surprises entre dev et staging vu qu'on utilise les mêmes moteurs de
base de données et qu'on garde encore une fois des applis assez monolithiques avec peu de
peu de dépendance externe on a très rarement eu des surprises quoi. C'est vrai que je suis en dev
je suis plutôt sur en machine locale par contre effectivement staging je garde un staging très
très proche de la prod mais même là on voit qu'il y a encore des surprises en ce moment je bosse sur
un projet de santé ça veut dire qu'on n'a pas le droit d'accéder aux données pures à l'ensemble des
données de production. C'est compliqué puisque tu n'as pas le droit de copier le jeu de données
en staging sans cette contrainte c'était assez simple avant déplement copier les données en staging
on vérifier si tout fonctionnait. Là on peut pas là faut limiter les surprises jusqu'au bout
et c'est pas simple tout le jour et des fois il y a des surprises qui passent. Non alors en effet
alors dans ces cas là j'ai bossé dans le milieu broncaire pas dans le milieu de la santé mais dans
le milieu broncaire on a pareil des contraintes de sécurité. Ah oui j'imagine que tu n'avais pas accès à la prod.
Bah si parce que je suis hopp donc du coup j'avais accès à la production mais avec les devs avec
lesquels je travaillais elles n'avaient pas accès aux données. Les devs n'avaient pas accès à la prod.
Et ce qu'on peut faire dans ces cas là non il ne faut mieux pas ou alors faut qu'ils savent
faut vraiment qu'ils savent ce qu'ils vont faire mais bon ça ne s'est jamais arrivé. Ce qu'on peut
faire dans ce cas là c'est extraire une base de données et l'anonymiser il y a des solutions
pour ça on peut anonymiser les données donc garder juste des informations ou même des informations
différentes qui ne sont pas reconnaissables en fait par les devs. Ça c'est une possibilité. Ah oui
c'est dire un nom et un prénom tu les offures tu remplaces des prénoms par d'autres prénoms
des trucs comme ça. Oui et on peut aller très loin on peut même enfin tout type de données peut être
changées. Ah oui c'est intéressant ça tiens j'y avais pas pensé mais ça demande du travail c'est
encore. Oui ça demande du travail. C'est pas gratuit quoi il faut faire l'effort de à chaque fois
d'analyser quelles sont les données quels sont les données sensibles et de faire en conséquence quoi.
Exactement après c'est comme tout il y a des outils d'automatisation qui permettent de faire ça.
Donc il suffit de le coder une fois l'anonymisation et après on peut le rejouer et on peut même
alimenter des bases de devs en continu comme ça. Très très très intéressant je pense que je vais
te piquer l'idée pour mon projet là. Bah c'est possible là. Ah bah si on va continuer dans les
12 facteurs il reste deux maintenant donc l'avant dernier qui est les logs donc il faut traiter les
logs comme des flux d'événement. Oui dans la même logique il ne faut pas que chaque serveur et son
propre système de logs quoi. Oui exactement et ce qu'on peut mettre en place souvent c'est une
centralisation des logs c'est à dire qu'en gros on va récupérer les logs et on va les stocker sur
un autre service en fait. Et donc le dernier qui est en fait les processus d'administration doit
être des processus one off. Ça veut dire ça en gros c'est quand on met à jour une application on a
souvent un mettre à jour la base de données c'est le cas le plus courant on fait des migrations.
Donc pour ça comme on a plusieurs serveurs sur lesquels on doit déployer notre code on va
déployer le code et on va lancer les migrations sur tous les serveurs mais sauf qu'on ne peut pas se
permettre que tous les serveurs ont des migrations sur la base de données. Donc c'est ça en fait un
seul des serveurs doit lancer les migrations et les autres doivent savoir qu'il y en a un qui lance
qui lance les tâches de migration qu'on utilise des semaphores ou n'importe quoi pour qu'on ait
un seul une seule tâche d'administration à la fois. Oui ça serait fâcheux qu'il y ait des migrations
complémentaires avec des transactions lancées tout ça risque d'être un jeu bizarre quand même.
En effet ça j'insiste aussi avec les devs pour que justement comme c'est eux qui sont responsables
de l'immigration et souvent c'est eux qui sont responsables de la tâche de l'ansom de migration
qui gère ça justement le fait qu'il y aura plusieurs serveurs qui vont lancer l'immigration
en même temps. Ok bah écoute merci Christophe je te propose que ce soit le mot de la fin si tu
veux en savoir plus cher auditeur va sur 12factor.net 12factor.net Christophe si on veut en savoir un
peu plus sur ton travail où est-ce qu'on vient ? Et bah il suffit de venir sur notre site parce
qu'on est plusieurs et donc le nom de site c'est Lydra.fr et Lydra.fr. Super je te remercie
d'être venu Christophe. Et bah merci de me voir invité. Quand t'as toi cher auditeur je te remercie
pour ton attention j'espère que ce podcast t'a plu si c'est le cas vient vite t'abonner sur
artisandeveloper.fr si ce n'est pas déjà fait et je te dis à demain.