- Critique du recours à une architecture système inutilement complexe malgré un faible nombre d’utilisateurs réels
- Présentation d’un cas où diverses technologies comme Redis, MongoDB, Kubernetes et les microservices ont été combinées sans discernement
- Mise en avant du fait qu’une instance Postgres unique et une configuration serveur simple auraient largement suffi
- Rappel que la complexité n’est pas une vertu et qu’il ne faut faire évoluer l’architecture que lorsque le besoin est démontré
- Un rappel pour les startups et les équipes de développement de respecter des principes de conception simples adaptés à leur échelle
Abus d’une pile technologique inutilement lourde
- Critique d’une combinaison de technologies choisies au hasard, comme l’utilisation simultanée de Redis et MongoDB
- Questions posées : « Pourquoi Redis parle-t-il à MongoDB ? », « Pourquoi utiliser MongoDB ? »
- Il est souligné qu’un système distribué a été mis en place alors qu’il n’y avait que 12 utilisateurs réels, dont 6 comptes de test
- L’article cite ce cas comme un exemple de surdimensionnement alors qu’une simple instance Postgres unique aurait suffi
Excès dans le déploiement et l’infrastructure
- Configuration actuelle : 15 microservices, 8 bases de données, un cluster Kubernetes sur 3 environnements, 4 files de messages, un service mesh, un pipeline CI/CD de 2 heures
- Comme configuration réellement nécessaire, seuls sont évoqués un serveur unique, Postgres et éventuellement Redis pour le cache
- Le contraste avec les besoins réels met clairement en évidence un niveau excessif de complexité de l’infrastructure
Complexité du système et capacité à l’expliquer
- Il est souligné que si expliquer le système à un développeur junior nécessite un diagramme embrouillé façon spaghetti, c’est qu’il y a un problème
- Le message central est résumé par la phrase : la complexité n’est pas une vertu
- Il faut commencer simplement, puis n’ajouter de la complexité que lorsque le besoin est prouvé
Enseignements clés
- Les choix technologiques et la conception du système doivent être simplifiés en fonction de l’échelle et de l’usage réel
- L’extension sans discernement et l’adoption excessive d’une pile technologique nuisent à la maintenabilité et à l’efficacité
- Pour les startups ou les petites équipes, il est important de préserver une simplicité adaptée à leur taille
1 commentaires
Avis Hacker News
Parfois, ce genre de comportement ressemble simplement à de la procrastination
On évite de parler à des clients, investisseurs ou juristes, et à la place on fait quelque chose de « intéressant » du point de vue d’un ingénieur
En apparence, ça a l’air productif, mais en réalité on fait du sur-place
Si on ne fait pas volontairement un peu de travail inconfortable chaque jour, on finit par régresser et par se retrouver plus tard face à de gros problèmes qu’on aurait pu éviter
Cela vaut autant pour le logiciel que pour la vie en général
J’ai appris que pour gagner de l’argent, il faut faire ce qui est prioritaire, pas ce qui est amusant
Je me demande si ce n’est pas plutôt une façon de satisfaire le goût pour l’architecture idéale d’un CTO ou d’un VPE déconnecté de la réalité
Je me souviens d’entretiens de design système où il fallait lire entre les lignes sur le sujet monolithe vs microservices
Au final, les gens qui ont du pouvoir ont une direction bien précise en tête, et aller contre revient à brûler du capital politique
Ils déroulent leur stack technique avec des phrases du genre « j’ai connecté ABC avec XYZ »
Il y a aussi l’envie de rendre son CV plus impressionnant
En réalité, la plupart des projets pourraient très bien être réalisés avec des technologies des années 1990, mais dès qu’on ajoute des mots comme systèmes distribués, ça paraît beaucoup plus « cool »
À cause d’une mauvaise culture du recrutement dans le secteur, on se retrouve dans une situation où un cuisinier n’est pas jugé sur sa maîtrise du couteau, mais sur le fait d’utiliser « une certaine marque de couteau »
Par exemple, DuckDuckGo demande seulement des connaissances en algorithmes et structures de données, en précisant juste « au fait, on utilise Perl »
Stream propose un cursus de 10 semaines aux candidats qui ne connaissent pas Go, et Jane Street n’exige pas non plus d’expérience en OCaml
Chez bevuta IT GmbH, où je travaille, on m’a aussi permis d’apprendre Clojure après mon arrivée
Cette approche n’a rien à voir avec les annonces vieillottes du type « 10 ans d’expérience en Ruby on Rails »
Parce que j’avais envie d’essayer de nouvelles choses et de les comparer
Au final, la réalité du secteur, c’est qu’on bavarde d’une complexité inutile pour quelques centaines d’utilisateurs
L’expression « mise en cache avec Redis » est devenue trop courante, alors qu’en réalité Postgres suffit souvent
Si quelqu’un propose Redis à tout prix, c’est peut-être que lui aussi n’a pas résisté à son envie d’overengineering
À petite échelle, il n’y a souvent pas besoin de cache, et il est plus séduisant de placer les données temporaires dans un système séparé
Les abstractions de cache des frameworks sont d’ailleurs généralement pensées avec Redis en tête
Mieux vaut commencer avec un cache en mémoire, puis ajouter Redis si le besoin apparaît
Mais Redis/Valkey, c’est excessif. memcached est bien plus simple et plus pragmatique
Comme il ne persiste pas l’état comme Redis, on évite les mauvais patterns de conception qui dépendent de la cohérence du cache
Un cache en base de données est lent car il doit passer par le système de fichiers
Écrire des requêtes efficaces est un tout autre sujet
Une fois Postgres redevenu rapide, on pourrait retirer Redis, mais en général on le laisse
Sur une webapp basée sur AWS Lambda traitant 1 000 requêtes par seconde, Postgres peinait alors que Redis tenait sans problème
Sa simplicité en fait un cas d’usage qui vaut vraiment le coup
C’est amusant de voir l’auteur défendre la « simplicité » tout en construisant sa page avec Tailwind + framework JS + bundler
Il aurait aussi pu la faire en HTML simple
Je présente donc MastroJS, un framework web simple qu’on peut comprendre et fabriquer soi-même
En pratique, il ne génère en CSS que les classes utilitaires utilisées
Le tweet original vient en fait d’un tweet de Jeff Atwood en 2013
En ce moment, je réfléchis moi aussi à un choix similaire
Si le produit n’a pas encore été validé par le marché, il faut commencer petit et vite, pour créer un MVP capable de pivoter
En revanche, s’il faut montrer à des investisseurs ou à de grands groupes une capacité à concevoir pour le passage à l’échelle, alors il faut choisir dès le départ une structure scalable
Si le modèle économique n’est viable qu’à condition d’atteindre une taille qu’une base unique ne peut pas supporter, alors partir sur une architecture extensible dès le début est plus avantageux à long terme
Quand on travaille au milieu d’un cauchemar d’infrastructure, la simplicité peut sembler illusoire
Mais une grande partie de la complexité sert moins à résoudre des problèmes techniques qu’à répondre à des problèmes organisationnels
Automatisation des déploiements, redondance pour la résilience, pipeline CI, gestion des secrets, cache : tout cela sert de garde-fou pour protéger l’équipe
Ignorer ces éléments est risqué quand on travaille à l’échelle d’une équipe
Même SQLite peut parfaitement convenir en production, malgré le préjugé selon lequel ce ne serait « bon que pour les tests »
Les configurations par défaut des PaaS sont elles aussi souvent inutilement complexes
On peut commencer par un processus de build basé sur une checklist, puis l’automatiser une fois qu’il est stable
J’aimerais voir de vrais cas où des microservices sont réellement nécessaires en dehors d’un niveau FAANG
Beaucoup suivent simplement des stacks techniques standard parce qu’ils ont peur de réfléchir
Le problème, c’est l’usage non critique de Kafka, Mongo, Redis et autres
En réalité, il vaut souvent mieux implémenter directement uniquement les fonctionnalités nécessaires, et la capacité à choisir le nombre minimal de composants est au cœur du métier d’ingénieur
Des outils comme Kafka sont souvent une pure perte d’argent
La phrase « n’ajoutez de la complexité que lorsque c’est nécessaire » est juste, mais il y a des cas où l’ajouter plus tard est difficile
Si la conception initiale est mauvaise, cela peut exiger une réécriture complète
En pratique, il faut donc parfois un compromis comme une configuration k8s simple
J’ai eu une expérience similaire lors d’un entretien récent
Pendant 10 ans, je me suis concentré sur l’obtention du PMF (Product-Market Fit), pas sur l’obsession de la scalabilité dès le départ
Quand un produit trouve son marché, on peut résoudre les problèmes de montée en charge avec de l’argent
Mais en entretien, on m’a demandé « comment faire passer un service Django à 10 millions de requêtes par jour »
J’ai répondu « il suffit d’augmenter les specs du serveur », et cela n’a visiblement pas satisfait mon interlocuteur