System Design

Dans les applications monolithiques traditionnelles, maintenir la cohérence des données entre plusieurs entités est simple. Les moteurs de bases de données relationnelles fournissent des garanties ACID (Atomicité, Cohérence, Isolation, Durabilité) enveloppées dans des transactions SQL locales. Si une commande, une déduction de paiement ou une réserve de stock échoue à mi-parcours, l’appel de ROLLBACK annule instantanément chaque modification de la base de données.

Dans l’architecture moderne axée sur les événements (Event-Driven Architecture), les microservices émettent en permanence des événements métier (OrderCreated, PaymentProcessed) pour communiquer de manière découplée. Cependant, publier un événement de façon 100% fiable pose un problème critique : Comment garantir que la mise à jour de la base de données et la publication de l’événement réussissent ou échouent ensemble ?

Dans une architecture de microservices, les services forment un réseau d’appels réseau distribués. Bien que cela permette aux équipes de créer et de faire évoluer les services de manière indépendante, cela signifie également que la fiabilité globale de votre système est aussi forte que son maillon le plus faible. Si un service critique tombe en panne ou ne répond plus, cela peut déclencher une panne en cascade qui perturbe l’ensemble de l’application.

Dans une architecture de microservices, les services communiquent via un réseau plutôt que via des appels en mémoire. Bien que ce découplage permette une mise à l’échelle horizontale massive et des déploiements indépendants, il introduit également une vulnérabilité majeure : le réseau n’est pas fiable. À tout moment, un service en aval peut rencontrer un bref problème de réseau, un pic temporaire du processeur, un conflit de verrouillage rapide de la base de données ou un redémarrage de mise à jour continue. Ces échecs temporaires sont appelés défauts transitoires.

Dans une architecture de microservices, une seule application est décomposée en dizaines ou centaines de services indépendants et collaboratifs. Bien que cette conception améliore la modularité et l’évolutivité, elle introduit également un risque majeur : une défaillance d’un service peut se répercuter et faire tomber l’ensemble du système. Si un service en aval devient lent ou ne répond plus, les demandes entrantes adressées à vos services en amont commenceront à s’accumuler. S’ils partagent tous la même mémoire, le même processeur ou le même pool de threads, une dépendance lente peut rapidement épuiser toutes les ressources disponibles, provoquant le blocage de l’ensemble de votre application.

Dans les systèmes cloud natifs modernes, les microservices devraient faire bien plus que simplement exécuter une logique métier. Ils doivent gérer la journalisation, gérer les certificats SSL/TLS, collecter des métriques, mettre en œuvre des mécanismes de nouvelle tentative et coordonner les communications sécurisées avec d’autres services. Si nous intégrons toutes ces fonctionnalités transversales directement dans la base de code de chaque application, nous nous retrouvons avec une surcharge de code, un couplage étroit et un verrouillage linguistique.

Dans le génie logiciel moderne, les applications monolithiques existantes constituent un défi courant. Au fil du temps, une base de code réussie devient si volumineuse et interconnectée que la réalisation de simples modifications devient risquée, les déploiements prennent des heures et la mise à l’échelle de fonctionnalités individuelles est pratiquement impossible.

Dans une architecture de microservices, nos systèmes sont décomposés en dizaines de petits services ciblés, comme un service utilisateur, un service de commande et un service produit. Mais lorsqu’il s’agit d’afficher ces informations à vos utilisateurs, les différents appareils ont des besoins très différents. Un navigateur Web sur un ordinateur de bureau à grande vitesse nécessite un tableau de bord riche rempli de tableaux, de barres latérales et de graphiques. Une application mobile sur un réseau cellulaire lent nécessite une mise en page simple et légère pour économiser la bande passante et la batterie. Une application de montre intelligente peut n’avoir besoin que d’une seule ligne de texte.

La transition d’une application unique et monolithique vers une architecture de microservices résout de nombreux problèmes. Il permet aux équipes de travailler de manière indépendante, de déployer des services séparément et de faire évoluer certaines parties du système selon les besoins. Cependant, cela introduit également un nouveau défi : comment les clients interagissent-ils avec tous ces services indépendants ?

Lorsque les organisations passent d’une architecture monolithique aux microservices, elles sont confrontées à une question critique aux enjeux élevés : Comment tracer les limites de nos services ? En théorie, les microservices devraient être des unités lâches et découplées qui peuvent être développées, déployées et mises à l’échelle indépendamment. Dans la pratique, cependant, de nombreuses équipes finissent par créer un monolithe distribué : un système dans lequel les services sont si étroitement couplés qu’un seul changement commercial nécessite de modifier et de déployer plusieurs services simultanément, ce qui aggrave la latence du réseau et les blocages de déploiement.