Comment décider si les microservices sont le bon choix

L’architecture par défaut devrait être un monolithe modulaire

Pour la plupart des entreprises qui développent des logiciels en 2026, le point de départ le plus judicieux n’est pas les microservices. Il s’agit d’un monolithe modulaire. Cela peut sembler moins passionnant, mais les décisions techniques doivent être guidées par les résultats.

Un monolithe modulaire permet de conserver l’application sous la forme d’un système unique déployable, doté d’une seule base de données et d’un seul pipeline de livraison. Au sein de ce système, cependant, chaque domaine métier est divisé en modules bien définis, dont la responsabilité est clairement établie et les limites strictement délimitées. Un module expose ses fonctionnalités via des interfaces internes et gère ses propres données sans autoriser d’accès direct depuis d’autres modules. Cela permet d’instaurer une discipline dès le départ, tout en conservant la simplicité des opérations.

Le principal avantage réside dans le fait que la complexité reste proportionnelle à l’activité. Tout système distribué engendre des coûts opérationnels dès le premier jour. Vous avez besoin d’une découverte de services, d’une surveillance couvrant plusieurs services, de communications réseau, d’une orchestration des déploiements, d’une sécurité entre les services, ainsi que d’ingénieurs maîtrisant les systèmes distribués. Ces coûts existent avant même que la moindre valeur commerciale ne se manifeste.

De nombreuses organisations n’atteignent jamais une taille suffisante pour que ces coûts soient justifiés.

Une architecture monolithique modulaire offre aux dirigeants un atout précieux : la flexibilité. Si une fonctionnalité métier doit à terme évoluer de manière indépendante ou être gérée par sa propre équipe d’ingénieurs, ce module pourra être extrait ultérieurement pour devenir un service à part entière. Si ce moment ne survient jamais, l’entreprise évite ainsi des années de dépenses opérationnelles inutiles.

Cette approche améliore également la vitesse d’exécution. Les ingénieurs déploient une seule application au lieu de devoir coordonner les mises en production entre de nombreux services. Le dépannage est plus rapide, car les défaillances restent confinées à un seul déploiement. Les coûts d’infrastructure restent plus faibles, car il y a moins d’éléments à gérer.

D’un point de vue commercial, cela revêt une importance particulière, car l’architecture logicielle relève d’un choix d’ingénierie. Mais cela a également une incidence directe sur le recrutement, les coûts d’exploitation, la rapidité de livraison des produits et la flexibilité organisationnelle. Chaque service supplémentaire nécessite une prise en charge, une surveillance, une documentation, des audits de sécurité et une maintenance à long terme. Ces investissements doivent générer une valeur commerciale mesurable.

Martin Fowler a abordé cette question de front dans son article de 2015 intitulé « Microservice Premium ». Il y fait valoir que les systèmes distribués entraînent un coût opérationnel immédiat, et que ce coût ne s’avère rentable qu’une fois que l’organisation a atteint une taille et une complexité suffisantes. Avant cela, les microservices ralentissent souvent le développement, mobilisent des ressources d’ingénierie et nécessitent des talents expérimentés qui pourraient être affectés à d’autres tâches.

David Heinemeier Hansson (DHH), cofondateur de Basecamp et créateur de Ruby on Rails, parvient à une conclusion similaire dans son article intitulé « The Majestic Monolith ». Il affirme que de nombreuses équipes étaient convaincues que les microservices constituaient la solution par défaut, alors que ce n’était pas le cas. Basecamp prend en charge plusieurs plateformes tout en continuant à fonctionner comme une application monolithique modulaire avec une équipe d’ingénieurs relativement réduite. Cette architecture est restée efficace car elle répond aux besoins réels de l’entreprise plutôt qu’à ses besoins anticipés.

Pour les dirigeants, cela soulève une question simple.

Vous attelez-vous à résoudre les problèmes actuels de votre entreprise, ou vous préparez-vous à faire face à des problèmes qui ne se poseront peut-être jamais ?

La réponse devrait déterminer votre architecture.

L’adoption des microservices nécessite un cadre décisionnel structuré

La décision d’adopter les microservices ne doit jamais être motivée par des considérations technologiques. Elle doit partir de conditions commerciales mesurables.

Élaborez un cadre pratique articulé autour de cinq axes : l’autonomie des équipes, l’indépendance de déploiement, les exigences en matière d’évolutivité, la propriété des données et la maturité organisationnelle. Ensemble, ces éléments permettent de déterminer clairement si les avantages des microservices l’emportent sur leur coût opérationnel.

