Conseils essentiels pour renforcer votre application et votre infrastructure

Transcription de la vidéo

Nous avons utilisé ChatGPT pour améliorer la grammaire et la syntaxe de la transcription.

Greg : Bienvenue sur le flux en direct d'Upsun ! Aujourd'hui, nous allons nous plonger dans quelques conseils essentiels pour s'assurer que les applications, l'infrastructure et tout ce qui est lié à DevOps et au monde du développement sont solides comme le roc, en particulier à l'approche des fêtes de fin d'année.

Certains d'entre nous se disent "Attendez, il est trop tôt pour cela", mais avec 80 degrés Fahrenheit à l'extérieur et des centaines de degrés, on a l'impression qu'il est encore tôt pour les vacances. Je ne connais pas la conversion exacte en degrés Celsius, mais cela correspond probablement à une température de 32 degrés sur cette échelle. Je devrais probablement mettre mon petit chapeau de Père Noël, ou toute autre fête que vous célébrez, parce que la saison approche.

Nous allons nous concentrer sur la stabilité, la façon de gérer les pics de trafic, et plus encore. Il se peut même qu'un invité spécial se joigne à nous pour partager ses histoires d'horreur du vendredi noir, ainsi que quelques conseils. Mais tout cela mis à part, je m'appelle Greg Qualls et je suis un développeur en herbe basé au Texas.

Et avec moi, comme toujours - enfin, parce que c'est la première fois - Thomas est ici. Je suis nul pour prononcer les noms, alors je vais le laisser se présenter.

Thomas : Bonjour, je suis Thomas di Luccio. C'est un nom italien, bien que je sois français. Je suis un défenseur des développeurs et un concepteur-développeur, et je suis très enthousiaste à l'idée de parler de ce sujet aujourd'hui.

Greg : Avant de plonger dans le vif du sujet, nous allons explorer quelques segments différents. Pour ceux qui nous rejoignent pour la première fois, nous allons couvrir plusieurs sujets, en commençant par les nouvelles émergentes.

Tout d'abord, nous allons nous plonger dans le segment des nouvelles émergentes ! J'adore ces petits pare-chocs - merci à Kirby de les avoir fabriqués. Thomas, vous êtes le premier. Qu'est-ce qui fait les gros titres pour vous ?

Thomas : Oui, j'ai lu récemment quelques articles sur l'idée que la bulle de l'IA est peut-être en train d'éclater. Pour être clair, l'IA est là pour rester. C'est une technologie extraordinaire, mais on a le sentiment qu'il est temps de se calmer. De nombreuses startups ont levé des fonds importants simplement en ajoutant l'IA à leur pitch decks.

Greg : Vraiment ? Je n'ai jamais entendu parler de cela. Je veux dire que toute l'IA sur chaque site est 100% authentique et absolument nécessaire, n'est-ce pas ?

Thomas : Exactement. Je veux dire, avons-nous vraiment besoin d'une brosse à dents dotée d'une IA ? Nous entrons peut-être dans la phase où les gens se demandent : "Avons-nous vraiment besoin de cela ?" Il s'agit de trouver comment ajouter de la valeur pour les utilisateurs, et pas seulement d'ajouter de l'IA à un coût énorme.

Greg : Ce qui me fascine dans cette bulle de l'IA, c'est qu'en tant que personne ayant vécu la bulle Internet (même si je n'étais pas très impliqué), il y avait des blagues similaires à l'époque. On disait : " Oh, maintenant tout le monde a un site web. Pourquoi quelqu'un aurait-il besoin d'un site web ?" Puis la bulle a éclaté, mais aujourd'hui, si vous n'avez pas de site web, vous n'avez pas d'entreprise.

Je suis curieux de savoir ce que l'avenir réserve à l'IA. Une fois que le battage médiatique sera retombé, je me demande comment l'IA s'intégrera dans l'écosystème. Dans dix ans, l'IA sera peut-être aussi répandue dans les applications que les sites web le sont aujourd'hui pour les entreprises, mais elle sera utilisée dans le bon contexte, axé sur la productivité et la fonctionnalité.

Thomas : Absolument ! Je pense qu'il pourrait en être de même pour l'IA : après l'engouement initial, elle trouvera sa place. Pour en revenir à la bulle de l'IA, il y a quelque chose qui a attiré mon attention cette semaine : La transition de ChatGPT de Next.js à Remix.js. J'en ai entendu parler partout sur mon fil d'actualité et sur TikTok.

