Mort par mille microservices

• La culture qui consiste à adopter les microservices par défaut est critiquée pour avoir accru les coûts et la complexité afin de résoudre non pas de vrais problèmes d’échelle, mais des problèmes inexistants
• La fermeture de l’écosystème JavaScript/Node.js, les pratiques façon FAANG et l’abondance du capital-risque se sont combinées pour créer, même chez les startups, une ambiance où l’on imite les architectures web-scale
• Même avec Docker et Kubernetes, les difficultés des systèmes distribués — développement, débogage, déploiement, tests et résilience — ne disparaissent pas
• Dropbox, Twitter, Netflix, Facebook, GitHub, Instagram, Shopify, StackOverflow, WhatsApp, entre autres, ont démarré avec une base de code monolithique ou conservent encore aujourd’hui un monolithe au cœur de leur système
• La plupart des entreprises n’atteignent pas l’échelle qui exige réellement un système distribué ; il est donc plus réaliste d’extraire un service uniquement lorsqu’il existe une charge clairement isolable et extensible

---

Une culture qui vénère la complexité

• La satire qui échoue à expliquer un labyrinthe complexe de microservices pour obtenir une simple date de naissance d’utilisateur vise la surconception de la culture technique actuelle
• Le problème est que l’objectif a basculé : au lieu de résoudre les tâches immédiates, on brûle de l’argent à résoudre des problèmes inexistants
• La critique de JavaScript et de Node.js ne concerne pas seulement une technologie précise ; elle renvoie au danger d’un écosystème logiciel fermé qui pousse à réapprendre des leçons déjà acquises
• Le secteur a déjà connu par le passé des murs de complexité comme CORBA et SOAP avant de faire marche arrière

Les conditions qui ont créé la mode des microservices

• Des développeurs qui utilisaient JavaScript pour le navigateur se sont revendiqués “full-stack” et sont entrés dans le développement serveur et le code asynchrone ; les débuts de Node ressemblaient plutôt à des projets d’apprentissage individuels, et le JavaScript initial était un choix très problématique pour le serveur
• Le monde hors de Node ayant été perçu comme pratiquement inexistant, une pensée dogmatique s’est installée, selon laquelle la façon Node était la seule façon de faire
• Par la suite, des profils issus des FAANG ont rejoint des startups et diffusé “la manière de faire chez Google” comme une réponse universelle, indépendamment du contexte et de l’échelle
  • La pression du type “sans User Preferences Service séparé, ça ne passera pas à l’échelle” en est un exemple représentatif
• À l’époque où le capital-risque abondait, montrer aux investisseurs une croissance explosive est devenu plus important que le chiffre d’affaires, et les entreprises ont rapidement recruté des ingénieurs logiciels coûteux pour leur faire faire “quelque chose”

Les systèmes distribués restent difficiles

• Les microservices ont été présentés comme une “nouvelle façon d’écrire du logiciel scalable”, mais ils touchent en réalité au vieux problème des systèmes distribués
• Historiquement, les systèmes distribués étaient considérés comme des outils difficiles et dangereux, proches du dernier recours pour des problèmes particulièrement épineux
• Dans un système distribué, toutes les tâches suivantes sont plus difficiles et plus longues
  • Développement
  • Débogage
  • Déploiement
  • Tests
  • Mise en place de la résilience
• Le développement fondé sur les microservices ne dispose pas d’outillage standard ni de framework commun ; même dans les années 2020, travailler sur des systèmes distribués n’est devenu qu’un peu plus facile
• Docker et Kubernetes ne font pas disparaître par magie la complexité intrinsèque d’une configuration distribuée

Des exemples où la simplicité donne de meilleurs résultats

• Le bilan de 5 ans d’audits de code de startups conclut que les startups qui réussissaient le mieux adoptaient une approche Keep It Simple presque sans complexe
• Les migrations prématurées vers les microservices, les architectures dépendantes du calcul distribué et les conceptions centrées sur la messagerie ont été des pièges majeurs qui ont mis plusieurs entreprises en difficulté
• Beaucoup de startups construisent des systèmes simples et performants tout en ressentant un faux complexe d’infériorité parce qu’elles “ne font pas de microservices dès le premier jour”
  • À la question “qu’est-ce qui ne va pas si l’on n’a qu’un monolithe Django maintenu par quelques ingénieurs et une instance MySQL ?”, la réponse est presque toujours : “rien”
• Même des ingénieurs expérimentés peuvent se sentir inadéquats dans la culture technique actuelle, mais le vrai problème peut être un environnement mêlant confiance excessive injustifiée, gaspillage et effet Dunning-Kruger