La première dimension est l’autonomie des équipes. Les microservices fonctionnent au mieux lorsque plusieurs équipes d’ingénieurs sont responsables de différents domaines métier et doivent agir de manière indépendante. Si une ou deux équipes seulement développent l’ensemble du produit, le fait de diviser l’application en dizaines de services entraîne généralement davantage de coordination, et non l’inverse.

La deuxième dimension est l’indépendance vis-à-vis des déploiements. Posez-vous une question simple : les lancements de produits sont-ils retardés parce que différentes équipes doivent se coordonner à chaque déploiement ? Si la réponse est oui, des services indépendants pourraient éliminer ce goulot d’étranglement. Si les déploiements se déroulent déjà sans heurts, l’introduction de systèmes distribués n’apportera peut-être que peu de valeur ajoutée.

La troisième dimension est l’évolutivité. Toutes les parties d’une application ne sont pas soumises à la même demande. Un système de paiement, un moteur de recommandation ou un processus de paiement peuvent nécessiter nettement plus de ressources informatiques que d’autres fonctionnalités. Si le fait de faire évoluer l’ensemble de l’application pour prendre en charge un composant très sollicité entraîne un gaspillage des dépenses d’infrastructure, la séparation de ce composant peut s’avérer économiquement intéressante.

La quatrième dimension est la propriété des données.

Chaque service doit avoir la pleine maîtrise de ses données. C’est l’une des principales raisons justifiant l’adoption des microservices. Les différents domaines d’activité ont souvent des besoins de stockage distincts. Les données financières peuvent nécessiter un certain type de base de données, la recherche un autre, l’analyse un autre encore, et la gestion des sessions un autre enfin. Lorsque ces différences prennent une importance opérationnelle, les services indépendants offrent une flexibilité sans imposer à toutes les charges de travail d’utiliser la même technologie.

La cinquième dimension est la maturité opérationnelle.

On a souvent tendance à sous-estimer ce point.

Les microservices partent du principe que l’entreprise dispose déjà de systèmes d’ingénierie aboutis. L’intégration continue et la livraison continue (CI/CD), la surveillance, le traçage distribué, la gestion des incidents, la gestion des API, l’orchestration des conteneurs et des modèles de responsabilité fiables doivent déjà être en place. Les microservices ne créent pas l’excellence opérationnelle. Ils en ont besoin.

L’un des messages les plus marquants est que les entreprises évaluent souvent leur avenir plutôt que leur présent. Les dirigeants imaginent à quoi pourrait ressembler l’organisation dans trois ans et mettent immédiatement en place les structures nécessaires à cet avenir.

C’est généralement une erreur.

L’architecture doit répondre à des besoins métier avérés. Les logiciels évoluent bien plus efficacement lorsque la complexité n’est introduite qu’une fois qu’elle devient nécessaire.

Ce cadre traduit cette philosophie à travers trois résultats concrets.

Si la plupart des dimensions reçoivent une réponse « Oui », certains domaines métier spécifiques peuvent justifier leur extraction pour former des services indépendants. Il est important de noter que seules ces dimensions doivent être extraites.

Si la plupart des dimensions sont « Pas encore », il est recommandé de conserver une architecture monolithique modulaire tout en imposant des limites strictes entre les modules. Cela permet de préserver la flexibilité future sans alourdir la charge opérationnelle actuelle.

Si la plupart des critères sont « Non », l’entreprise devrait conserver une architecture monolithique et investir en priorité dans ses infrastructures techniques. De meilleurs pipelines de déploiement, une répartition des responsabilités plus claire, une surveillance renforcée et des pratiques opérationnelles éprouvées génèrent bien plus de valeur que la mise en production prématurée d’une application.

Pour les équipes de direction, ce cadre change la donne.

La question n’est plus : « Devrions-nous adopter les microservices ? »

La question qu’il convient plutôt de se poser est la suivante : « Quelle capacité métier spécifique justifie cette complexité supplémentaire ? »

Ce n’est que lorsqu’il existe une réponse claire qu’il convient d’extraire un service. Tout le reste doit rester là où il génère le plus de valeur : au sein d’un monolithe modulaire bien structuré.

Le recours aux microservices se justifie lorsqu’il s’agit de répondre à des enjeux spécifiques en matière d’évolutivité, d’autonomie et d’efficacité

Les microservices ne tirent pas leur valeur du fait qu’ils soient modernes. Ils ont de la valeur lorsqu’ils permettent de résoudre un véritable problème opérationnel.