Greg : OpenAI n'a pas directement expliqué les raisons de ce changement, mais d'après ce que j'ai compris, et je suis d'accord avec Wes Bos sur ce point, il semble qu'ils s'éloignent du rendu côté serveur et se concentrent davantage sur le rendu côté client pour rendre les choses plus rapides. C'est intéressant parce que ChatGPT est une application énorme, et faire un changement de framework comme celui-ci est une grosse affaire. Ce qui est impressionnant, c'est qu'en tant qu'utilisateur, la transition s'est faite sans heurt - je ne l'ai même pas remarquée jusqu'à ce que les gens commencent à en parler.

Qu'en pensez-vous, Thomas ? Aurait-il fallu attendre la fin du Black Friday pour procéder à ce changement ?

Thomas : Honnêtement, cette frénésie pour les frameworks me laisse toujours perplexe. Les gens sont tellement passionnés par leurs frameworks préférés qu'ils suivent qui utilise quoi. En tant qu'utilisateur actif de ChatGPT, je ne me soucie pas vraiment du framework qu'ils utilisent, tant qu'il remplit sa fonction. S'ils sont satisfaits du changement, je devrais peut-être passer plus de temps à apprendre comment fonctionne Remix.

Greg : Pour moi, ce qui est fascinant, c'est la spéculation sur les raisons qui les ont poussés à le faire. Parfois, c'est aussi simple que quelqu'un qui l'a essayé pendant le week-end, qui a remarqué que les choses allaient plus vite et qui a décidé de passer à autre chose. Ou peut-être qu'une personne apprécie davantage Remix et a suffisamment d'influence au sein de l'entreprise pour faire en sorte que cela se produise. Il est toujours possible de chercher une raison technique profonde, mais parfois, il s'agit simplement d'une préférence personnelle.

Et avec cela, nous avons couvert les nouvelles émergentes pour aujourd'hui. Nous passons maintenant à notre segment "Stash of the Day", où nous partageons des outils ou des ressources que nous avons trouvés utiles récemment.