Des entreprises qui ont aussi grandi avec des monolithes

• L’idée selon laquelle on ne peut pas grandir sans microservices tient du mythe
• Dropbox, Twitter, Netflix, Facebook, GitHub, Instagram, Shopify, StackOverflow et d’autres ont commencé avec une base de code monolithique, et certaines gardent encore un monolithe au cœur de leur système
• StackOverflow met en avant sur sa page de performance le fait d’exploiter un grand site avec peu de matériel
• Shopify utilise toujours un monolithe Rails et traite des milliards de jobs avec le très éprouvé Resque
• WhatsApp a fortement grandi avec un monolithe Erlang et environ 50 ingénieurs
  • L’organisation d’ingénierie est restée petite, autour de 50 personnes
  • Les équipes individuelles comptent 1 à 3 personnes et disposent d’une forte autonomie
  • L’entreprise privilégie un petit nombre de serveurs et augmente autant que possible verticalement chacun d’eux
• Instagram a été racheté pour plusieurs milliards de dollars avec une équipe de 12 personnes, et Threads suit aussi le modèle Instagram

Ne pas résoudre des problèmes inexistants

• La question centrale est : “quel problème résout-on ?”
• Si l’échelle est le problème, il faut des données montrant quoi séparer en service distinct, et pourquoi
• Les systèmes distribués sont conçus pour l’échelle et la résilience, mais il faut aussi prendre en compte les situations où, lorsqu’un service ralentit ou tombe, le trafic se reporte sur d’autres services
• Les facteurs à considérer dépendent des schémas d’usage et des caractéristiques de charge du système
  • Backpressure
  • Circuit breakers
  • Files d’attente
  • Jitter
  • Timeouts raisonnables sur tous les endpoints
  • Garde-fous pour empêcher qu’un petit changement provoque une panne globale
• La plupart des entreprises n’atteignent pas l’échelle gigantesque qui exige un vrai système distribué
• Imiter Amazon et Google sans avoir leur échelle, leur expertise ni leurs ressources mène facilement à gaspiller du temps et de l’argent
• Reste cet avertissement : un mauvais système distribué est encore plus difficile qu’un système distribué en soi

L’idéal et la réalité des services par équipe et des API

• La tentative d’aligner une topologie distribuée sur la structure de l’entreprise part de l’idée qu’un problème devient plus simple si on le divise en petits morceaux
• Le microservice idéal est strictement maintenu par une équipe dédiée, caché derrière une belle API versionnée et rétrocompatible, et nécessite très peu de communication avec les autres équipes
• Dans la réalité, les canaux Slack débordent de releases, de bugs, de changements de configuration, de breaking changes et d’annonces
• Tout le monde doit constamment suivre toute la situation, et il est courant que des équipes déjà occupées se retrouvent à gérer maladroitement plusieurs microservices
• La propriété des services change au gré des mouvements de personnes, et l’on finit par construire plusieurs mauvaises voiturettes de golf au lieu d’une bonne voiture de course

Ce que les microservices font perdre

• L’affaiblissement du DRY

  • Les microservices ne sont fondamentalement pas DRY, et chaque service embarque du boilerplate redondant
  • Dans les petits microservices, le code de plomberie prend une telle place que l’instance de service moyenne peut ressembler davantage à du code de “service” qu’à du code produit
  • Lorsqu’on essaie d’extraire du code commun, toutes les options sont douloureuses
    • Créer une bibliothèque commune oblige à décider d’une stratégie de versions et de mises à jour
    • On peut créer régulièrement des pull requests dans tous les dépôts pour imposer les mises à jour
    • Regrouper le tout en monorepo apporte ses propres problèmes
    • On accepte une certaine duplication de code, ou bien chaque équipe réinvente la roue à chaque fois

• La dégradation de l’expérience développeur

  • L’expérience développeur correspond au niveau de friction et d’effort nécessaire pour développer une nouvelle fonctionnalité ou corriger un bug
  • Dans un environnement de microservices, il faut une carte mentale de tout le système pour savoir quels services lancer pour une tâche donnée, quelles équipes solliciter et à qui poser quelles questions
  • Spotify a créé Backstage pour cataloguer ses nombreux systèmes et services, ce qui montre le coût élevé de ce jeu
  • Les entreprises qui ne sont pas Spotify finissent par bricoler leurs propres solutions, sans pouvoir vraiment attendre robustesse ni portabilité
  • Démarrer un nouveau service implique aussi d’automatiser beaucoup d’éléments
    • Droits développeur GitHub/GitLab
    • Variables d’environnement et configuration de base
    • CI/CD
    • Contrôles de qualité du code
    • Configuration des revues de code
    • Règles et protections de branches
    • Monitoring et observabilité
    • Harnais de test
    • Infrastructure as Code
  • Si plusieurs langages de programmation sont utilisés, cette liste se multiplie par le nombre de langages
  • Peaufiner ces automatisations peut prendre des mois, et l’on se retrouve à choisir entre construire le produit et construire des outils