Trop d’organisations partent de l’architecture au lieu de se concentrer sur le problème. La meilleure approche consiste à identifier les points où le système actuel génère des frictions mesurables. S’il n’y a pas de frictions significatives, la mise en place de services distribués ne fait qu’accroître la complexité opérationnelle sans créer de valeur métier significative.

L’une des principales raisons d’adopter les microservices réside dans l’évolutivité de l’organisation.

À mesure que les entreprises se développent, les équipes d’ingénieurs se spécialisent naturellement davantage. Différentes équipes se voient confier différentes capacités métier, chacune disposant de sa propre feuille de route, de ses propres priorités et de son propre calendrier de déploiement. Lorsque ces équipes doivent constamment attendre les unes les autres avant de déployer de nouvelles fonctionnalités, le rythme de livraison ralentit. Les services indépendants permettent à chaque équipe de déployer des modifications selon son propre calendrier, sans affecter les autres parties de l’entreprise qui ne sont pas concernées.

Ce phénomène est étroitement lié à la loi de Conway, selon laquelle l’architecture logicielle tend à refléter la structure de communication de l’organisation. Si l’organisation fonctionne grâce à plusieurs équipes autonomes aux responsabilités clairement définies, les microservices peuvent renforcer cette structure. Si ces équipes n’existent pas encore, la fragmentation du système engendre généralement un surcroît de travail de coordination au lieu de l’éliminer.

L’indépendance vis-à-vis du déploiement constitue un autre indicateur important.

De nombreuses organisations sont confrontées à des goulots d’étranglement au niveau des mises en production, car les modifications de schéma, les bibliothèques partagées ou le code étroitement couplé obligent plusieurs équipes à se coordonner pour chaque déploiement. À long terme, cela ralentit le rythme de développement du produit et retarde les améliorations destinées aux clients. Les microservices apportent une solution à ce problème en permettant à des domaines métier bien définis d’évoluer de manière indépendante, à condition que les services soient véritablement découplés.

Les exigences en matière d’évolutivité constituent une autre justification évidente.

La demande pesant sur les différentes composantes d’une application est rarement uniforme. Lors d’événements de forte affluence, un service de paiement en ligne peut enregistrer des niveaux de trafic dix, voire cent fois supérieurs à ceux générés par la consultation du catalogue. Adapter l’ensemble de l’application pour prendre en charge une seule charge de travail à forte demande entraîne une augmentation inutile des dépenses d’infrastructure. En isolant cette charge de travail dans un service dédié, vous pouvez allouer les ressources informatiques là où elles génèrent le meilleur rendement.

La propriété des données est l’un des arguments les plus convaincants en faveur des microservices.

Les différents domaines d’activité nécessitent souvent des technologies de persistance différentes. Un registre financier peut privilégier la cohérence et la traçabilité. Les fonctionnalités de recherche peuvent s’appuyer sur Elasticsearch pour une indexation et une récupération rapides. La gestion des sessions peut recourir à Redis en raison de sa rapidité. Les charges de travail analytiques peuvent tirer parti de ClickHouse, tandis que les données métier transactionnelles peuvent continuer à utiliser PostgreSQL.

Les microservices permettent à chaque domaine de choisir la technologie la mieux adaptée à ses besoins opérationnels, au lieu d’imposer à toutes les charges de travail l’utilisation d’une seule et même plateforme de base de données.

Cette flexibilité ne crée toutefois de la valeur que lorsque les domaines métier sont véritablement indépendants. Si les services échangent constamment des données, partagent des bases de données ou nécessitent des mises à jour synchronisées, l’avantage architectural disparaît en grande partie.

Il existe plusieurs raisons qui ne devraient en aucun cas motiver la mise en place d’une initiative de microservices.

Des affirmations telles que « les microservices sont modernes », « notre base de code devient de plus en plus volumineuse » ou « Netflix utilise des microservices » ne constituent pas des justifications commerciales. Elles décrivent des tendances ou des préférences du secteur plutôt que des problèmes opérationnels mesurables.

Pour les dirigeants, cette distinction est importante.

Les investissements technologiques doivent permettre de résoudre des contraintes identifiables qui pèsent sur la croissance, l’expérience client, la productivité des équipes d’ingénierie ou les coûts d’exploitation. Si ces contraintes n’existent pas, la mise en place de microservices ne fait qu’accroître la complexité à long terme sans générer de valeur commerciale proportionnelle.

Les organisations ne doivent justifier l’extraction d’un service que si au moins une condition d’éligibilité est remplie à ce jour ou devrait l’être dans les 12 à 18 prochains mois. Une planification fondée sur des besoins futurs hypothétiques n’est pas suffisante.