C'est moi qui donne le coup d'envoi ! Voici quelque chose d'amusant que j'ai trouvé : un plugin pour Visual Studio Code appelé Indent Rainbow (arc-en-ciel d'indentation). Comme son nom l'indique, il ajoute un arc-en-ciel de couleurs à vos retraits. C'est probablement difficile à voir à l'écran, mais cela rend les retraits plus distincts visuellement. Avec l'âge, il m'est plus difficile de savoir quelle div appartient à quelle section, et ces couleurs me facilitent la tâche. De plus, mon code a l'air heureux !

Thomas : Je l'ai essayé après que vous l'ayez partagé avec nous, et il alimente définitivement mon trouble obsessionnel-compulsif. Si vous avez du mal à garder tout parfaitement aligné, ce plugin va changer la donne, mais il peut aussi vous obséder encore plus !

Greg : Exactement ! C'est pourquoi je le combine avec Prettier. Prettier s'occupe automatiquement du formatage, et les couleurs m'aident à parcourir rapidement le code pour trouver ce dont j'ai besoin. C'est simple et ça rend le codage un peu plus agréable.

Maintenant, Thomas, j'ai hâte de connaître ta cachette du jour.

Thomas : Bien sûr ! Ma cachette est Locust.io. J'ai récemment travaillé sur un article pour le blog Blackfire.io, et j'explorais les options pour les tests de charge. C'est alors que j'ai découvert Locust.io, un projet open-source de test de charge avec Python. Je ne suis pas le meilleur développeur Python, mais j'ai pu mettre en place des scénarios de test de charge pour une application en quelques heures seulement. C'est super convivial et puissant.

Greg : C'est génial ! Je connais bien Gatling pour les tests de charge, mais c'est bien de savoir qu'il existe une alternative open-source comme Locust.io. J'ai aussi tâté de Python, donc cela me semble tout à fait dans mes cordes. Je n'ai jamais effectué de test de charge moi-même, je n'ai fait qu'en subir les conséquences.

Thomas : C'est très simple ! J'ai exécuté les tests localement, et ils ont été effectués sur un serveur distant. Quelques commandes simples et tout était prêt à fonctionner. Locust propose également une version cloud si vous ne souhaitez pas gérer l'infrastructure vous-même.

Greg : J'aime le fait qu'il s'agisse d'un logiciel libre. On ne trouve pas toujours d'outils open source pour les tests de charge, alors je vais certainement l'essayer. Maintenant que nous avons partagé nos trouvailles du jour, il est temps de plonger dans le sujet principal : préparer votre application pour le rush des fêtes de fin d'année !

Comme nous l'avons déjà mentionné, les fêtes de fin d'année approchant à grands pas, il est essentiel de s'assurer que votre application est prête à faire face à l'augmentation du trafic et des demandes. Aujourd'hui, nous allons discuter de stratégies visant à renforcer la stabilité de votre application et à assurer son bon fonctionnement pendant les périodes de pointe, comme le vendredi noir et le cyber lundi.

Il ne s'agit pas nécessairement d'un webinaire formel ; nous allons simplement discuter de quelques idées clés. Certaines d'entre elles peuvent sembler évidentes, mais elles valent la peine d'être revues, notamment pour rappeler qu'il faut commencer à les mettre en œuvre dès maintenant. Pour ce segment, nous avons un invité spécial, Guillaume, qui a plus de 25 ans d'expérience dans le domaine du développement. Il a travaillé avec diverses entreprises de commerce électronique et a traversé plusieurs épisodes de Black Friday. Certaines personnes ont de l'expérience, d'autres des cicatrices, et je pense que Guillaume a un peu des deux !

Guillaume : Merci pour l'introduction, Greg, et merci de me rappeler mes 25 ans d'expérience, ce qui me fait toujours plaisir. Et oui, j'ai commencé à coder à l'âge de 14 ans, pas 5 ans, mais presque !

Greg : Alors, Guillaume, quel serait votre premier conseil pour préparer le trafic des fêtes de fin d'année ?

Guillaume : Mon premier conseil est lié à ce que Thomas a mentionné tout à l'heure à propos des tests de charge. Il faut faire des tests de performance pour voir comment le système se comporte en cas de forte charge. Mais vous avez également besoin de suffisamment de ressources pour simuler ces utilisateurs. La plupart des grandes plateformes de commerce électronique essaient de gérer des dizaines de milliers de transactions à la fois, et vous devrez donc effectuer des tests de résistance à cette échelle. Des outils tels que Locust Cloud sont très utiles, car ils vous évitent de mettre en place des dizaines d'instances AWS pour générer un trafic fictif.

La clé, c'est la préparation. Dans l'agence de commerce électronique pour laquelle je travaillais, nous gérions 30 à 40 sites web de grands détaillants, principalement dans le domaine de la mode. Le vendredi noir était toujours une période stressante. Des mois avant l'événement, nous commencions à nous préparer et à effectuer des tests. Il est essentiel de définir les scénarios de test. Vous voulez des scénarios qui correspondent à ce que font réellement vos utilisateurs, ce qui peut s'avérer difficile car les utilisateurs font toutes sortes de choses : consulter des catalogues pendant des heures, ajouter des tonnes d'articles à leur panier, les retirer, etc. Nous avons passé beaucoup de temps à travailler avec nos clients et à étudier les données analytiques pour définir des scénarios de test réalistes, mais même dans ce cas, on ne peut pas tout prévoir.

Lorsque le Black Friday est arrivé, la pression a été énorme. Les équipes marketing, les équipes techniques et les agences travaillaient 24 heures sur 24 et 7 jours sur 7 pour que tout fonctionne. Heureusement, grâce aux progrès de la technologie "cloud", il est aujourd'hui beaucoup plus facile de provisionner des ressources. À l'époque, si un serveur tombait en panne, nous devions nous rendre physiquement dans un centre de données pour en brancher un nouveau. Aujourd'hui, avec les fournisseurs de services en nuage, il suffit de créer de nouvelles instances. Mais même cela peut s'avérer délicat. Pendant le COVID, par exemple, nous avons enregistré un trafic de commerce électronique considérable et certains fournisseurs de services en nuage ont eu du mal à approvisionner les instances en raison d'une pénurie de matériel.

Greg : Vous avez mentionné le fait de travailler avec un fournisseur de services en nuage ; dans quelle mesure est-il crucial de procéder à une mise à l'échelle à l'avance ? Recommanderiez-vous de tester la capacité de votre infrastructure à évoluer avant le Black Friday ?

Guillaume : Absolument ! Quelques mois avant le Black Friday, vous devez commencer à mettre à l'échelle et à effectuer des tests de résistance. Il est important de ralentir le développement de nouvelles fonctionnalités pendant cette période - pas nécessairement un gel complet du code, mais l'accent doit être mis sur l'optimisation des performances. Cela signifie qu'il faut effectuer des tests, identifier les goulets d'étranglement et prévoir le pire des scénarios.

Lors d'un Black Friday, nous avons eu un client qui a augmenté ses ressources jusqu'à 1 200 CPU juste pour la journée. C'est le niveau de trafic dont nous parlons. Et il ne s'agit pas seulement des serveurs. Parfois, des composants tels que Redis, qui est monotâche, deviennent des goulots d'étranglement. Il faut anticiper ces problèmes et être prêt à réagir rapidement.

Greg : Guillaume, dirais-tu que tu as appris ces leçons à la dure, par l'expérience ?

Guillaume : Tout à fait. J'ai beaucoup de cicatrices pour le prouver. Une fois, alors que je travaillais pour une société de billetterie, nous avons conclu un accord avec une grande salle de spectacle et nous étions ravis de lancer leur nouvelle saison. Tout se passait bien jusqu'à ce que le grand rush arrive et que tout le système s'effondre. Nous avions sous-estimé la charge et n'avions pas testé correctement ces scénarios. Ce fut une dure expérience d'apprentissage.

Les tests en conditions réelles sont essentiels. Créez un clone de votre environnement de production et simulez les mêmes niveaux de trafic que ceux auxquels vous vous attendez pendant les périodes de pointe. Utilisez des outils d'observabilité et de surveillance pour voir ce qui ne fonctionne pas et où les choses ralentissent. Vous découvrirez peut-être que certaines parties de votre application se comportent différemment sous charge que dans un trafic quotidien normal.

Greg : Thomas, je sais que tu as des idées sur les tests et l'observabilité. Quelles sont les meilleures pratiques que tu recommanderais ?

Thomas : Oui, absolument ! L'observabilité est essentielle. Lorsque vous effectuez des tests de charge, utilisez des outils de profilage comme Blackfire ou d'autres plateformes d'observabilité. Ces outils vous donnent un aperçu de ce qui se passe à l'intérieur de votre application, ce qui vous permet d'identifier les problèmes. Vous découvrirez peut-être que certaines requêtes ou fonctions de la base de données sont à l'origine des problèmes de performance en cas de trafic important.

L'une des leçons que j'ai apprises en travaillant pour une société de billetterie est que votre installation doit être conçue pour le pire des scénarios, et pas seulement pour un trafic normal. Nous avons rencontré des problèmes lorsque le pic d'activité, par exemple lorsque des personnes scannaient des billets dans une salle de spectacle, se produisait la nuit et que personne n'était disponible pour faire évoluer l'infrastructure. Si votre système n'est pas conçu pour gérer la montée en charge automatiquement, vous risquez d'avoir de gros problèmes.

Greg : Cela soulève un point important à propos de la mise à l'échelle automatique. On dirait que le fait d'avoir la bonne infrastructure et les bons outils d'observabilité peut faire le succès ou l'échec de votre Black Friday.

Guillaume : Absolument. L'automatisation de la mise à l'échelle est essentielle, surtout si vous avez affaire à des événements à fort trafic. Vous ne voulez pas dépendre d'une intervention manuelle à 4 heures du matin lorsque votre trafic atteint son maximum. Si votre infrastructure peut évoluer automatiquement en fonction de la demande, c'est un énorme avantage.

Et pour répondre à la remarque de Greg, il ne s'agit pas seulement de faire évoluer vos serveurs - vous devez vous assurer que chaque partie de votre système, de vos bases de données à vos couches de mise en cache, peut supporter la charge. Parfois, ce sont les choses auxquelles on ne s'attend pas, comme les problèmes de mise en cache, qui peuvent tout faire échouer.

Greg : À ce propos, Guillaume, peux-tu nous en dire plus sur la mise en cache ? Tu as dit tout à l'heure que c'était l'une des choses les plus importantes sur lesquelles il fallait se concentrer quand on se prépare à des pics de trafic.

Guillaume : Tout à fait. La mise en cache est l'un des meilleurs moyens d'améliorer les performances, en particulier pendant les périodes de fort trafic. Si vous pouvez servir la même page ou le même contenu à des milliers d'utilisateurs à partir d'un cache plutôt que de la générer à nouveau à chaque fois, vous économiserez beaucoup de ressources et accélérerez les temps de réponse.

Cela dit, la mise en cache peut également s'avérer délicate. Il ne s'agit pas seulement d'activer la mise en cache ; vous devez vous assurer que vous mettez en cache les bonnes choses. Dans le domaine du commerce électronique, par exemple, il faut veiller à ne pas mettre en cache le contenu dynamique, comme les informations spécifiques à l'utilisateur. En revanche, pour les pages de produits, les listes de catégories et d'autres contenus statiques, la mise en cache est une évidence.

Les stratégies de mise en cache intelligentes permettent de réaliser de nombreux gains de performance. Elles réduisent la charge sur votre backend et accélèrent l'expérience de l'utilisateur. En fait, une célèbre statistique d'Amazon, datant d'il y a plusieurs années, indiquait que l'entreprise pouvait perdre des millions de dollars pour chaque 100 millisecondes de temps de chargement supplémentaire. Vous pouvez donc imaginer à quel point les performances sont cruciales lors d'un événement d'achat intense.

Greg : Thomas, je sais que tu es un grand partisan de l'observabilité. Pourriez-vous nous en dire plus sur le rôle de l'observabilité dans la mise en cache et le contrôle des performances ?

Thomas : Absolument. L'observabilité joue un rôle important non seulement pour détecter les problèmes de performance, mais aussi pour identifier les défaillances ou les performances insuffisantes de la mise en cache. Avec des outils comme Blackfire, vous pouvez surveiller votre application en temps réel, voir où se trouvent les goulots d'étranglement et même obtenir des recommandations sur la façon de les résoudre.

Par exemple, supposons que vos tests de charge révèlent que les requêtes de votre base de données atteignent des sommets lors des pics de trafic. Grâce à l'observabilité, vous pouvez relier ces requêtes à des parties spécifiques de votre code. Il se peut qu'une requête ne soit pas optimisée ou que vous extrayiez trop de données. L'essentiel est d'utiliser ces informations pour prendre des décisions fondées sur les données concernant la mise en cache et l'optimisation.

L'observabilité permet également d'éviter les situations où les développeurs font de mauvaises suppositions. Par exemple, un développeur peut penser : "Oh, il s'agit juste de quelques requêtes de base de données supplémentaires, ce n'est pas grave". Mais au fil du temps, ces petits changements peuvent s'accumuler, en particulier en cas de trafic important, et entraîner une dégradation significative des performances.

Avec l'observabilité en place, vous obtenez une image claire de la façon dont votre application se comporte dans différentes conditions, ce qui vous permet d'effectuer des changements proactifs avant qu'ils ne deviennent des problèmes critiques.

Greg : Guillaume, que penses-tu du rôle des tests dans ce contexte ? Y a-t-il un élément clé sur lequel vous mettriez l'accent si une équipe dispose d'un temps limité pour se préparer aux fêtes de fin d'année ?

Guillaume : Si vous n'avez le temps que pour une seule chose, je me concentrerais sur la mise en cache et l'optimisation de votre infrastructure backend. Si vous pouvez servir autant de contenu que possible à partir du cache, vous réduisez considérablement la charge sur vos serveurs. Mais si nous parlons d'une deuxième priorité, alors oui, l'observabilité et les tests sont cruciaux.

Les tests ne doivent pas porter uniquement sur les fonctionnalités, mais aussi sur les performances. Chaque fois que vous lancez de nouvelles fonctionnalités, vous devez effectuer des tests de régression des performances pour vous assurer qu'elles n'introduisent pas de nouveaux goulets d'étranglement. Les tests automatisés sont très utiles à cet égard, car ils peuvent être exécutés en continu et vous alerter en cas de défaillance ou de ralentissement.

Par exemple, je me souviens d'avoir travaillé sur une application où une nouvelle fonctionnalité avait involontairement ajouté des douzaines de requêtes SQL inutiles. L'application fonctionnait encore très bien dans des conditions normales de trafic, mais dès que la charge augmentait, ces requêtes devenaient un problème majeur. C'est pourquoi les tests et l'observabilité vont de pair. Vous devez savoir comment chaque partie de votre application fonctionne sous charge et disposer d'un plan pour résoudre les problèmes avant qu'ils n'atteignent la production.

Thomas : Commencez modestement, mais pensez stratégiquement. Il n'est pas nécessaire de tout mettre en œuvre en même temps, mais commencez par des tests d'observabilité et de performance pour vos chemins les plus critiques - les parties de votre application qui gèrent le plus de trafic ou qui ont le plus d'impact sur l'expérience de l'utilisateur.

Définissez des seuils de performance. Par exemple, vous pouvez fixer un nombre maximum de requêtes SQL par demande ou une limite de temps pour une opération spécifique. Utilisez ensuite des outils tels que Blackfire ou des plateformes similaires pour suivre automatiquement ces mesures. Si quelque chose dépasse ces limites, c'est un signal d'alarme qu'il convient d'examiner.

Concentrez-vous également sur la formation de votre équipe. Tout le monde n'a pas le même niveau de compréhension des problèmes de performance ou des stratégies de mise en cache. Assurez-vous que vos développeurs comprennent l'impact que leurs modifications peuvent avoir en cas de forte charge et qu'ils savent comment utiliser efficacement les outils d'observabilité.

Si votre équipe manque de temps, même de petites améliorations peuvent faire une grande différence. Par exemple, l'amélioration des performances d'une fonction fréquemment utilisée ou la réduction du nombre de requêtes de base de données sur une page à fort trafic peuvent réduire considérablement la charge sur vos serveurs.

Greg : Exactement. Je pense que le message général ici est de planifier et de tester bien à l'avance. Qu'il s'agisse de tests de charge, d'observabilité ou d'optimisation de votre stratégie de mise en cache, le fait de se préparer à l'avance peut vous éviter bien des maux de tête lorsque le trafic des fêtes de fin d'année se fera sentir.

C'est exactement ce qu'il faut faire : la préparation est essentielle lorsqu'il s'agit de gérer un trafic élevé pendant les périodes de pointe telles que le vendredi noir et le lundi de l'été. Plus vous planifiez à l'avance, plus vous pouvez atténuer les urgences de dernière minute qui surgissent inévitablement. J'aimerais ajouter une chose à propos de l'élément humain dans tout cela.

Lorsque vous effectuez des tests de charge et des contrôles de performance, vous ne testez pas seulement le système, mais aussi votre équipe. Vous voulez vous assurer que tout le monde sait comment gérer ces situations lorsqu'elles se présentent. Il ne s'agit pas seulement de technologie, mais aussi de processus et de communication au sein de l'équipe.

Thomas, Guillaume : Êtes-vous d'accord pour dire que ces tests aident à préparer les personnes autant que les systèmes ?

Guillaume : Absolument, Greg. Ces tests ne servent pas seulement à valider l'infrastructure, mais aussi à s'assurer que l'équipe sait comment réagir en temps réel. Par exemple, si quelque chose se casse pendant un test, est-ce que tout le monde sait ce qu'il faut faire ? Sait-on qui contacter ? Le meilleur moyen d'éviter le chaos lors d'un événement réel est d'exécuter ces scénarios à l'avance.

Thomas : Oui, à 100 %. Le vendredi noir est en quelque sorte un exercice d'évacuation. Vous ne voulez pas seulement que votre système fonctionne sous charge - vous voulez que votre équipe sache quoi faire si quelque chose d'inattendu se produit. Plus vous répétez ces scénarios, mieux vous serez équipé pour réagir rapidement et minimiser les temps d'arrêt.

Greg : C'est un excellent point, et cela nous ramène à l'importance d'avoir des processus en place. Vous devez avoir des plans de secours clairs si les choses tournent mal. Si quelque chose tombe en panne, qui est responsable de la réparation ? Quel est le plan de secours en cas de défaillance du système principal ? Ce sont des questions auxquelles il faut répondre bien avant que le trafic ne commence à arriver sur votre site.

En gardant cela à l'esprit, quel serait votre dernier conseil aux équipes qui se préparent à un trafic important, que ce soit pour les vacances ou pour tout autre événement majeur ?

Guillaume : Je dirais qu'il ne faut pas attendre la dernière minute. Commencez dès maintenant vos tests de charge et l'optimisation des performances. Même si vous n'avez pas beaucoup de temps ou de ressources, chaque optimisation que vous faites maintenant vous évitera des maux de tête plus tard. Et assurez-vous de tirer parti des outils de mise en cache et d'observabilité.

Thomas : Je retiens surtout qu'il faut investir dans l'observabilité. Il ne s'agit pas seulement de surveiller, il s'agit de comprendre comment votre application se comporte en cas de stress. Si vous pouvez voir les signes avant-coureurs rapidement, vous pouvez résoudre les problèmes avant qu'ils ne deviennent catastrophiques. Utilisez également vos tests de charge pour identifier les points faibles et les renforcer à l'avance.

Greg : Excellent conseil. J'ajouterais que la communication est essentielle, tant au sein de votre équipe qu'avec les fournisseurs externes avec lesquels vous travaillez. Assurez-vous que tout le monde est au courant de ce qui se passe et qu'un plan a été mis en place. Ainsi, en cas de problème, ce n'est pas le chaos total pour savoir ce qu'il faut faire.

Cela étant dit, je pense qu'il est temps de passer à notre segment de demande de sondage, au cours duquel nous répondons aux questions du public.

Notre formidable productrice, Céleste, est en train d'extraire les questions. La première vient du chat :

"Est-ce que vous voyez une frénésie dans les frameworks, ou est-ce que vous pensez que seuls quelques frameworks vont émerger et rester à long terme ?

Guillaume : C'est une excellente question. Je pense qu'il y aura toujours de nouveaux frameworks qui apparaîtront et disparaîtront. Pour l'instant, React, Angular et Vue sont les principaux acteurs, et je pense qu'ils resteront en place pendant un certain temps. Mais il y a aussi des frameworks comme Svelte et Remix qui gagnent en popularité. La clé est de ne pas trop se laisser prendre par le battage médiatique. Utilisez le framework qui répond le mieux aux besoins de votre projet et qui est soutenu par une communauté et un écosystème solides.

Thomas : Je suis d'accord. Il y a vraiment beaucoup d'excitation autour des nouveaux frameworks, mais j'ai tendance à m'en tenir à ceux qui ont fait leurs preuves, comme React. Il existe depuis longtemps, dispose d'une communauté massive et de tonnes de ressources. Cela dit, il est toujours bon de garder un œil sur les frameworks émergents, mais il ne faut pas changer pour le plaisir de changer.

Greg : Oui, j'apprends Flask en ce moment, et c'est très bien pour ce dont j'ai besoin. Pour moi, ce qui compte, c'est moins le framework que ce avec quoi on est à l'aise et ce qui fonctionne le mieux pour le projet en cours.

Greg : Génial. Passons à la question suivante :

"Comment équilibrez-vous la pression pour sortir des fonctionnalités avec le besoin de maintenir les performances lors d'événements à fort trafic ?

Guillaume : C'est toujours une question difficile. Je pense que la clé est de communiquer avec vos parties prenantes - qu'il s'agisse de votre équipe produit, du marketing ou de toute autre personne - et d'expliquer les risques potentiels liés à la sortie d'un trop grand nombre de nouvelles fonctionnalités juste avant un événement majeur. L'idéal est de geler les fonctionnalités avant le Black Friday ou toute autre période de forte affluence, afin de se concentrer sur les performances et la stabilité.

Thomas : Oui, je dirais que le gel des fonctionnalités est votre ami dans ce cas. Il est très tentant de sortir de nouvelles fonctionnalités avant un grand événement, surtout s'il y a une campagne de marketing derrière. Mais il faut évaluer le risque de panne par rapport aux avantages potentiels de la nouvelle fonctionnalité. Parfois, il vaut mieux attendre et s'assurer que le système est stable.

Greg : C'est un excellent conseil. Je pense que la conversation entre les équipes de développement et les équipes commerciales est essentielle à cet égard. Les deux parties doivent comprendre les compromis à faire entre le lancement de nouvelles fonctionnalités et l'assurance de la stabilité.

Greg : Et sur ce, il semblerait que nous terminions le flux en direct d'aujourd'hui. Merci à tous ceux qui nous ont rejoints pour Upsun Live ! Nous espérons que ces conseils vous ont été utiles.

Un grand merci à notre invité, Guillaume, et bien sûr à Thomas. Merci également à notre productrice, Céleste, et à Pablo, qui s'est occupé de l'aspect technique en coulisses. N'oubliez pas de consulter Upsun.com et Blackfire.io pour plus de ressources sur la performance et l'observabilité des applications.

Restez prudents, continuez à coder, et nous nous reverrons la prochaine fois ! Prenez soin de vous.