• La difficulté des tests d’intégration

  • Même si les tests d’un service isolé et les tests unitaires passent, cela ne dit pas si les chemins critiques restent valides après chaque commit
  • Les tests d’intégration en environnement distribué sont traités comme un problème presque impossible, et l’observabilité est venue prendre leur place
  • L’observabilité est devenue un nouveau secteur industriel, qui exige non seulement de l’argent mais aussi du temps développeur
  • L’observabilité ne fonctionne pas immédiatement comme un plugin ; il faut comprendre et mettre en œuvre les releases canary, les feature flags, etc.
  • Découper le problème ne le rend pas plus facile à résoudre : on obtient un ensemble de problèmes plus difficiles

Un monolithe n’est pas automatiquement du bon code

• Défendre le monolithe ne signifie pas que “monolithe” veut dire bon code et “microservices” mauvais code
• Dans la réalité, il existe beaucoup de monolithes médiocres produits par des équipes pressées ou ordinaires
• Mais les systèmes distribués sont beaucoup plus impitoyables envers les approximations, les mauvaises décisions et les modes de panne oubliés
• Si l’on ne fonctionne pas constamment à un haut niveau, on en paie le prix dans un système distribué

De simples services peuvent suffire, sans être “micro”

• Un service n’a pas forcément besoin d’être “micro” ; un simple service peut suffire dans certains cas
• Certaines startups sont allées jusqu’à créer un service par fonction, montrant jusqu’où peut aller un cargo cult non validé
• Commencer par un monolithe est une option claire
• Le pattern “trunk & branches” peut aussi convenir dans de nombreux cas
  • Les fonctionnalités cœur sont assurées par le monolithe principal, les “viande et pommes de terre” du système
  • Les charges clairement identifiables qui nécessitent une mise à l’échelle distincte sont prises en charge par des services branch
• Un Image-Resizing Service gourmand en CPU a davantage de sens comme service séparé qu’un User Registration Service
• Demander si le nombre d’inscriptions par seconde est assez élevé pour exiger une mise à l’échelle horizontale indépendante devient un critère pour décider de séparer un service

Le reflux de la mode et les choix réalistes

• La surchauffe autour des microservices semble retomber, et le resserrement des flux de capital-risque amène le marché à pousser les entreprises vers des décisions plus sensées
• Dépenser de l’argent dans une architecture web-scale sans avoir de problème web-scale n’est pas soutenable
• Si l’on doit aller de New York à Philadelphie, la solution adaptée au problème consiste à acheter un billet Amtrak de 90 minutes plutôt qu’à construire un vaisseau spatial complexe

[GN⁺]

Avis de Hacker News

