Début décembre, appel en catastrophe d’un client d’ami : leur site est hébergé par un prestataire qui ne gère plus le serveur, qui est une boîte noire et qui sature totalement. Nous ne connaissons ni le code ni l’infrastructure à ce moment-là.
Ce sera donc une opération coup de poing comme je les chéris : la situation initiale étant totalement insatisfaisante, je ne peux que faire mieux, je vais pouvoir aller vite sans trop de craintes. Mode pompier.
Cette conférence permettra de montrer le passage d’une archi classique à une archi cloud, à pas cher, en montrant tous les aléas rencontrés lors de cette migration. Ce sera l’occasion de balayer pas mal d'idées reçues sur le cloud et les performances.
_ Bonjour à toutes et à tous. Déjà, je remercie le programme de m'avoir mis entre la documentation et le monitoring. On va parler de ça pendant toute la conférence. C'est parfait.
On va faire un retour d'expérience. C'est un récit. On va parler de plein de points que je ne pourrais pas pousser très loin, mais on en reparlera.
Le projet sur lequel on va partir, c'est l'exemple parfait du POC, le projet que l'on fait à l'arrache pour satisfaire les investisseurs et les développeurs qui fonctionne. On a fait un truc. Il y a de la complexité qui arrive avec beaucoup de données. Il a besoin de sortir des features et des utilisateurs qui font des retours. Quand ce n'est pas fait pour que l'on n'a pas le temps de faire bien les choses, on a des veilles techniques à maintenir et au bout d'un moment, on n'est pas motivé.
Sur ce projet, c'est des nuits blanches entières qui sont passées. C'est un truc qui est né aux États-Unis. Niveau horaire, ce n'est pas parfait. Il y a plein de problèmes. Donc une nouvelle équipe arrive et on fait appel à moi pour la partie performance. Je suis Bastien et j'aime bien, dès que c'est un peu complexe, on m'appelle pour ça. Je suis le pompier du code.
On s'adresse à ceux qui ont un serveur dédié et qui ont peut-être des problèmes pour le mettre à jour ou le maintenir à jour, pour créer de nouveaux environnements, des gens qui veulent scaler leur infrastructure alors que leurs serveurs ne le permettent pas.
Tous ceux qui ont des infrastructures un peu plus sérieuses et qui ont déjà eu ces problèmes, vous allez voir que c'est une bonne histoire.
Quand on développe un site en PHP, ça peut être n'importe quoi, une des questions que l'on se pose, c'est combien ça va coûter ? On va vous demander quelle version de PHP, quelle version MySQL et qu'est-ce que vous voulez comme CPU et RAM ou espace disque alors que par défaut, votre site n'est pas en ligne que vous ne savez pas encore comment le site comporte et vous ne savez rien. Vous devez faire un choix très en amont.
Ce que l'on ne va pas vous demander, c'est comment on va gérer les mises à jour de sécurité, les déploiements, comment on va passer de PHP 7 à PHP 8.
Il y a plein de choses que l'on ne vous pose pas et vous allez morfler plus tard si votre site a le malheur de fonctionner correctement.
Moi, je récupère quelque chose qui fonctionne trop bien et qui a des problèmes de charge. On se sépare et je dois demander de pouvoir mettre SSH. On a zéro documentation, c'est pour les faibles. Script custom, il n'y a pas de log, il n'y a pas de APM. On me dit que c'est lent.
La phrase cachée qui dit que j'ai mal géré les transcriptrices, c'est qu'on ne va surtout pas toucher à ces serveurs... On le laisse. On ne peut rien faire dessus. Heureusement, on est plutôt content côté code : il y a un back office, il y a un front office, une API, il y a un truc un peu bizarre.
L'architecture du code, pour l'API et BO, c'est le legacy.
C'est très lent. Le front, il est nickel, mais il a un énorme cache de fichiers. Les applications mobiles ne bénéficient pas du cache et je dois recalculer plusieurs fois la même chose. Et la notion de performance n'a pas du tout été pris en compte. Ce sont des gens qui ont patché au fur et à mesure pour essayer d'apprendre en continu. Il y a beaucoup de conférences sur le cache. C'est génial. C'est l'interface entre le client et le site PHP. Ça répond et ça consomme zéro CPU. En gros, à part la bande passante, ça ne coûte rien. J'ai fait un très gros billet sur le sujet sur Symfony.
Ce que l'on va faire, c'est que l'on va vouloir proxyfier l'API. On va commencer par ça. On va mettre quelque part un proxy ailleurs. Encore une fois, nous n'avons aucune idée de comment ça va se comporter. Est-ce qu'il faut une grosse ou une petite machine ? On fait le choix de ne pas faire de choix. Le trafic n'est pas lisse. L'intérêt d'être un pompier, c'est qu'on peut prendre des raccourcis. Le site tombe tout le temps. Ce n'est pas grave si je le casse. Sur site, il faut gérer les propres serveurs.
Le modèle IaaS, c'est votre serveur dédié sur lequel vous installez le système d'exploitation, et tout ce que vous voulez. Et le modèle PaaS, c'est ce que l'on va voir. C'est le contrat avec les applications et les données.
On va utiliser Clever Cloud parce qu'ils ont parlé de mon article pour dire que c'était super. Retour sur investissement, et surtout, leur instance par défaut. C'est pratique pour moi. Je veux une application PHP, je veux une base de données. On les met ensemble. Tout se configure.
Vous verrez que je n'aime pas les interfaces graphiques. On ne va faire que des lignes de commande. Une ligne de commande... À puissance égale, le coût du serveur par rapport aux serveurs dédiés est monstrueux.
On va utiliser ça. Ce n'est pas lisse. Par défaut, il y a une petite instance. Quand il y a des pics, ça monte. Du coup, infrastructures sur Clever Cloud. Je ne sais pas si la vélotypie me suit. Je parle un peu vite. Je m'en excuse.
Je discute avec l'administrateur système. C'est pénible. On fait en sorte que le client possède tous les comptes. Moi, je n'ai rien. On me délègue les actions. Il y aura une conférence sur le sujet derrière sur les applications et leur configuration. Quand on crée un DNS, tout le monde oublie le point derrière et ça casse. On commence par le proxy.
Très simple, on veut mettre un proxy. Varnish va discuter avec l'API derrière. On crée un dossier. Il faut savoir que Varnish se configure avec un outil qui est atroce. Je vous évite le code. C'est standard, on le retrouve partout. La partie pour créer une application est très complexe. Voilà ce que l'on fait. Clever Open, c'est parce que je suis feignant et il m'a généré ça. Pas de chance. Je ne veux pas faire du VSL* et je vais devoir faire du script autrement, j'ai dégagé tout ça. On ne laisse pas l'instance tournée. Proxy en PHP. Ce n'est pas du tout performant. On part d'un API qui met minimum 300 secondes.
On dit qu'on veut PHP 8. C'est une variable d'environnement. Ça ne marche pas. Sous le capot, c'est un Apache. Symfony a un package pour fournir cet outil. Cette fois, on déploie une application en deux minutes. Parfait. Je coûte cher à l'heure, mais pour l'instant, je n'ai pas coûté cher. On va faire une action très simple. Ça cache n'importe quoi. Je vous évite la configuration qui prend les paramètres d'entrée, qui les renvoie.
On rajoute de la logique derrière. C'est un test. Le but est de savoir ce qu'il se passe à travers. Il faut monitorer. Pour le configurer, on ne fait rien et ça marche. On est en 2021. Novembre 2021 pour PHP 8.1. La sortie se fait en février et on est en décembre. C'est mort.
Je m'étais trompé. Je leur ai dit qu'il fallait le mettre en 8. Facile, on change la variable d'environnement. Pas de conflit. On redémarre et c'est tranquille. Au passage, je vous rappelle qu'il faut tester. Tester, c'est douter. Je doute de tout et donc je teste. Ça casse ! Pourquoi ? On ajoute deux headers qui permettent de dire à notre application que Varnish doit mettre en cache. Il faut mettre toutes les réponses pendant une heure en cache.
Vous avez remarqué qu'on n'a rien fait pour builder, normalement, on est censé écrire pour dire qu'il va falloir un endroit faire composer install et créer des fichiers d'environnement et tout ça. Là, non. Ça s'occupe de tout. Ça s'installe.
Au final, si vous connaissez un peu le monitoring dans l'APM, ça regroupe par action de contrôleur. Du coup, il n'y a qu'une seule action qui fait tout. On triche. On lui dit de prendre le chemin de l'URL pour créer la transaction. On est plusieurs clients. Du coup, j'ai rajouté dans le truc le même endpoint qui est appelé par deux clients différents. Ce sera bien. On verra après que de toute façon, le code dépend du client.
Là, ce sont des graphs que j'ai fait récemment. Il n'y a pas de trucs totalement débiles. Une action principale regroupe plusieurs pour cent. Il y a une table qui représente 44 %. Ce n'est pas celle qu'il faut optimiser. Cela représente 86 % de la logique. On peut dire aux applications clients d'utiliser le proxy. On est tranquille. Il suffit de changer l'URL.
Là, j'avais plein de slides plus compliqués. Je fais vite. Dans Varnish, je me rends compte qu'il n'est pas si rapide que ça. Je ne l'ai pas dit, mais sur le serveur legacy, il y avait 300 Gigas et là, mon petit scanner, il a un giga de cache. Il se fait avoir dans tous les sens. C'est une stratégie de LRU, il prend les plus anciennes réponses et il les dégage. Il passe son temps à dégager les trucs ici parce que je n'ai pas assez de place.
Je tente de prendre une plus grosse instance. Je me dis que c'est lié à la mémoire, mais ce n'est pas le cas. Je discute avec eux. 1 giga de cache, c'est un peu léger. On me donne une variable d'environnement. Entre-temps, je me suis dit que 13 Gigas allaient bien. Les réponses sont bien stockées dans les 13 Gigas, mais les métadonnées sont également en mémoire. Je dois augmenter la mémoire. Ce sont quand même des réponses que je n'avais pas en amont. J'ai pu tester empiriquement. J'arrive au résultat assez facilement tout cela deux heures du matin, parce que je fais d'autres choses à ce moment-là et que j'ai des enfants qui me prennent beaucoup de temps.
On peut passer au front. La cible, elle est Clever Cloud. Sur le repository existe déjà. Je clone, je crée l'application, je configure les variables d'environnement. On rajoute le bon Symfony patch.
J'essaie de configurer et je me rends compte que le menu met deux minutes à générer. Cela fait appel à beaucoup trop de données. Je pourrais me dire que je vais optimiser ce truc, mais Varnish utilise des morceaux de fragments pour dire que le composant est une requête à Paris qu'il faut la mettre en cache. Donc, je remplace l'appel au menu par un truc comme ça. je les dégage. En face, je crée une action de contrôleur et derrière, ce truc, ce sera comment sur toutes les pages. Au lieu de prendre deux minutes tout le temps sur toutes les pages, ça prendra deux minutes une fois et ce sera fini. Grâce à Varnish, les prochains calculs seront asynchrones parce qu'il fournira la version expirée le temps qu'il demande à Asynchrone de recalculer. Ça recalcule le tout une seule fois et on verra plus tard. Quand on fait des missions de pompiers comme ça, je sais qu'il y a un problème, et on passe sur la chose d'après. Le DNS, on a la main dessus.
Quand j'avais recetté, il se trouve que les médias étaient avec l'URL complète. Je n'ai pas capté qu'il fallait régénérer une fois que j'avais basculé le domaine. Ça a pété. On pourrait se dire qu'on fait proprement, qu'on déplace les fichiers, etc.
Il se trouve que j'ai développé un proxy, il n'y a pas longtemps. Je reprends ma logique de proxy. Je la mets. Le but n'était pas de faire un truc propre aujourd'hui. Cette fois, c'est bon. Je laisse quelqu'un de l'équipe livrer les fichiers. J'ai d'autres choses à faire.
Je passe sur la suite. API et PO. On a un proxy. Le proxy, on peut le programmer. On peut faire des choses. On peut lui dire qu'on va monter un autre cluster à côté avec l'API et la base de données pour voir comment elle se comporte. Ça permet de tester pas cher ce qu'il se passe. Vous connaissez le topo. Nous ne sommes pas en Symfony. Du coup, il faut ajouter ht access.
On est tranquille. Là, je me rends compte que les performances SQL sont cataclysmiques. C'est incroyable. Il y a de la latence, il y a de la bande passante, etc. Ce n'est pas ça. J'enquête. Effectivement, j'arrive à un résultat. C'est certainement une logique de requête. Il y a le query cache dans mysql. Je l'ignorais, dans MySQL 8, ils ont supprimé le query cache. Qui le sait ? Il y a quand même trois personnes.
Du coup, je me suis retrouvé avec un code qui n'était pas bon et qui faisait des boucles. C'était masqué par le MySQL. Là, on reprend notre administrateur système, on lui dit qu'on lui avait demandé la version huit. Finalement, il me faudra autre chose. Du coup, il ne m'aime pas. C'est pour ça que je ne leur parle pas. On arrive comme ça. On dit au revoir au serveur dédié et c'est bon. Les notions de serveurs et de fichiers codés, on s'en fout.
Dans les bugs marrants, on avait d'énormes pics de base de données. Un truc de malade. Il fallait regarder et le monitoring de back office. Attention. Un contributeur ouvrait 40 onglets en même temps. Ça chargeait la page d'accueil du back office 40 fois, sauf qu'il y avait d'énormes requêtes SQL. Cela met à plat toute la base de données. Ça ne marchait pas. Et du coup, j'essaye encore. Il y a 220 qui sont ouverts. Il n'y a plus de bases de données. Donc j'ai ajouté un favicon.
Au passage, vous ne l'auriez jamais inventé si vous n'aviez pas d'APM. Après, il faut regarder bon endroit pour l'APM. On a le premier, le crash. On reprend. Deuxième, on recommence. Troisième, on optimise deux ou trois trucs. Le 4, API en production. Problème avec MySQL. On le fixe. Ensuite, je suis en vacances. Il ne se passe rien. On est moins bon qu'avant. On a des machines à sept euros et d'autres plus. 5, retour de vacances. 6, il ne se passe rien. J'adore. On est tranquille.
On a parlé de documentation. Il y a plein de choses dont on n'a pas forcément besoin au début d'application et dont on a besoin après-coup. Notamment, les... Je vais être en avance...
Notamment la gestion des fichiers contribués. Il y a deux manières de faire. On est dans le cloud, les machines meurent. Elles vont mourir. On va utiliser les machines des autres. On ne peut pas stocker sur la machine comme on le faisait avant. Il y a deux manières dans le cloud de stocker les fichiers. Soit il y a le S3 ou le NFS. Un dossier sur le serveur. On utilise fsbucket. C'est une ligne.
La gestion des mails, cloud, toujours. Les mails sont bloqués. Sinon, on prendrait beaucoup de spams. On a le moyen de configurer via l'environnement le SMTP distant, mais ça ne marche pas.
Cette histoire est fausse. Ce sont trois histoires mélangées. C'est un problème récent.
Crontab, la gestion, je passe. Gestion des workers, c'est documenté. La gestion des logs, aussi. Je n'ai pas besoin de mettre en place des choses sur mon nouveau serveur en disant qu'il faudra que je forme. Je m'en fous. Il faut lire la documentation. En plus, elle est bien écrite.
Ça, c'est la dédicace à ceux qui font de la doc. On peut pendant le déploiement, avant et après le build, on peut agir, avant le lancement et après le lancement. On peut se crypter. Soit on met la commande directement, soit on met un fichier. Ça marche très bien. On peut même faire du rust. Ça marche très bien.
PHP 8.1 est sorti. Je vais être super en avance. N'importe quoi. L'intérêt, c'est que l'application, on parle d'API, ce n'est pas fait pour fonctionner avec MySQL 8. Quand il a été écrit, c'était une abstraction. Donc ce n'est pas compatible. On était dans le rush, est la priorité, c'était les fonctionnalités et la performance. Forcément, techniquement, il n'y a pas de qualité de mise en place pour avoir des codes. C'est compliqué, mine de rien, de prendre du code legacy qui n'utilise rien. MySQL a disparu, il y a plein de complexité à mettre en place pour ce genre de choses. On peut le faire sans stress, et on peut le prouver. On met les deux applications côte à côte. Si vous foirez la requête MySQL, vous pouvez avoir de vrais problèmes. C'était une base de données différente. Ça fonctionnait pareil. Le proxy cache, il y a une notion cool dans l'impossibilité. Le passage de 7.4 à 8.1 est très stressante de manière générale. Il y a de la manipulation de données en plus. Et il y a un truc très nu, "division by zero error". Je ne sais pas qui a déjà eu cette erreur-là. Ça peut arriver dans n'importe quelle page et n'importe quelle ligne du code. C'était horrible. C'était beaucoup trop long et beaucoup trop pénible.
Apparemment, j'ai du temps. Je rajoute une histoire. Qu'est-ce que je voulais dire ? Non, je raconterai plus tard. Pour le déploiement, avant, on se connectait en SSH en demandant à quelqu'un que l'on n'aime pas de déclarer notre clé SSH.
Tu lances une commande inconnue. Tu ne sais pas où aller et ce qu'elle fait. Tu ne sais pas pourquoi le site a été coupé avant et il va être remonté après. Après, on fait un clever deploy. Il va builder. Peu importe.
On prend la grosse machine. Quand c'est prêt, on enregistre dans un endroit et il n'y aura plus qu'à prendre ça qui traîne quelque part, on le prend et ça lance avec.
Ce sont des trucs compliqués à mettre en place. Faire un vrai déploiement, c'est compliqué. Là, c'est documenté. Au niveau vertical, soit on prend une grosse machine, soit on augmente le nombre. J'ai choisi d'augmenter le nombre. Comme j'ai du cache je n'ai pas envie de repartir à zéro à chaque fois. Le proxy cache, on ne le scale pas. Il ne fait rien. On a des problèmes de mémoire. On a pris une instance plus grosse. Sur AWS, on prendrait une machine plutôt mémoire.
Là, on scale les fronts et les API. Les API ne font plus grand-chose. Vous avez sur l'étagère quelque chose qui fonctionne pour vous jouer aux Lego pour faire ce que vous pouvez. Il y a des choses qui sont plus difficiles que d'autres. Pour ce projet, je savais que ça allait rentrer parfaitement à l'avance. Après, il faut demander au support. Je ne connais même pas le prix. Là, il faut demander au support. Ils le font. Ça peut arriver. J'ai vu un souci sur MySQL. Encore une très bonne histoire. Il fallait une requête mysql qui utilise la time zone, mais MySQL n'a pas de time zone. Ils ont pu l'activer. J'espère qu'ils ont laissé ça derrière. Pour la réplication SQL, il faut demander au support. La boîte n'est pas toute jeune, mais elle est en train de grossir. Ils ajoutent des features. Datadog, c'est génial.
Il y a un truc qui s'appelle Elastic APM. Il y a un des sponsors de la conférence. Normalement, on le met dans le serveur Web, mais là, ce n'est pas possible. Ils sont en train de le faire. Il y a évidemment moyen en mettant un proxy. J'en ai fait part, des proxy. Et ils ont fait un truc aux US. Il a tout fallu passer sur Montréal.
Dans un autre truc moins cool, il n'y a pas de support http 2 par défaut. En 2014...
Il n'y a pas de réseau privé. Ça arrive. Je n'ai pas de problème sur l'application. Tout est public par défaut. Il n'y a pas de healthcheck applicatifs. Il vont tuer l'instance si le process ne répond pas.
J'ai un problème de DNS. On a mis en place quelque chose et il ne l'a pas tué. J'ai fait du lobbying.
Et pour la dernière ligne, c'est de l'opinion. En rétrospective, j'ai fait zéro administration système. Techniquement, ce n'est pas du haut niveau. C'est l'assemblage de briques. J'ai eu des problèmes de version de MySQL. Les problèmes de PHP aussi. On a pu rajouter des Workers, on a pu accéder au log. On avait une vision parfaite de l'application sans en discuter avec qui que ce soit. Vous êtes peut-être pas en mesure de faire tout ce que vous voulez, mais vous pouvez faire tellement de choses et tellement plus vite, qu'il y a quand même un intérêt. Une fois que vous connaissez bien l'application, vous pouvez vous dire qu'une fois que ça fonctionne et comment rationaliser des coûts et aller sur un projet dédié ? Pour un projet qui démarre, jamais de la vie, j'utiliserai un serveur dédié. C'est impossible.
Tu peux faire tout ce que tu viens, tu n'as pas besoin d'avoir les réponses. C'est assez marrant, quand tu n'as pas la connaissance, que tu dois faire un truc qui t'engage, alors que quand tu connais, on fait un truc et on verra plus tard. Ça marche trop bien. C'est vraiment cool.
Au final, je rappelle que j'aime intervenir sur des trucs intéressants. Pas faire des features. L'intérêt était vraiment de dire que je veux vous sortir de la situation et en même temps, je n'ai pas envie que vous soyez dépendant de moi. Le contrat est rempli. Ils ont la main sur tout. Vous regardez le nombre d'applications. Quel est le contrat de l'application ? Quelles sont les variables d'environnement ? Tu vois les variables d'environnement. Tu regardes dans le code pour savoir ce que c'est. Pour le coup, l'infrastructure est autodocumentée. Pour toutes les fonctionnalités un peu complexes, dans tous les cas, il y a la documentation que vous n'avez pas à écrire. Surtout ce qui est infra, il n'y a plus de problème.
Au final, c'est simple et ennuyeux, mais c'est très bien, l'ennuyeux. On n'a pas besoin de mettre tout en place. On aurait pu utiliser Kubernetes, on aurait pu faire plein de choses, mais là, ce n'est rien. L'application et l'environnement parlent ensemble. Je n'ai pas de docker, par exemple. Alors que sur un serveur, il y en a. Ce sont des trucs stables qui fonctionnent. On a pu avoir de l'agilité. Le client virtuel, puisque c'est un faux projet, qui arrive et qui nous dit qu'il ne pouvait plus espérer croître parce que l'infrastructure tombée, là, il fait plus de 70 %.
Je ne suis pas... Je m'en fous du PaaS. Je n'ai rien offert là-dessus. Ce que j'ai cherché dans cette histoire et dans tout ce projet, c'est l'agilité et l'observabilité. Je voulais l'agilité pour tester quelque chose. Je voulais regarder comment ça se comportait et avec l'agilité, j'ai pu itérer en fonction. Je n'ai presque jamais parlé à un humain pour travailler là-dessus. Tout ce que j'ai fait, je l'ai fait dans mon coin. Ça a marché. Je l'ai fait à mon rythme et sans avoir de réunion.
En conclusion, on a une architecture moins chère, scalable et évolutive, c'est faux. Elle est plus chère, mais elle fonctionne. Il y a quelque chose de très important dans ce que l'on fait, le coût d'opportunité. On ne payait que 100 au lieu de 200 maintenant, mais on ne pouvait pas gagner d'argent. Donc on a économisé 100 €, mais on perd la possibilité d'en gagner. Ça, c'est le coût d'opportunité. C'est débile quand on est une start-up n'importe quoi. Pourquoi se mettre des bâtons dans les roues ? Ensuite, on a tout standardisé sans code custom. La documentation est portée par quelqu'un d'autre. C'est parfait. Si vous avez besoin d'écrire de la documentation, c'est qu'il y a un problème à la base. Là, il n'y a rien à comprendre.
On a le côté cloisonnement d'applications sans avoir de containers ou de machines virtuelles. Pas d'OS, rien. Ils sont à fond sur les trous de sécurité. Le moindre patch qui est sorti, il le faut. Ils vont prendre les choses et les tuer. C'est fait par défaut. Ils s'en occupent pour vous. Sur votre dédit, vous ne le faites pas. Vous êtes en train de développer de la feature mapping et non pas de mettre à jour.
Un truc que je regrette quand même, c'est pourquoi avoir attendu que tout le monde soit noyé pour faire appel à la cavalerie ? Ma prestation n'a coûté rien du tout. J'ai été gratuit sur cette mission. J'ai été une source de revenus. J'ai dépanné quelque chose qui permet d'avancer et de ne plus avoir de problème. À des moments, c'est bien de vouloir prendre soi-même, mais à un moment donné, dans les décisions, là, on a fait un proxy par l'extérieur et peut-être que je dirais l'inverse. Ça dépend de la problématique de la situation. Vous êtes sur AWS et je vais dire que vous avez une superbe infra scalable et que ça ne sert à rien. Et cette conférence a mis plus de temps à être préparée que la migration. Donc ce n'est pas très efficace de faire une conférence. Pour des commentaires, vous avez deux sites où vous pouvez mettre que j'ai parlé trop vite. Je m'appelle Bastien de Jolicode et je vous remercie de m'avoir écouté. J'espère que vous avez appris deux ou trois trucs. Et je crois que j'ai géré le temps. On va même avoir le temps pour les questions.
_ On a le temps pour une ou deux questions.
_ Sinon, j'ai plein de choses à dire. Notamment la validation du cache. Je vais écrire un article plus complet qui vous donnera mal à la tête. Ce sera sur le bloc de Jolicode. Il y a plein d'informations plus notamment la validation du cache sur le fond et l'API. Il y a des problématiques intéressantes.
_ Merci pour la présentation. Je voulais savoir, tu as choisi Clever Cloud. Tu as benchmarké d'autres solutions ? Ou pas ?
_ Jolicode, nous avons plein de projets. Pas un seul. Nous avons eu l'occasion de tester d'autres choses. En l'occurrence, c'était le besoin. Varnish est intégré sur les serveurs PHP. J'ai voulu utiliser Clever Cloud sur ces projets parce que c'était très approprié. Vous arriveriez certainement à faire la même chose sur PlatformSh. Je pense que c'est plus dans la manière de fonctionner. Là, c'est presque trop. Il y a moyen d'éclairer les variables d'environnement et de faire des choses autrement, mais là, il n'y a pas de problème sur ce projet. Je ne ferai peut-être un projet comme ça quand il y a 300 stagiaires.
_ Merci. On va arrêter là. Vous pouvez profiter de la pause dans la salle où il y a les sponsors de l'autre côté. Merci.
Tweets