Cette approche rigoureuse permet à l’architecture de rester en phase avec la réalité de l’entreprise plutôt qu’avec les tendances du secteur.

Une échelle insuffisante et un manque de maturité opérationnelle constituent des obstacles à une mise en œuvre efficace des microservices

L’une des erreurs les plus coûteuses commises par les organisations est de partir du principe que l’adoption des microservices améliorera la maturité technique.

Ce n’est pas le cas.

Les microservices amplifient à la fois les points forts et les points faibles. Si une organisation fonctionne déjà efficacement, les services distribués peuvent accroître sa flexibilité. Si les pratiques opérationnelles présentent des lacunes, ces faiblesses deviennent nettement plus visibles et beaucoup plus difficiles à gérer.

Chaque service indépendant implique des responsabilités permanentes.

Chaque service doit disposer de son propre pipeline de déploiement, de ses propres systèmes de surveillance et de journalisation, de ses propres contrôles de sécurité, de sa propre stratégie de test, de sa propre documentation, de son propre processus de gestion des incidents et d’une responsabilité clairement définie. Les ingénieurs doivent comprendre leur propre code et la manière dont les défaillances se propagent au sein d’un environnement distribué.

À mesure que le nombre de services augmente, la charge de travail opérationnelle s’alourdit également.

Pour les petites équipes d’ingénieurs, cela représente un véritable défi. Un nombre limité d’ingénieurs peut se retrouver à devoir assurer la maintenance de plusieurs services simultanément, tout en restant chargés du développement de nouvelles fonctionnalités. Les connaissances se fragmentent, et le départ d’un seul ingénieur peut priver des services essentiels de l’expertise nécessaire.

Les avantages des microservices ne se concrétisent que lorsque les organisations sont en mesure d’attribuer à chaque service une responsabilité spécifique à long terme.

La maturité opérationnelle revêt une importance tout aussi grande.

Avant de mettre en place des services distribués, les organisations doivent déjà disposer de systèmes fiables d’intégration continue et de livraison continue (CI/CD), d’un système de surveillance complet, d’un traçage distribué, de pratiques cohérentes en matière d’astreinte, d’une gestion des API, d’un équilibrage de charge et d’une orchestration des conteneurs.

Ces fonctionnalités ne constituent pas des ajouts facultatifs après la migration. Il s’agit de conditions préalables.

Sans eux, le diagnostic des problèmes de production devient nettement plus difficile, car les requêtes transitent par plusieurs systèmes indépendants au lieu de rester au sein d’une seule application.

Les nouveaux produits font généralement l’objet de changements fréquents au niveau des exigences métier. Les équipes ne cessent d’approfondir leurs connaissances sur les clients, les flux de travail, les modèles de tarification et les fonctionnalités des produits. À mesure que cette compréhension évolue, les limites métier changent naturellement.

Définir trop tôt les limites définitives des services conduit souvent à une décomposition inadéquate. Dès lors que les services communiquent au-delà des frontières du réseau, la modification de ces limites devient nettement plus coûteuse que la réorganisation des modules au sein d’une même base de code.

C’est l’une des raisons pour lesquelles il est préférable de commencer par un monolithe modulaire. Les frontières internes peuvent évoluer à mesure que l’entreprise acquiert davantage de connaissances, tandis que la complexité opérationnelle reste gérable.

Ce n’est qu’une fois que les domaines d’activité se seront stabilisés que les organisations devraient envisager de mettre en place des services autonomes.

Sam Newman, auteur de *Building Microservices*, a insisté sur ce point lors de la conférence QCon London en 2020, en déclarant que « les microservices ne devraient pas constituer le choix par défaut ». Sa position rejoint étroitement celle de Martin Fowler et David Heinemeier Hansson, malgré leurs parcours et leurs expériences différents. Tous trois concluent qu’une adoption prématurée engendre souvent des coûts inutiles sans apporter les avantages commerciaux correspondants.

Pour les dirigeants, l’enseignement stratégique à en tirer est clair.

Avant de financer une transformation architecturale d’envergure, évaluez si l’organisation a mis en place la discipline opérationnelle nécessaire pour la soutenir. Les investissements dans l’automatisation du déploiement, la surveillance, la prise en charge, l’ingénierie de la fiabilité et la visibilité sur l’environnement de production génèrent souvent un meilleur retour sur investissement que la mise en place prématurée de services distribués.