• Je fais partie de ceux qui ont fortement défendu les microservices ; j’ai aidé à construire la plateforme Netflix et j’ai parcouru le monde pour en vanter les avantages. Pourtant, quand je conseille des startups, je leur dis presque toujours de commencer par un monolithe
  Il est beaucoup plus simple de garder une seule base de code et une seule base de données, et cela peut passer à l’échelle pendant assez longtemps. Si l’on utilise un stockage clé/valeur comme DynamoDB, on perd une partie des fonctionnalités relationnelles, mais on peut tenir encore plus longtemps
  Un monolithe peut aussi être déployé sur Lambda, et l’on peut bénéficier des avantages de Lambda sans découper les services
  Ce n’est qu’une fois la croissance arrivée qu’il faut extraire en microservices, avec leur propre stockage de données, les parties qui doivent passer à l’échelle indépendamment ou être déployées séparément
  Les microservices consomment au minimum 25 % du temps d’ingénierie rien que pour maintenir la plateforme ; s’ils ne permettent pas de récupérer au moins autant d’efficacité, ils n’ont aucune valeur

  • L’expression « assez longtemps » est une sous-estimation. Avec quelqu’un qui sait un minimum manier SQL, le simple fait de mettre Postgres sur un gros serveur de base de données permet d’aller jusqu’à des tables de 50 millions de lignes avant même d’envisager de recruter un vrai DBA
  • À ce stade, plutôt que de découper en microservices, il faut refactorer le monolithe en composants et regarder les vrais indicateurs de performance via du tracing
    En phase de croissance — et même dans la plupart des cas — mieux vaut ne pas faire de microservices du tout
    Et, par pitié, il ne faut pas découper les données. Les données sont bien plus complexes à gérer que le code
  • Tout se ramène à une vérité très simple : faire aussi simple que possible, et aussi complexe que nécessaire
    On peut toujours rendre les choses plus complexes plus tard. On peut extraire une partie d’un monolithe pour en faire un service ; c’est difficile, certes, mais cela n’a rien à voir avec le fait de retirer d’un système une complexité déjà introduite
    Quiconque a déjà tenté de ramener plusieurs microservices dans un monolithe le sait : en général, la charge de travail ressemble à une réécriture depuis zéro
  • Beaucoup d’entreprises n’ont tout simplement pas besoin de passer à l’échelle. Netflix est un modèle avec beaucoup de clients et un faible revenu par client, mais il existe aussi beaucoup d’activités, peut-être davantage, avec peu de clients et un revenu élevé par client
    Pour ce type de produit, on pourrait vraiment faire tourner l’environnement de production sur un ordinateur portable si on le voulait
    Dans mon emploi précédent, on avait organisé une fête aux microservices pour 300 clients. C’était pourtant une activité où quelques milliers de clients auraient déjà été un succès, et quelques dizaines de milliers un immense succès
    En général, comme on ne consacre pas 25 % du temps d’ingénierie à maintenir la plateforme, elle devient impossible à exécuter en local et l’environnement de production tient à peine avec du ruban adhésif
    Lors d’un entretien récent, on m’a demandé de concevoir un système pour « 500 millions d’utilisateurs simultanés », alors que l’entreprise relevait plutôt du modèle avec peu de clients et un revenu élevé par client
    Je ne sais toujours pas si c’était un test pour voir si je relevais que 500 millions représente environ 10 % de la population mondiale connectée à Internet, donc un chiffre absurde, ou si la startup croyait vraiment pouvoir en arriver là
    J’ai répondu que je me concentrerais sur la chose la plus simple : construire un monolithe, ajouter des fonctionnalités et vérifier que les gens veulent vraiment le produit. Je n’ai pas été recruté
  • Personnellement, je ne recommanderais pas les microservices avant d’atteindre l’échelle de Netflix, Amazon ou Reddit. Et même à cette échelle, il faut disposer en interne de ce niveau d’expertise, sinon cela devient un cauchemar

• Je travaille sur un énorme monolithe avec environ 800 contributeurs, et ajouter un champ aussi simple que la date de naissance d’un utilisateur est tout aussi complexe. Cela dit, toute la complexité n’est pas technique : comme on touche au code de tout le monde, il faut un « alignement organisationnel »
  Les cycles de conception et de revue se répètent sans fin, il faut l’approbation d’au moins deux architectes, et la tâche est ajoutée à plusieurs cycles de planification. Le code réel prend moins d’une demi-journée
  Lors de la revue de code, il faut atteindre 90 % de couverture de tests, mais il y a tellement de tests que la PR est trop grosse : on la découpe donc en plusieurs PR, qui finissent intégrées sur plusieurs releases hebdomadaires
  On cache alors la fonctionnalité derrière un feature flag, mais il y a actuellement 13 000 feature flags
  Une fois en production, avec les dashboards et le monitoring branchés, on l’active puis on la désactive à répétition. On ne sait pas bien pourquoi la fonctionnalité d’anniversaire a cassé le service de facturation, mais elle semble en être la cause, donc il faut l’analyser pendant des semaines
  Au bout d’un an, l’ingénieur chargé de cette tâche recevra peut-être une bonne évaluation et deviendra candidat à une promotion. Puis il sera immédiatement affecté à un autre projet bancal, entamé trois ans plus tôt : permettre aux utilisateurs de définir leur fuseau horaire

  • Le point central n’est pas microservices contre monolithe, mais plutôt ce que l’article appelle les apôtres du culte de la complexité
    Les microservices comme les monolithes ne sont ni des marteaux universels ni des balles d’argent ; à l’inverse, ils ne sont pas le mal absolu. Ce sont deux outils avec des compromis, qui se combinent avec des compromis propres au contexte de chaque organisation
    Le problème, c’est que les ingénieurs sont fascinés par la complexité, confondent « simplicité » et « bricolage », et que les organisations imitent aveuglément des outils et des patterns d’architecture
    Appliquer naïvement une architecture ou un design pattern en pensant que le simple fait de l’utiliser apportera des bénéfices ne produit pas ces bénéfices
  • Les défenseurs des énormes monorepos oublient souvent que Google dispose d’équipes séparées qui ne font que construire les outils nécessaires pour refactorer et tester cette base de code unique
  • On dirait une entreprise capable de tout gâcher quel que soit le paradigme de stack technique choisi
  • Cette entreprise ne semble pas subir de pression concurrentielle l’obligeant à livrer rapidement les changements de code. Mais si un challenger apparaît, ou si son avantage défensif disparaît, cela deviendra un problème
    J’ai essayé de garder en tête que le génie logiciel est une lutte sans fin contre la complexité, avec des réussites et des échecs
    Cette lutte doit être permanente et être la priorité absolue. Sinon, on arrive à ce genre de situation
    Aucune architecture ni idéologie ne met fin à cette guerre : c’est simplement la nature même du métier
  • 13 000 feature flags, c’est délirant. Dans mon ancien poste, je suis content d’avoir insisté pour qu’on utilise des flags de « release » pour les nouvelles fonctionnalités qui n’avaient pas besoin d’être explicitement activées ou désactivées pour certains clients
    En production, ces flags de release ne pouvaient pas être activés, et les développeurs devaient supprimer le code du flag avant les tests finaux et la release
    Cela ajoute un peu de travail pour chaque fonctionnalité nécessitant un flag, mais au bout de quelques mois, la réduction de la complexité de la base de code est largement payante

