Architecture monolithique ou microservices : laquelle vous convient le mieux ?

L’approche monolithique est le modèle logiciel traditionnel. Les microservices reflètent un développement de logiciels plus récent, mais qui n’a pas rendu l’architecture monolithique obsolète.

Supposons que vous ayez commencé à travailler pour une startup technologique et que vous ayez été chargé de mettre en œuvre un plan informatique pour la nouvelle entreprise. Vous devez faire face à une multitude de décisions, mais aucune n’est aussi fondamentale ou aussi ambitieuse que le choix d’une architecture monolithique ou d’une architecture de microservices. Le choix de l’architecture logicielle ne doit pas être fait en vase clos ou sans une compréhension claire des besoins initiaux et éventuels de l’entreprise en matière de traitement de données, car quelle que soit l’approche architecturale choisie, elle aura des répercussions considérables sur la capacité de l’entreprise à atteindre ses objectifs commerciaux.

Les enjeux sont donc considérables. Et parce que vous êtes le nouveau directeur de l’informatique, c’est aussi une décision importante pour vous personnellement. Cette décision pourrait vous mener vers une évolution de carrière considérable si vous faites le bon choix.

Que choisir ? Tout d’abord, examinons les options qui s’offrent à vous.

Comme indiqué, l’architecture monolithique est le modèle traditionnel de développement logiciel. Dans ce type de code, une base de code exécute plusieurs fonctions (c’est-à-dire, des fonctions commerciales). Le noyau de l’ordinateur contrôle toutes les fonctions. Dans les applications monolithiques, tout le code nécessaire à l’ensemble de l’application est conservé dans un emplacement central.

Les applications monolithiques contiennent généralement les composants suivants :

• Interface utilisateur côté client : le « côté client » fait référence à ce qui s’affiche sur l’appareil de l’utilisateur. L’interface utilisateur gère ce que voit l’utilisateur, y compris les images, le texte et tout ce qui peut être transmis sur l’écran de l’interface utilisateur, comme les informations relatives aux actions du navigateur.

• Base de données : les architectures monolithiques utilisent un système de gestion de base de données relationnelle (RDMS), un type de base de données qui organise les données en lignes et en colonnes. Ces lignes et colonnes forment un tableau dans lequel les points de données sont liés les uns aux autres.

• Application côté serveur : une application côté serveur gère les ressources du serveur telles que la mémoire, le processeur et le stockage.

L’utilisation d’une architecture monolithique présente de nombreux avantages :

• Développement d’applications simplifié : les applications construites à partir d’une base de code unique sont plus simples à créer et leur développement est plus rapide.

• Déploiement de base : l’architecture monolithique fonctionne avec un seul fichier exécutable ou un seul répertoire, ce qui facilite le déploiement. Une architecture monolithique est également plus facile à entretenir car elle utilise moins de composants.

• Débogage simple : les opérations de test et de débogage sont moins courantes dans les architectures monolithiques. Les opérations de test de bout en bout sont effectuées à partir d’un système de journalisation central.

• Sécurité renforcée : parce qu’une architecture monolithique est un système fermé, ses activités de traitement de données sont entièrement contenues et protégées contre les cybermenaces.

L’utilisation d’une architecture monolithique présente également certains problèmes :

• Résistance aux nouvelles technologies : les applications monolithiques étant généralement étroitement couplées, il peut être difficile d’y intégrer de nouvelles technologies.

• Évolutivité réduite : même si la mise à l’échelle nécessaire est relativement mineure (ajustement d’une seule fonction), vous devrez peut-être démanteler et reconstruire efficacement le système pour refléter le changement. Cela peut s’avérer chronophage et laborieux.

L’autre modèle de développement logiciel, les microservices, est un style d’architecture cloud natif. Avec les microservices, une application est basée sur plusieurs composants individuels ou services faiblement couplés. Les applications de microservice ont leur propre pile technologique, qui est un ensemble de technologies fonctionnant ensemble pour accomplir une tâche particulière.