L’architecture doit s’adapter à la maturité de l’organisation, et non tenter de la créer.

Des microservices mal mis en œuvre peuvent se transformer en monolithes distribués

Le passage aux microservices ne garantit pas automatiquement la mise en place d’un système indépendant et évolutif. Dans de nombreux cas, les entreprises se retrouvent avec ce que l’on appelle un « monolithe distribué ». Il s’agit là d’un des scénarios les moins souhaitables, car il combine le coût d’exploitation des systèmes distribués avec le couplage étroit propre à un monolithe traditionnel.

La caractéristique principale d’un monolithe distribué réside dans le fait que les services ne peuvent pas fonctionner de manière véritablement indépendante.

L’un des signes avant-coureurs les plus évidents est l’utilisation d’une base de données partagée. Si plusieurs services lisent et écrivent dans les mêmes tables, ils ne sont plus maîtres de leurs propres données. Chaque modification du schéma nécessite une coordination entre les équipes, ce qui allonge les délais de mise en production et engendre des risques inutiles. Le déploiement indépendant devient difficile, car une modification destinée à un service peut avoir des répercussions inattendues sur un autre.

Les véritables microservices reposent sur une propriété claire des données. Chaque service doit contrôler ses propres données et les exposer via des interfaces bien définies. Dès que les services commencent à partager des bases de données, cette indépendance disparaît rapidement.

Les communiqués coordonnés constituent un autre signe d’alerte.

Si le déploiement du service A nécessite que les services B et C soient déployés dans un ordre précis, l’entreprise n’est pas parvenue à mettre en place un déploiement indépendant. Les équipes continuent de travailler de concert, mais elles doivent désormais également gérer les communications réseau, la compatibilité des versions et l’infrastructure distribuée. L’accélération attendue du rythme de livraison ne se concrétise jamais, car la coordination reste une exigence permanente.

Dans certaines implémentations, une seule requête client déclenche une séquence d’appels synchrones impliquant plusieurs services. Si un service subit une latence ou devient indisponible, toutes les requêtes qui en dépendent sont affectées. Au lieu d’isoler les défaillances, l’architecture les répartit à travers le système.

Cela a des répercussions directes sur l’activité. L’expérience client devient plus sensible aux problèmes d’infrastructure, et les équipes d’ingénieurs consacrent davantage de temps au diagnostic des pannes qui touchent plusieurs services.

Les transactions distribuées ajoutent un niveau supplémentaire de complexité.

Dans une application monolithique, une transaction de base de données permet souvent de garantir que soit toutes les opérations aboutissent, soit aucune n’aboutit. Dès lors que les données sont réparties entre plusieurs services, ces garanties ne s’appliquent plus au-delà des frontières entre les services. Les entreprises doivent alors gérer les transactions distribuées à l’aide de techniques telles que le modèle « Saga », dans lequel chaque transaction locale nécessite des actions de compensation en cas d’échec d’une partie du flux de travail global.

Bien qu’efficaces, ces modèles augmentent la charge de travail liée au développement, la complexité opérationnelle, les exigences en matière de tests et le risque d’incohérence temporaire des données. À mesure que de nouveaux services interviennent dans une transaction, la complexité ne cesse de croître.

Pour les dirigeants d’entreprise, il s’agit là d’un aspect important à prendre en compte, car la complexité architecturale n’a pas seulement des répercussions sur l’ingénierie. Elle influe également sur la rapidité de mise en œuvre, la fiabilité, les coûts d’exploitation et la capacité de l’organisation à s’adapter à l’évolution des priorités métier.

Au lieu de continuer à fragmenter le système en services plus petits, les organisations devraient commencer par regrouper les composants étroitement liés. L’objectif est de définir de véritables périmètres métier avant de procéder à une distribution plus poussée. Une fois que ces périmètres sont stables et indépendants, l’extraction sélective de services devient beaucoup plus aisée et nettement moins risquée.

Les microservices créent de la valeur grâce à leur indépendance. Si cette indépendance fait défaut, l’architecture supporte les coûts liés à la distribution sans en offrir les avantages.

Les limites des services doivent être définies en fonction des capacités métier

Une fois qu’une organisation a décidé qu’un service devait être extrait, la question suivante revêt une importance bien plus grande que ne le pensent de nombreuses équipes.

Où faudrait-il tracer la limite ?

Cette décision doit toujours partir des besoins de l’entreprise plutôt que de la technologie.