• Les microservices ne sont pas une solution à un problème technique, mais à un problème social.
  Une équipe de N ingénieurs nécessite N² coordinations. Les grandes équipes s’enlisent dans des réunions, des e-mails et des revues de conception sans fin ; les petites équipes sont plus efficaces, mais peinent à maintenir de grands systèmes.
  En découpant le système en sous-systèmes, chaque équipe peut se concentrer sur sa pièce du puzzle tout en réduisant la coordination entre les personnes.
  Il est vrai que les microservices ajoutent de la complexité et de l’overhead, mais cette approche permet aux grandes organisations de construire de grands systèmes rapidement et de les améliorer par itérations.

  • En pratique, ça ne se passe pas comme ça. Quand on découpe un système en sous-systèmes, les connexions existantes ne font qu’être mappées vers de nouvelles connexions entre sous-systèmes ; les connexions nécessaires pour résoudre le problème de fond restent indispensables.
    Désormais, au lieu de connexions directes, il faut des réunions « transverses » entre équipes et des couches de communication complexes.
    Si l’on a trouvé un découpage qui nécessite très peu de connexions entre sous-systèmes, alors ces connexions n’existaient déjà pas dans le système d’origine, et il n’y avait pas non plus de problème en N².
  • En théorie, je suis d’accord, mais en pratique je n’ai jamais vu d’équipes organisées ainsi autour des microservices.
    Ce que j’ai vu à répétition, c’est une seule énorme équipe où « tout le monde est responsable de tous les microservices », ce qui finit par faire que plus personne n’est responsable de quoi que ce soit.
  • Les gens semblent oublier qu’on peut créer des répertoires séparés dans une base de code.
    Pour résoudre un « problème humain », on transforme un petit problème technique en problème complexe de système distribué.
    Et là, on a un vrai problème.
  • Honnêtement, je ne suis pas non plus convaincu que les petites équipes peinent à maintenir de grands systèmes. J’ai déjà maintenu, avec 7 bons ingénieurs, un projet de 3,5 millions de lignes comprenant à la fois une UI web et un client lourd.
    Il prenait en charge deux types de bases de données et disposait aussi d’un exécuteur de tâches capable de scaler horizontalement.
    À un moment, nous étions 35, puis les licenciements nous ont ramenés à 7, et c’est là que nous avons commencé à accomplir beaucoup plus de choses. Parce que le temps passé à aligner tout le monde avait fortement diminué.
    Il y avait beaucoup moins de réunions, d’approbations, de revues, de planification, de rétrospectives et de réunions de management ; les développeurs avaient davantage de marge de manœuvre et terminaient simplement le travail.
    Les fonctionnalités étaient facilement livrées en moitié moins de temps, et nous consacrions les 50 % restants au remboursement de la dette technique. Comme nous réduisions impitoyablement la complexité, l’ajout de nouvelles fonctionnalités s’est aussi accéléré.
    Certains projets ont sans doute besoin de plus de monde, mais je pense qu’il existe un plafond à la complexité qu’on peut ajouter à un système dans un temps donné.
    Si l’on dépasse un seuil et qu’on ajoute des développeurs, le nombre de fonctionnalités par semaine reste le même, mais tout le monde travaille un peu moins et passe davantage de temps à communiquer.
    Répétez ce processus jusqu’à atteindre des milliers de personnes, et il faut des mois pour ajouter un champ.
  • Pourquoi faut-il absolument découper en services ?
    Je me demande si l’on a envisagé de déplacer les choses dans des dossiers différents.
    Pas besoin d’un nouveau dépôt ni d’une nouvelle configuration Docker pour modulariser. Utilisez simplement des dossiers.