Le principal avantage des microservices, c’est qu’ils peuvent être facilement mis à jour pour tenir compte des nouvelles capacités métier au sein de l’application, sans affecter l’ensemble du système. Cela peut se traduire par des économies considérables en termes de temps et de main-d’œuvre.

Les avantages des microservices sont nombreux. Ils s’adaptent à la fois à la croissance constante de l’entreprise et aux évolutions technologiques :

• Évolutivité accrue : les microservices excellent en évolutivité par rapport aux architectures monolithiques. Les services individuels au sein d’une architecture de microservices sont décomposés en modules, et une seule instruction de mise à l’échelle peut être transmise simultanément à plusieurs services. De plus, les microservices sont bien adaptés à la gestion des applications volumineuses et complexes.

• Prêts pour l’automatisation : les microservices utilisés permettent aux entreprises d’automatiser le processus d’Intégration continue/de livraison continue (CI/CD). Cela permet de développer des mises à jour de code selon un calendrier continu.

• Fonctionnement indépendant : l’architecture de microservices divise chaque service en une cellule opérationnelle. Avec ce type de fonctionnement indépendant, il n’y a aucun risque que le workflow d’une application de microservices empiète sur les workflows d’autres applications de microservices.

Les microservices offrent des avantages certains, mais leur complexité crée certains problèmes :

• Obstacles aux tests : avec les microservices, les opérations de débogage ne démarrent pas tant que les différentes parties d’une application n’ont pas été testées. Cela inclut la vérification des dépendances, la mise en cache des activités et l’accès aux données.

• Risques en matière de sécurité : l’échange de données entre différents processus au sein d’un système de microservices utilise une passerelle d’interface de programmation d’application (API). Une API gateway peut créer des vulnérabilités de sécurité dans l’authentification et d’autres activités critiques.

• Augmentation de la latence : les microservices font évoluer les applications de manière impressionnante, mais cela peut créer des problèmes avec une latence supplémentaire. Chaque fois que le système évolue, la complexité et la quantité de données transférées augmentent, ce qui peut ralentir le traitement.

Avant de comparer l’architecture monolithique et l’architecture de microservices, abordons quelques détails historiques afin de bénéficier d’un contexte plus large.

À certains égards, il est difficile de retracer l’origine de l’architecture monolithique à une seule date. Plus la technologie est complexe, plus il peut être difficile d’en déterminer l’apparition exacte. Il en va de même pour les architectures monolithiques, qui ont commencé à se développer vers le milieu du XXe siècle.

International Business Machines (IBM) a été un acteur majeur dans ce développement précoce essentiel. Selon Pier-Jean Malandrino, collaborateur de DZone, «... des entreprises comme IBM ont joué un rôle déterminant dans la définition des premières architectures logicielles en développant des ordinateurs mainframe dans les années 1960 et 1970. » ¹

Les architectures monolithiques n’étaient pas parfaites : elles étaient souvent écrites dans des langages ultrabasiques et devaient être lues par une seule machine. Comme une seule machine contenait l’ensemble du système, tous les composants de l’ordinateur étaient étroitement couplés. La mise à l’échelle était soit inexistante, soit à peine possible, nécessitant généralement la reconstruction complète d’un système.

Par ailleurs, si l’architecture monolithique semble primitive avec le recul, c’est en partie parce qu’elle était là la première, avant tout autre système d’architecture logicielle. Et elle a été constamment utile, voire résiliente, au fil du temps. Le fait que les architectures monolithiques soient encore utilisées sept décennies après leur introduction en dit long dans un secteur où les changements sont généralement incessants.

L’architecture monolithique a perduré, mais elle n’est plus la seule sur le marché, et ce depuis un certain temps. Au fil des années 1980, le génie logiciel a connu une tendance à la modularité et à l’utilisation de langages de programmation orientés objet. Dans les années 1990, les conditions étaient réunies pour que les systèmes distribués puissent profiter des progrès récents de l’informatique en réseau.

Cela a finalement conduit au développement de microservices, qui se sont généralisés après l’apparition des technologies de cloud computing et de conteneurisation dans les années 2000. L’architecture de microservices a été créée pour améliorer le modèle monolithique en l’adaptant à une mise à l’échelle rapide et à des systèmes décentralisés.

