Article
Avant les microservices : quatre solutions à essayer dans un monolithe
Charge élevée, livraisons fréquentes, équipes distinctes : un monolithe offre plusieurs réponses. Voici comment les évaluer et reconnaître leurs limites.
La génération de PDF ralentit les requêtes ordinaires. Une équipe veut livrer plus souvent. Un traitement instable affecte ses voisins. Ces problèmes peuvent justifier un service indépendant, mais plusieurs solutions existent dans un monolithe. Les comparer permet de choisir selon le besoin, avec une idée claire du coût ajouté.
Réserver des ressources aux traitements lourds
Un export volumineux et une consultation de page ne sollicitent pas le serveur de la même façon. Si chaque instance traite indifféremment les deux, les exports peuvent dégrader les temps de réponse des utilisateurs.
Une possibilité consiste à déployer le même artefact sur des lots d'instances différents. Le routeur envoie les exports vers un lot plus puissant ou dédié, et le trafic courant vers un autre.
Le code reste livré ensemble. Les échanges internes au processus restent locaux. Le dimensionnement et le routage deviennent, eux, plus précis.
Vous pouvez laisser les grosses instances absorber aussi le petit trafic, ou les réserver aux travaux lourds. La première option mutualise mieux les ressources ; la seconde limite davantage les interférences.
Cette solution demande de reconnaître le travail concerné et de vérifier les ressources partagées. Elle n'isole pas une base commune saturée ni un défaut qui s'exécute sur toutes les instances.
Réduire le risque des déploiements communs
Le blue-green prépare une nouvelle version sur un second ensemble d'instances, puis bascule le trafic. Un déploiement canari commence par une petite part du trafic pour observer la nouvelle version.
Ces approches peuvent limiter l'interruption et faciliter le retour à l'ancienne version. Elles demandent toutefois que les données et les échanges restent compatibles pendant la coexistence des versions.
Une migration de schéma destructive peut rendre le retour difficile. Prévoir des changements progressifs et compatibles fait donc partie du travail de livraison.
La limite reste importante : l'artefact est commun. La bascule devient plus sûre, mais une équipe ne choisit pas automatiquement son propre calendrier. Si la coordination des livraisons est devenue le principal frein, l'extraction peut apporter un bénéfice réel.
Donner à une équipe une responsabilité claire
Une équipe peut posséder un module, ses règles, ses tests et ses interfaces sans exploiter un processus séparé. Cette responsabilité lui donne une autonomie de conception.
Il faut distinguer cette autonomie de celle du déploiement. Un module compilé dans une application commune part avec cette application. Une équipe peut donc travailler de façon indépendante tout en partageant la livraison.
Examinez les délais réellement subis : revue de contrat, durée du build, validation commune ou attente d'une fenêtre de livraison. Certaines difficultés se traitent par les outils et l'organisation ; d'autres justifient une séparation.
La loi de Conway rappelle le lien entre organisation et architecture. Elle ne prescrit pas un service par équipe ni un nombre idéal de processus.
Limiter la propagation d'une surcharge
Des files de travail, des limites de concurrence et des lots d'instances dédiés peuvent éviter qu'un traitement occupe toutes les ressources. Un contrôle d'admission peut refuser temporairement du travail avant la saturation.
Pour une API HTTP, 503 Service Unavailable peut signaler une indisponibilité temporaire ou une surcharge. Une requête invalide relève d'une autre réponse. Cette distinction aide le client à décider s'il doit corriger sa demande ou réessayer.
Le routage ne protège que les charges qu'il sait distinguer. Une fuite mémoire dans du code exécuté partout peut encore affecter toutes les instances. Un service séparé offre une séparation de processus, mais ses quotas, son stockage et ses dépendances doivent aussi être examinés.
Reconnaître ce qui reste difficile dans un artefact commun
| Contrainte | Question utile |
|---|---|
| Un environnement spécialisé | Peut-on l'exploiter simplement avec l'application, ou demande-t-il un cycle de vie distinct ? |
| Un stockage différent | Le module peut-il y accéder directement tout en gardant le déploiement commun ? |
| Des livraisons indépendantes | Le contrat et les données permettent-ils réellement cette indépendance ? |
| Une isolation forte | Quelles ressources doivent être séparées pour contenir la panne ou limiter les accès ? |
Un monolithe peut utiliser plusieurs moteurs de stockage. Ce besoin ne rend donc pas, à lui seul, un service obligatoire. Un langage, un matériel ou une politique d'isolation particulière peut en revanche rendre la séparation plus simple à exploiter.
Je commence par la solution qui répond au problème avec le moins de composants à maintenir. Quand elle ne suffit plus, l'extraction d'un module devient une option à comparer sur des critères mesurables.
Laisser un commentaire
Votre commentaire sera relu avant d'être publié.