• Un schéma que j’ai souvent vu est le suivant. Les CTO ou VP actuels ont créé le monolithe d’origine, ou ont participé à sa création.
  Personne n’a envie de dire au CTO que ce code est mauvais. Ou bien c’est simplement du code qui, parce que les temps ont changé, a besoin d’une refonte complète, sans que cela ait quoi que ce soit à voir avec le fait qu’il s’agisse d’un monolithe.
  Le CTO est trop occupé par le marketing ou la levée de fonds pour trancher entre microservices et monolithe, et c’est un architecte fraîchement recruté qui prend la décision.
  Tout le monde acclame les microservices. Cela colle bien au récit d’une entreprise tech sérieuse en forte croissance, et personne ne veut être le seul à s’y opposer ni critiquer le CTO.
  Il est rare que les microservices soient recommandés parce qu’ils constituent sincèrement le meilleur compromis. C’est plutôt parce que les gens aiment leur travail, aiment recruter davantage et que cela colle bien au récit de l’entreprise.
  Pendant une grande refonte, on peut réécrire et améliorer beaucoup de code ; il suffit d’appeler cela une migration vers les microservices.
  Au final, cela devient une façon de réécrire en masse du vieux mauvais code, sans blesser les sentiments du CTO, en suivant la foule, et sous une cause que presque tout le monde soutient.

  • Ne pas vouloir dire que le code du CTO est mauvais n’est pas un schéma, c’est quasiment inévitable.
    Qu’il s’agisse d’un lead engineer individuel ou d’un CTO/fondateur, on finit toujours, avec le recul, par conclure qu’on aurait pu faire mieux, et par voir, avec joie et effroi, les bénéfices et les défauts des patterns et processus que l’équipe a suivis de bonne foi.
  • La description qui vient d’être faite résume exactement les cinq dernières années de StumbleUpon.

• J’aime d’autant plus ce texte qu’il confirme mes biais
  Je le dis depuis des années, mais je vois la folie des microservices surtout comme un prétexte pour que des ingénieurs moyens maintiennent la demande. La médiocrité l’alimente, et en même temps elle fait tourner beaucoup d’entreprises tech
  Il n’y a pas assez d’ingénieurs compétents capables de bien manier UNIX et de construire de beaux systèmes minimalistes comme StackOverflow
  Donc les microservices comme écran de fumée pour masquer la médiocrité vont continuer d’exister. D’autant plus que des fournisseurs cloud comme AWS se promeuvent par tous les canaux possibles et poussent les décideurs à choisir cette voie

  • Je ne comprends pas pourquoi personne n’embauche ni n’écoute les architectes qui recommandent de conserver un système monolithique sûr
    Si l’on ne parle pas de cloud, de microservices et de tout dernier framework non éprouvé, on passe pour un vieux dépassé
    Alors même que de tels systèmes sont rarement les plus efficaces, les plus robustes ou les plus sûrs
    Mon entreprise actuelle développe des logiciels utilisés en interne par d’autres sociétés ; il y a au maximum 200 utilisateurs simultanés et pas de pics d’utilisation
    Ce serait l’environnement parfait pour un serveur web ordinaire, sans problèmes de montée en charge imprévus, mais tout le monde veut aller dans le cloud
    À mon avis, c’est parce que la direction, les programmeurs et même les clients ont été convaincus par le marketing du cloud et pensent que le cloud, c’est cool
  • Il y a clairement des développeurs qui s’enthousiasment pour les microservices pour de mauvaises raisons, par exemple parce que ça fait bien sur un CV, mais le problème le plus important est la manière dont les entreprises gèrent la complexité
    Les entreprises n’expédient pas seulement leur organigramme : elles embarquent aussi dans le produit tous leurs dysfonctionnements et tout leur passif historique
    Il y a cinq ans, c’était peut-être une belle plateforme efficace et bien conçue, avec un modèle de données et des API propres, du code bien écrit et testé ; mais après cinq ans de changements de cap incessants du CEO, de demandes clients de dernière minute poussées par les commerciaux, de chefs de produit ajoutant des fonctionnalités ni nécessaires ni demandées, avec trop peu de personnel et de temps, elle peut devenir un désordre complet
    Un jour, on se retrouve face à un énorme tas de dette technique, avec des corrections de bugs et des ajouts de fonctionnalités qui prennent plus de temps que nécessaire, et les microservices se mettent à sonner comme le chant des sirènes qui promet qu’on n’aura pas besoin de tout brûler pour repartir de zéro
  • StackOverflow n’a pas été construit sur UNIX, mais sur Windows
    Ça peut sembler être du pinaillage, mais il y a un point plus général : les choix technologiques sont rarement le goulet d’étranglement
  • D’après mon expérience, même des ingénieurs moyens peuvent construire un monolithe correct avec un framework très prescriptif comme Ruby on Rails
    À l’inverse, les microservices ont beaucoup plus de pièces mobiles et de modes de défaillance, donc ils sont bien plus complexes ; des ingénieurs moyens, et même beaucoup d’ingénieurs qui ne le sont pas, ont beaucoup plus de chances d’y créer des problèmes
  • Plutôt que d’ingénieurs moyens, il s’agit peut-être d’ingénieurs inexpérimentés qui veulent remplir leur CV
    J’ai l’impression qu’on n’a pas réussi à enseigner correctement à la génération actuelle ce qui compte dans ce métier