Eric Evans, auteur de *Domain-Driven Design*, préconise depuis longtemps de définir des limites autour des capacités métier plutôt qu’autour des couches techniques. Cette approche permet d’aligner la responsabilité du logiciel sur la manière dont l’organisation crée réellement de la valeur pour ses clients.

Une capacité métier correspond à une fonction métier complète, dotée d’un objectif précis et d’une responsabilité clairement définie.

Par exemple, un service utilisateur qui gère l’inscription, l’authentification, les profils utilisateur et la gestion des sessions constitue une capacité métier cohérente. Ces fonctions vont naturellement de pair, car elles contribuent à un seul et même résultat métier.

En revanche, la création de services articulés autour de couches techniques engendre souvent des problèmes à long terme. Un service chargé uniquement de l’accès à la base de données, par exemple, a tendance à devenir une dépendance partagée par de nombreux composants de l’application. Au fil du temps, cela renforce le couplage au lieu de le réduire et rend l’évolution indépendante beaucoup plus difficile.

Certaines charges de travail techniques présentent des caractéristiques opérationnelles qui diffèrent considérablement du reste de l’application. Les points de terminaison soumis à des interrogations à haute fréquence, les passerelles de messagerie entrante ou le traitement d’images très gourmand en ressources CPU peuvent justifier d’être exécutés sous forme de processus distincts, car leurs exigences en matière de performances ou de fiabilité sont particulières. Ces cas constituent des exceptions dictées par les caractéristiques des charges de travail plutôt que par des principes architecturaux généraux.

Plutôt que d’approuver la création d’un service sur la seule base de l’enthousiasme des ingénieurs, la direction peut exiger la preuve que le service proposé dispose d’un responsable métier clairement identifié, d’une responsabilité exclusive, d’une capacité de déploiement autonome et d’une résilience opérationnelle.

La correction de délimitations de services inadéquates après le déploiement constitue l’une des erreurs les plus coûteuses dans un programme de microservices. Une fois les services en production, la modification de ces délimitations a des répercussions sur les API, la propriété des données, les processus de déploiement, les procédures opérationnelles et les responsabilités organisationnelles.

Consacrer davantage de temps à la définition des limites avant l’extraction permet généralement d’éviter des mois de travail supplémentaire par la suite. Cela permet également de mettre en place une architecture logicielle capable d’évoluer au rythme de l’activité, sans nécessiter de refonte structurelle constante.

L’architecture de la citadelle offre une alternative hybride pratique

Les choix architecturaux ne se limitent pas nécessairement à deux options. Il existe une troisième option que de nombreuses organisations négligent : l’architecture Citadel.

Conçue par David Heinemeier Hansson (DHH), cofondateur de Basecamp et créateur de Ruby on Rails, l’approche « Citadel » consiste à conserver l’application principale sous la forme d’un monolithe modulaire tout en n’extrayant qu’un petit nombre de services spécialisés, appelés « avant-postes ». Ces avant-postes ne sont créés que lorsqu’une charge de travail particulière présente des exigences techniques qui diffèrent sensiblement de celles du reste de l’application.

Il s’agit là d’une distinction importante.

Cette décision ne repose pas sur des préférences organisationnelles ni sur des tendances architecturales. Elle repose sur des besoins opérationnels mesurables.

La majeure partie de la logique métier reste au sein du monolithe, où le développement, le déploiement et la maintenance restent simples. Seules les charges de travail présentant des exigences spécifiques en matière de performances, de disponibilité ou d’évolutivité sont séparées en services indépendants.

Campfire reposait sur le fait que les clients interrogeaient le serveur toutes les trois secondes pour vérifier s’il y avait de nouveaux messages. La plupart de ces requêtes ne renvoyaient aucune nouvelle information, mais elles généraient tout de même un trafic important. Le traitement de ces requêtes par l’ensemble de l’application Rails impliquait que chaque interrogation consommait des ressources qui n’étaient pas nécessaires pour une tâche aussi simple.

Au lieu de déployer l’application dans son intégralité, l’équipe d’ingénieurs a isolé uniquement le point de terminaison de sondage dans un service distinct. Ce point de terminaison traitant des volumes de requêtes extrêmement élevés, il a été réécrit au fil du temps à l’aide de plusieurs langages de programmation optimisés pour les performances, notamment le C, le C++, le Go et l’Erlang. Pendant ce temps, l’application Basecamp principale a continué à fonctionner comme une application monolithique Ruby on Rails.

HEY, le service de messagerie de Basecamp, en est un autre exemple.