Aujourd’hui, dans les années 2020, le développement de logiciels s’appuie soit sur une architecture monolithique, soit sur une architecture de microservices. Sur la base de ce que nous attendons de l’évolution technologique, nous pourrions supposer que la technologie la plus récente est la meilleure, et dans certaines circonstances, c’est le cas.

Cependant, il est dangereux de faire ce genre d’affirmation générale, principalement parce que ce n’est pas toujours vrai. Il existe encore de nombreuses situations informatiques qui bénéficient de la simplicité du modèle d’architecture monolithique.

Ces deux architectures logicielles présentent des avantages et des inconvénients. Les entreprises doivent donc évaluer soigneusement les deux types et prendre en compte leurs besoins en matière de développement d’applications avant d’adopter un système ou un autre.

Comment l’architecture monolithique et l’architecture de microservices se comparent-elles lorsqu’elles à travers le prisme des étapes opérationnelles clés ?

• Création : les principales différences entre les deux formats architecturaux commencent dès le début, avec la conception du système souhaité. Les systèmes monolithiques sont plus simples à construire, car ils utilisent une conception plus basique. Les microservices sont considérablement plus complexes et nécessitent plus de planification.

• Structure : une architecture monolithique est conçue et construite en une seule unité. L’architecture de microservices soutient l’idée de modularité en utilisant un ensemble de microservices plus petits et déployables qui permettent l’exploitation des opérations indépendantes.

• Complexité : plus un système est complexe, mieux il est adapté à une architecture de microservices. Les microservices modulaires accueillent de nouvelles fonctionnalités et de nouvelles technologies qui tendent à s’accompagner d’une complexité accrue.

• Croissance : l’architecture monolithique et l’architecture de microservices peuvent toutes deux être efficaces lors de leur utilisation initiale. Cependant, la croissance change tout, en particulier lorsque les entreprises prennent conscience qu’elles vont bientôt étendre leur système initial. À ce stade, les entreprises ont besoin d’un plus grand nombre d’opérations, et les microservices fournissent cette fonctionnalité en dimensionnant davantage les opérations que ne le fait l’architecture monolithique.

• Délai de mise sur le marché : cet indicateur clé joue un rôle essentiel dans le commerce en évaluant le temps nécessaire à la fabrication des produits et à leur entrée dans les canaux de distribution. Le délai de mise sur le marché est un domaine dans lequel l’architecture monolithique excelle par rapport aux microservices. En n’utilisant qu’une seule base de code, les développeurs évitent le temps et le travail supplémentaires liés à l’intégration de logiciels provenant de diverses sources.

• Évolutivité : l’architecture de microservices repose sur des services individuels qui peuvent être compartimentés sous des formes modulaires et tirer parti de l’intercommunication obtenue grâce à l’utilisation d’API. D’autre part, l’architecture monolithique présente une adaptabilité globale moindre en raison d’une structure centrale très dense et d’un logiciel étroitement couplé.

• Débogage : le débogage est le processus qui consiste à utiliser un logiciel pour détecter et localiser les problèmes de codage, puis à y remédier. L’architecture monolithique gère mieux le débogage que les microservices, car elle est plus simple et plus directe. Le débogage d’une architecture de microservices est considérablement plus lent, plus complexe et plus laborieux.

Il existe un nombre quasi illimité de cas d’utilisation qui peuvent être atteints en utilisant une architecture monolithique ou une architecture de microservices. Voici quelques-uns des plus importants :

• Startups : les entreprises qui démarrent ont besoin de deux choses : de la flexibilité et des fonds de lancement (et beaucoup des deux). Une architecture monolithique est la meilleure solution pour démarrer une entreprise. En outre, elle peut être construite par des équipes de développement allégées d’une manière rentable qui n’impose pas de courbe d’apprentissage trop raide à ces petites équipes.

• Projets de base : le fait de disposer d’une base de code unique est rentable en termes de commodité, en particulier pour les projets dont la portée est rudimentaire. Lorsque le logiciel peut passer par le processus de développement sans avoir besoin d’incorporer des données provenant de plusieurs sources, c’est une victoire pour l’organisation.