• Je compatis, car nous sommes en train de passer aux microservices dans une petite équipe. Le plus gros problème, c’est l’observabilité
  Quand un problème survient en production, déterminer précisément ce qui a mal tourné devient une corvée énorme
  Suivre les logs d’une seule application distribuée ne suffit pas : il faut regarder simultanément les logs de plusieurs applications distribuées, avec des messages entremêlés
  Ça irait si nous avions un outil pour visualiser les traces, mais comme nous sommes une petite équipe, notre bande passante humaine est limitée, et nous n’avons pas encore ce genre d’outil
  À l’inverse, le monolithe avait NewRelic intégré depuis des années. Il y avait des problèmes de performance, mais la plupart ont été résolus avec des index et quelques vues matérialisées
  Il est facile de comprendre ce qui ne va pas, et même si le code est ancien et rempli de conditions de concurrence, le dépannage en lui-même n’est pas difficile
  Je redoute le moment où chaque microservice aura sa propre instance de base de données et où il faudra les mettre à niveau plus tard. J’aurais voulu plusieurs bases de données dans une seule instance, mais cette architecture n’est pas une option

  • Ça vaut la peine de regarder les outils et bibliothèques OTEL(OpenTelemetry), ou la stack Grafana avec Prometheus, Tempo et Loki
    La journalisation centralisée et le traçage des appels de service/de l’exécution du code ne sont pas nouveaux. Mais ils sont souvent repoussés à plus tard, jusqu’à ce qu’on se retrouve dans ce genre de situation désagréable
    Comme les bons outils n’ont pas été mis en place dès le départ, l’équipe devient plus petite et plus contrainte, puisqu’elle sait peu de choses, voire rien, sur ce que font les services
    Les instances de base de données peuvent être mises à niveau une par une. Sauf s’il y a des bugs graves, de sécurité par exemple, il n’y a pas besoin de se presser juste parce qu’une mise à niveau est possible
  • Je me demande si vous n’utilisez pas le cloud. Les fournisseurs cloud proposent une journalisation centralisée, donc si vous transmettez un ID de requête entre les services et l’incluez dans les entrées de log, vous pouvez suivre les requêtes entre services

• Lire ce genre de texte me fait étrangement l’effet d’une thérapie. Il y a dix ans, je disais déjà la même chose haut et fort, mais on me traitait d’incrédule et on me disait de me taire
  Pardonnez-moi si le paradigme des « microservices » m’a laissé un goût amer. J’ai vécu ce qui arrive quand on adopte complètement une technologie à la mode sans en comprendre pleinement les compromis
  Il y a longtemps, quand j’ai été embauché chez StumbleUpon, c’était la période où un soi-disant docteur en informatique de premier plan voulait remplacer le monolithe PHP qui fonctionnait bien et générait des revenus par une architecture de microservices Scala/Java
  Le processus d’onboarding des nouveaux employés incluait même un étrange tête-à-tête avec ce fou d’informaticien ; il expliquait avec passion les avantages des microservices et esquivait habilement les questions du genre « pourquoi créer un service distribué juste pour additionner une liste de nombres ? » d’un geste signifiant « tu ne comprendrais pas pourquoi c’est tellement mieux »
  Après plus de 30 nouvelles embauches et plus de quatre ans de développement intensif, l’entreprise, qui n’était plus rentable, n’avait plus qu’un enfer distribué plus lent, rempli de bugs et impossible à déboguer
  Le concepteur et architecte en chef a jugé que c’était le bon moment pour partir en « année sabbatique », et peu après, une énième levée de fonds s’est épuisée et tout le monde s’est retrouvé à chercher du travail