Les e-mails entrants sont d’abord traités par Postfix, qui reçoit les messages, les stocke en toute sécurité sur le disque afin d’améliorer la résilience, puis les transfère via HTTP vers Action Mailbox au sein de l’application principale HEY. Cela permet de dissocier une charge de travail liée à une infrastructure spécialisée sans que le reste de l’application ait à devenir un système distribué.

Pour les dirigeants, cette approche constitue une stratégie équilibrée.

Les entreprises constatent souvent que seul un faible pourcentage de leurs charges de travail nécessite réellement une infrastructure indépendante. Le fait de ne séparer que ces charges de travail permet aux équipes d’ingénierie de résoudre des problèmes opérationnels ciblés tout en évitant la complexité importante liée à la répartition de chaque fonctionnalité métier.

L’architecture de la Citadelle garantit également une flexibilité stratégique.

Le monolithe reste le système d’enregistrement principal et continue d’évoluer normalement. Des « outposts » ne sont ajoutés que lorsque des exigences techniques mesurables le justifient. Cela réduit les coûts d’exploitation, simplifie la gouvernance et limite le nombre de composants distribués nécessitant une assistance continue.

D’un point de vue financier, cette approche peut également améliorer l’efficacité du capital.

Chaque service supplémentaire entraîne des coûts d’infrastructure, une surveillance opérationnelle, des pipelines de déploiement, une gestion de la sécurité et la prise en charge technique. En limitant l’extraction de services aux charges de travail qui génèrent une valeur opérationnelle évidente, les organisations concentrent leurs investissements là où le retour sur investissement est le plus élevé.

L’architecture doit évoluer progressivement. Les entreprises n’ont pas besoin de décomposer l’intégralité de leur application simplement parce qu’un composant présente des exigences de performance exceptionnelles. Résoudre le problème spécifique tout en conservant la simplicité du reste du système permet souvent d’obtenir de meilleurs résultats à long terme.

Le système VQA d’Amazon Prime Video montre que la consolidation peut permettre de réduire les coûts et d’améliorer l’évolutivité

Ce cas montre que même les organisations reconnues pour leur expertise dans l’exploitation de systèmes distribués à grande échelle ne considèrent pas les microservices comme la solution par défaut. Elles continuent au contraire à évaluer si une architecture est adaptée à la charge de travail qu’elle doit prendre en charge.

En mars 2023, Marcin Kolny, ingénieur chez Amazon Prime Video, a expliqué comment le système d’analyse de la qualité vidéo (VQA) avait été repensé pour passer d’une architecture distribuée sans serveur à une application monolithique consolidée.

Le service VQA analyse en permanence des milliers de flux vidéo en direct afin de détecter les problèmes de qualité tels que les blocages d’image, la corruption de blocs et les problèmes de synchronisation audio-vidéo. Lorsque des problèmes sont identifiés, le système met en œuvre des mesures correctives en temps réel.

L’architecture d’origine s’appuyait sur AWS Lambda pour le calcul, AWS Step Functions pour l’orchestration et Amazon S3 pour le transfert des images vidéo entre les différents composants de traitement.

Si cette architecture offrait des services indépendants et une évolutivité élastique, elle entraînait également des coûts d’exploitation importants à l’échelle de la production.

La facturation d’AWS Step Functions s’effectue en fonction des transitions d’état. Étant donné que VQA générait plusieurs transitions d’état pour chaque seconde de vidéo traitée, les coûts d’orchestration ont augmenté rapidement à mesure que le volume de charge de travail s’accroissait.

Les transferts entre les différentes étapes de traitement d’Amazon S3 ont entraîné une latence supplémentaire et multiplié les opérations de stockage. Au lieu de transmettre les données directement en mémoire, chaque étape nécessitait des opérations répétées de stockage et de récupération, ce qui a allongé le temps d’exécution et augmenté les coûts d’infrastructure.

Selon M. Kolny, ces choix architecturaux ont également entraîné des limites en matière d’évolutivité. Le système a atteint ses seuils d’évolutivité au niveau des comptes à environ 5 % de sa capacité de production prévue.

L’équipe d’ingénieurs a décidé de regrouper les composants de conversion de média, de détection des défauts et d’orchestration au sein d’une seule et même application fonctionnant sur Amazon EC2 et Amazon ECS.

Une fois les services regroupés, les données intermédiaires transitaient directement par la mémoire au lieu de passer à plusieurs reprises par le stockage externe. L’orchestration des flux de travail s’est également considérablement simplifiée, car de nombreuses opérations se sont transformées en appels directs de fonctions internes plutôt qu’en interactions entre services distribués.

Les résultats ont été considérables.

