Architecturer et faire évoluer un backend : microservices ou monolithe ?
L'architecture de ton backend décide de la part de ta journée qui vire au combat. Au fur et à mesure que l'application grossit, les failles de tes premiers choix se voient. Tu arrives à un moment où il faut trancher. Tu gardes le monolithe, ou tu découpes tout en microservices ?
Il n'y a pas de solution miracle. Les deux approches ont leur place. Le bon choix dépend plus de la structure de ton équipe et du stade de ton entreprise que du mérite technique pur. Cet article passe en revue les deux options principales, plus un terrain d'entente pragmatique qui fonctionne très souvent.
L'idée derrière les microservices est simple. Au lieu de construire une application géante, tu construis une collection de services petits et indépendants. Chacun fait bien une seule chose.
Imagine une équipe décentralisée. Chaque service gère sa propre base de données et peut être déployé quand il est prêt, sans demander la permission aux autres. L'équipe de facturation peut utiliser Go pendant que l'équipe d'auth utilise Rust, et personne ne doit céder. Cette liberté rend les gens rapides. En théorie, du moins.
En pratique, ça convient aux grandes organisations, où coordonner une seule release entre 500 développeurs est un cauchemar.
Le monolithe est l'approche traditionnelle. Un seul code, une seule application, un seul déploiement. Tout vit ensemble, de l'interface utilisateur à la logique métier en passant par l'accès aux données.
Le mot "monolithe" est presque devenu un gros mot dans certains cercles. Il garde pourtant de vrais avantages. C'est simple. Tu n'as jamais besoin d'une carte pour trouver où une fonction est définie. Le déploiement tient en un seul script. Pour les petites et moyennes équipes, cette simplicité est un superpouvoir. Elle te permet d'avancer vite sans t'enliser dans la complexité de l'infrastructure.
Un anti-pattern fréquent dans les petites et moyennes entreprises, c'est de finir avec plus de microservices que d'ingénieurs. J'ai vu des organisations avec 100 ingénieurs tenter de maintenir plus de 300 services. Le résultat, c'est le chaos.
Une fois cette ligne franchie, beaucoup de services n'ont plus de propriétaire, ou les propriétaires héritent de services sur lesquels ils n'ont aucun contexte à cause des réorganisations. Tu passes aussi plus de temps à mettre à jour les dépendances dans tous les dépôts pour colmater les vulnérabilités. Des microservices bien faits exigent une équipe plateforme dédiée et un vrai investissement en outils. La plupart des startups n'ont pas les moyens de cette infrastructure, et leur architecture "agile" se transforme en cauchemar de maintenance.
Choisis une architecture parce qu'elle résout un problème que tu as vraiment. Les modes ne devraient pas entrer dans la décision.
Choisis les microservices si :
Choisis le monolithe si :
Voici un secret. Tu n'es pas obligé de passer directement aux microservices. Tu ne devrais probablement pas.
Le monolithe modulaire est un bon terrain d'entente. Tu construis une seule unité déployable, mais à l'intérieur tu imposes des frontières strictes entre les modules. Le code de Module A ne peut pas importer directement le code de Module B. Il doit passer par une interface publique définie. Tu obtiens l'organisation du code des microservices sans le coût d'infrastructure.
Au fur et à mesure que l'application grandit, tu détaches les parties qui doivent devenir indépendantes.
Le débat microservices contre monolithe rate généralement le sujet. La question n'est pas de savoir quelle architecture est meilleure en théorie. C'est de savoir quel ensemble de compromis tu peux supporter aujourd'hui.
Commence par un monolithe bien structuré. Découpe-le seulement quand la douleur apparaît. Ton futur toi-même et ton équipe DevOps te remercieront.
© Melvin Laplanche - All rights reserved.