• Cet article, pour reprendre la métaphore d’Amtrak, a complètement déraillé
  L’auteur part du principe que si l’on a créé de mauvais microservices, il aurait suffi de faire un monolithe pour que, comme par magie, tout se passe bien
  Même avec le même niveau de conception et d’ingénierie ayant produit des microservices médiocres, il suggère que viser un monolithe aurait donné un résultat en or
  Il y a aussi beaucoup d’autosatisfaction tout au long du texte, par exemple dans les commentaires sur les développeurs JS full-stack
  Mais il y a très peu de contenu relevant réellement de l’ingénierie. On pourrait s’attendre à des mesures ou à des données, mais on n’obtient que de longues tirades
  Gérer la complexité pour maintenir faible le coût des changements système est un bon objectif, mais ce n’est pas ce que propose cet article
  S’il l’avait reconnu, ou s’il avait présenté des données, voire au moins une anecdote, le texte aurait été meilleur
  Dans notre équipe, je choisirais un développeur frontend brillant et enthousiaste qui veut élargir son horizon et devenir développeur full-stack, plutôt que quelqu’un qui pense déjà tout savoir et n’a plus rien à apprendre

  • La dichotomie proposée est tellement simpliste qu’elle fait douter de la crédibilité de l’auteur. Quelle que soit l’architecture, si elle n’est pas correctement maintenue, elle devient avec le temps un fardeau écrasant
  • L’autre face de la pièce vaut tout autant. Si l’on a créé un monolithe médiocre, affirmer qu’il aurait suffi de faire des microservices pour que, comme par magie, tout aille bien revient au même

• À mon poste actuel, je lutte contre cette tendance ; avec un certain succès dans certaines équipes, beaucoup moins dans d’autres. Ces équipes se battent maintenant avec le monolithe distribué qu’elles ont elles-mêmes créé
  Ironiquement, les anciens de FAANMG sont tous plutôt favorables au monolithe
  Beaucoup de gens semblent oublier que les microservices sont le résultat d’un processus itératif. Au final, on extrait du monolithe les parties qui doivent passer à l’échelle
  Les microservices exigent beaucoup d’infrastructure de base qu’on n’a pas envie de maintenir tant qu’on n’en a pas besoin
  La plupart des entreprises n’ont même pas la plateforme adéquate pour prendre en charge ce modèle

• Je suis d’accord. Dans mon entreprise, les outils fonctionnent tellement mal que nous avons carrément abandonné le débogage
  Pour exécuter un seul service sur une machine locale, il faut configurer les 9 autres pour qu’ils s’y connectent
  Et si l’on crée une « fonctionnalité » pour un client, il faut bien sûr toucher au moins 2 services en même temps afin de déplacer davantage de données
  Si l’on place un point d’arrêt d’un côté, l’autre côté expire
  Résultat : tous les développeurs déploient des builds de release dans une VM locale, ajoutent des console.log, System.PrintLines() et _logger sans hot reload, puis lisent des fichiers de logs éparpillés
  Évidemment, je compte quitter le navire

  • Le troisième paragraphe pourrait au moins être amélioré dans une certaine mesure si tout était converti en logs structurés et pouvait être envoyé vers un agrégateur local
    Tout passer en traçage distribué serait encore mieux, mais pour suivre correctement les requêtes, il faudrait uniformiser les métadonnées de traçage partout, ce qui représente un investissement plus important
    Cela aiderait probablement davantage l’exploitation que le développement, mais ce serait tout de même utile. Rien que des informations de spans correctes donnent déjà beaucoup d’insights pour comprendre le chaos
    Si un point d’arrêt d’un côté provoque un timeout de l’autre, je me demande s’il n’existe pas un moyen d’augmenter ou de désactiver les timeouts en mode développement
  • Nous utilisons mirrord avec un environnement de staging pour n’exécuter qu’un service donné sans lancer toute la stack en local. Comme nous n’avons qu’environ 5 services, ce n’était déjà pas un gros problème à la base
  • Il y a Telepresence