Selon M. Kolny, les coûts d’infrastructure ont baissé de plus de 90 %. Parallèlement, le système repensé a permis de dépasser largement les limites de l’architecture d’origine.

Au contraire, cela met en évidence un principe plus important.

Les choix technologiques doivent être adaptés aux caractéristiques de la charge de travail.

L’architecture d’origine permettait de résoudre des problèmes tels que la mise à l’échelle indépendante des fonctions et l’exécution hautement distribuée, mais ces capacités ne constituaient pas les principales contraintes de la charge de travail VQA. Parallèlement, cette architecture engendrait de nouveaux coûts liés à la surcharge d’orchestration, aux communications réseau et aux transferts de données, qui affectaient directement l’efficacité opérationnelle.

Pour les dirigeants, cette affaire vient renforcer un principe d’investissement important.

Les choix architecturaux doivent être évalués à l’aune de résultats métier mesurables, tels que les coûts d’exploitation, les performances du système, la productivité technique, l’évolutivité et l’impact sur les clients. Une technologie qui donne de bons résultats dans un environnement donné peut s’avérer inutilement coûteuse dans un autre si les exigences métier sous-jacentes diffèrent.

Le concept de « Microservice Premium » développé par Martin Fowler transparaît clairement dans cet exemple. Les systèmes distribués offrent des avantages significatifs lorsqu’ils permettent de résoudre de véritables problèmes métier. Lorsqu’ils n’y parviennent pas, le coût d’exploitation devient le facteur déterminant.

La leçon à retenir n’est pas de privilégier les architectures monolithiques au détriment des microservices, ni l’inverse.

La leçon à retenir est de choisir l’architecture qui apporte la plus grande valeur ajoutée à votre activité pour la charge de travail dont vous disposez réellement aujourd’hui, tout en conservant la flexibilité nécessaire pour évoluer à mesure que ces besoins changent.

Récapitulation

Le débat autour des microservices a mûri. La question n’est plus de savoir si les microservices représentent l’avenir. La question est de savoir s’ils permettent de résoudre le problème métier auquel vous êtes confronté aujourd’hui.

Pour les dirigeants, l’architecture relève en fin de compte d’un choix stratégique. Elle influe sur les coûts d’exploitation, la stratégie de recrutement, la rapidité de mise sur le marché des produits, la résilience et la capacité de l’organisation à s’adapter à mesure qu’elle se développe. Chaque choix architectural a des conséquences à long terme ; la complexité doit donc toujours se justifier.

Une architecture monolithique modulaire offre à la plupart des organisations le moyen le plus rapide de créer de la valeur tout en préservant leur flexibilité future. Elle permet aux équipes d’ingénierie de se concentrer sur le développement de produits plutôt que sur la gestion de l’infrastructure. Lorsque l’activité se développe, l’architecture peut évoluer en parallèle. Dans le cas contraire, l’entreprise évite de supporter des coûts d’exploitation qui ne génèrent jamais de retours significatifs.

Les microservices restent une approche extrêmement puissante, mais uniquement lorsque les conditions sont réunies. Des équipes autonomes, des besoins de déploiement indépendants, une responsabilité claire en matière de domaine, des différences significatives en termes d’évolutivité et des capacités opérationnelles abouties ne sont pas facultatives. Ce sont là les signes indiquant que l’organisation a atteint le stade où les systèmes distribués créent plus de valeur qu’ils n’en consomment.

Les dirigeants d’entreprise doivent également prendre conscience que les choix architecturaux ne sont pas immuables. Ils doivent être réexaminés à mesure que les produits, les équipes et les demandes des clients évoluent. L’architecture qui convient aujourd’hui ne sera peut-être plus la bonne dans trois ans. L’objectif n’est pas de prévoir toutes les exigences futures, mais de mettre en place une base permettant d’évoluer sans perturbation inutile.

Les organisations qui réussissent durablement sont rarement celles qui adoptent l’architecture la plus en vogue. Ce sont celles qui prennent des décisions rigoureuses, fondées sur des résultats commerciaux mesurables. Elles n’introduisent de la complexité que lorsque cela leur procure un avantage évident, et elles continuent à remettre en question leurs hypothèses à mesure que leur activité évolue.

C’est là le véritable objectif. Choisissez l’architecture qui correspond à votre situation actuelle, investissez dans des bases techniques solides et évoluez de manière réfléchie à mesure que votre organisation se développe. Lorsque les décisions technologiques restent en adéquation avec les besoins de l’entreprise, les performances techniques et commerciales s’améliorent de concert.