• Plateformes de divertissement : pour gérer une plateforme de divertissement internationale, il faut être capable de faire face à l’évolution des workloads, qu’elles soient lourdes ou légères. Dans le cas de Netflix, le géant du streaming vidéo est passé d’une architecture monolithique à une architecture de microservices basée sur cloud. Le nouveau backend de Netflix contient un grand nombre de supports d’équilibreurs de charge, ce qui contribue à ses efforts d’optimisation des workloads.

• Commerce électronique : le commerce électronique dépend de l’architecture de microservices pour donner vie à la magie d’une marketplace avec une expérience utilisateur fluide. Des enseignes ambitieuses comme Amazon (AWS) proposent des ventes plus pratiques et des livraisons plus rapides : en 2023, le marché des ventes e-commerce a dépassé les 5,8 billions de dollars.²

• Les tâches les plus difficiles : l’utilisation continue des microservices nécessite généralement les compétences de mise en œuvre et d’administration d’équipes DevOps qui peuvent créer les services spécifiques nécessaires pour ce cadre architectural. Ces compétences sont particulièrement utiles face à des applications complexes.

Toute mise en œuvre à grande échelle d’une architecture monolithique ou d’une architecture de microservices sera inévitablement erronée si sa conception est réalisée dans un vide effectif, sans tenir compte au préalable de la partie la plus importante de l’équation, à savoir les besoins particuliers de votre startup technologique.

En tant que responsable informatique, il s’agit de l’activité la plus essentielle lors de la planification de vos décisions en matière d’infrastructure logicielle. Il est essentiel de savoir quand utiliser un style d’architecture et d’identifier le système le plus adapté à vos besoins.

L’exercice d’auto-analyse est très précieux, car vous devez choisir le système architectural optimal pour votre organisation, mais aussi estimer avec précision le système architectural dont votre entreprise aura besoin dans les mois et les années à venir. D’une certaine manière, vous devez prédire l’avenir.

Ainsi, bien qu’une architecture monolithique puisse sembler parfaitement idéale pour votre startup, c’est à vous de prévoir la croissance future. Et si une expansion fulgurante est prévue, il pourrait être plus judicieux d’aller de l’avant et d’investir dans une architecture de microservices. Il existe de nombreuses variables à prendre en compte :

• Logique commerciale utilisée : tout comme la logique informatique dicte ce qui est possible et ce qui ne l’est pas avec un ordinateur, la logique commerciale est basée sur des business rules qui régissent la manière dont une entreprise peut et ne peut pas être gérée. Techniquement, cela se traduit par les algorithmes qui définissent la manière dont les informations sont transmises entre une base de données et une interface utilisateur.

• Développement front-end : dès que vous planifiez le front-end de votre architecture logicielle, vous devez définir l’approche architecturale que vous suivez, car chacune a une structure unique. Dans une architecture monolithique, l’application front-end se présente comme une grande base de code qui héberge tout le code de l’application. Dans une application de microservices, plusieurs microservices fonctionnant indépendamment peuvent être mis en service.

• Tolérance aux pannes : un autre élément à prendre en compte est le degré de tolérance aux pannes qui sera nécessaire. La tolérance aux pannes est une question très délicate, car elle peut faire tomber toute une application en cas de défaillance d’un seul composant du système. Une architecture monolithique manque d’isolation entre les composants, ce qui peut aggraver le manque de tolérance aux pannes et entraîner des périodes de temps d’arrêt prolongées.

• Taux d’évolution attendu : le choix entre une architecture monolithique et une architecture de microservices n’est pas simplement une question d’architecture logicielle. Il s’agit en fait de choisir entre deux mentalités, l’une qui souhaite simplement lancer ses opérations et l’autre qui se concentre sur la réalisation d’une croissance significative. La croissance peut être délicate, mais elle est bien soutenue par les attributs de l’architecture microservice, tels que des cycles de développement plus rapides et une évolutivité accrue.