Monolithe vs Microservices : quelle architecture pour votre organisation ?

Malgré son nom, l’architecture monolithique n’est pas forcément obsolète. C’est simplement la façon traditionnelle de développer des applications en tant que composants uniques et indivisibles. À mesure que vous ajoutez de nouvelles fonctionnalités et des modifications à cette base de code, celle-ci s’étoffe au fil du temps. Cette structure convient bien aux petites équipes et offre plusieurs avantages, comme la réduction des coûts d’exploitation et un meilleur cadrage. Le monolithe comporte généralement une application côté serveur, une interface utilisateur front-end et une seule base de données. Toutes les fonctions sont gérées et fournies en un seul endroit, ce qui génère des gains importants.

 

Architecture monolithique : points forts et avantages

Une application monolithique est facile à développer, à tester et à déployer. Après le déploiement, il suffit de l’adapter en fonction des changements au fil du temps. Même si cette approche crée un point de défaillance unique pendant le déploiement, ce n’est pas un problème en soi pour la majorité des organisations. Comme tout passe par la même application, les problèmes transversaux tels que la journalisation, le traitement, la mise en cache et la sécurité sont faciles à résoudre, car la mémoire, l’espace et les ressources sont partagés. L’approche monolithique présente également des avantages en termes de performances, puisque l’accès à la mémoire partagée est plus rapide que la communication interprocessus (ICP), par exemple.

Voici quelques scénarios courants qui justifient l’adoption d’une approche monolithique :

1. Vous avez une petite équipe et vous en êtes au stade de la création. Dans une nouvelle équipe de deux à cinq personnes, l’architecture monolithique est le choix idéal pour se concentrer sur le projet.
2. Vous développez une démonstration de faisabilité. Les nouveaux produits changeront et évolueront à mesure que vous déterminerez ce qui sera utile à vos utilisateurs. Une architecture monolithique conviendra parfaitement, car elle permet une itération rapide du produit.
3. Une échelle et une complexité prévisibles. Si votre application ne nécessite pas d’évolutivité avancée et si sa complexité est gérable, l’architecture monolithique s’impose comme la meilleure option.

 

Le besoin d’agilité business.

Le commerce mondial connaît aujourd’hui une croissance exponentielle, chaque nouveau canal créant un nouveau marché. Les clients sont de plus en plus exigeants et recherchent des expériences d’achat captivantes sur tous les canaux et sur tous les appareils. Et pour les commerçants, les défis à relever ne manquent pas : personnalisation, niveau de service élevé et rapidité de livraison, pour ne citer que quelques exemples. Les chefs de file du secteur doivent être en mesure de s’adapter rapidement.

 

Architecture monolithique : défis et inconvénients

Dans cet environnement commercial qui évolue à un rythme effréné, l’architecture monolithique présente des lacunes évidentes :

1. Une grande complexité logicielle. Pour être efficaces, les applications doivent en permanence évoluer afin de répondre aux attentes changeantes des clients. Par conséquent, elles peuvent devenir difficiles à gérer et trop « touffues » ou obscures pour les développeurs qui travaillent dessus.
2. Pas de responsabilité. Une application imposante risque d’être perçue comme une « boîte noire » que personne ne veut prendre en charge. On parle alors de « grande boule de boue » (« big ball of mud » en anglais), ce qui peut dissuader les développeurs de toucher à quoi que ce soit.
3. Manque d’agilité. Avec des applications monolithiques, les équipes sont généralement structurées par fonctions individuelles, telles que le front-end, le back-end ou la base de données. Lorsqu’une demande concerne l’ensemble de ces équipes, les projets qui en résultent peuvent prendre beaucoup de temps, car les tâches doivent être partagées par et entre plusieurs de ces collaborateurs.
4. Dans une architecture centralisée, les différentes parties sont fortement liées et dépendantes les unes des autres. Cela se traduit par un point de défaillance unique qui peut compromettre l’ensemble du système.
5. Tests inefficaces. En raison des points de défaillance uniques présents dans ces applications, il devient vital de procéder à des tests complets et réguliers. Toute modification de la moindre partie de l’application doit être testée dans son intégralité, y compris au niveau des fonctionnalités qui n’ont rien à voir avec les changements apportés.
6. Pas de spécialisation. Dans une application fortement couplée, les composants individuels sont généralement traités de manière égale en ce qui concerne le type et le nombre de ressources auxquelles ils ont accès, sans tenir compte du fait que certains nécessitent plus ou moins de CPU, de RAM ou d’E/S disque.
7. Problèmes de scaling. Dans la plupart des applications monolithiques, le scaling horizontal est la seule option possible, ce qui entraîne de nombreux autres problèmes. Naturellement, les entreprises qui ont besoin d’aller plus vite et de stimuler l’innovation cherchent à contourner ces restrictions.

 

Architecture de microservices : points forts et avantages

L’approche des microservices consiste à transformer chaque capacité de l’entreprise en service individuel. Chaque processus applicatif fonctionne comme un service distinct, très faiblement couplé, avec sa propre logique et sa propre base de données. La mise à jour, le déploiement, les tests et le scaling s’effectuent à l’échelle de chaque service. Si les microservices ne réduisent pas la complexité d’un système, ils la rendent plus visible et plus facile à gérer. En fonction des besoins, un même service peut être réutilisé dans plusieurs processus business et sur une multitude de canaux et de points de contact. En standardisant les contrats via des API orientées business, les utilisateurs ne remarquent pas les changements apportés dans le back-end.

L’adoption des microservices par des acteurs tels que Netflix, Airbnb, Google, Disney et Amazon leur a permis de gagner du terrain et de se forger une solide réputation. Voici les meilleures pratiques courantes en matière d’architecture de microservices :

• Domaines clairement définis. Pendant la phase de conception des microservices, il faut que leur périmètre soit clair afin de pouvoir les aligner sur les capacités business. Dans la conception orientée domaine, c’est ce que l’on appelle le « bounded context » (contexte délimité). Cela vous permet d’utiliser le langage le plus efficace pour chaque domaine.
• Exigences très élevées. Les microservices peuvent offrir un niveau exceptionnel d’agilité, de rapidité et d’évolutivité. Les applications aux exigences très élevées gagnent à s’appuyer sur une architecture de microservices qui peut s’adapter spécifiquement à chaque service.
• Expertise en matière de microservices. Pour vous lancer dans les microservices, vous aurez besoin d’une équipe justifiant d’une certaine expérience en matière de microservices ou de conception distribuée. Nous vous conseillons de faire appel à des experts en DevOps et en conteneurs, car ces concepts sont étroitement liés aux microservices.
• Complexité. Si vous envisagez une application imposante avec de nombreux modules et des parcours utilisateur qui induisent une grande complexité, l’architecture de microservices est la meilleure option. Cela facilite grandement le scaling et l’ajout de nouvelles capacités.

 

Architecture de microservices : défis et inconvénients

Au vu des grands noms qui préconisent les microservices et des points de départ courants, il est clair que l’architecture de microservices n’est pas une solution miracle. N’optez pas pour les microservices uniquement parce que vous voyez d’autres organisations les utiliser avec succès. L’approche ne convient pas à tous les contextes commerciaux et ne fera pas disparaître comme par magie la complexité du développement et de la maintenance.

Ne la voyez pas comme une solution qui vous permettra de gérer votre e-commerce les yeux fermés, et tenez bien compte de ses inconvénients par rapport à l’approche monolithique :

• Problématiques transversales. Chaque microservice comporte un certain nombre de contraintes transversales (journalisation, métriques, contrôles d’état, externalisation de la configuration, etc.) que vous n’aurez sans doute pas anticipées au moment de la conception. Si c’est le cas, vous pouvez accepter la charge de travail associée à la création de modules distincts pour chacune d’elles. Ou bien, vous pouvez regrouper ces aspects dans une autre couche de service via laquelle l’ensemble du trafic est acheminé.
• Coûts plus élevés. Les microservices génèrent une charge de travail plus importante en termes d’opérations, de déploiement et de surveillance, ce qui augmente les coûts d’exploitation. Quand les services communiquent ensemble, le grand nombre d’appels à distance qui en résulte peut entraîner des coûts plus élevés liés à la latence et au traitement du réseau. Et comme chaque microservice est déployé indépendamment et nécessite son propre environnement d’exécution et son propre processeur, les besoins en ressources sont également plus importants.
• Changement organisationnel. Chaque équipe doit couvrir l’ensemble du cycle de vie d’un microservice pour garantir une indépendance totale, de la conception et des décisions techniques au déploiement, en passant par l’exploitation et la surveillance. Cette démarche nécessite des changements organisationnels, tels que le transfert des compétences et du pouvoir des responsables vers les équipes. Pour réussir le passage aux microservices, il est fortement conseillé d’adopter une culture DevOps, qui met également l’accent sur les pratiques d’automatisation.

 

Conclusion : il n’y a pas d’approche universelle

En matière d’architectures de services, les microservices ont le vent en poupe. Mais attention, pour prendre la bonne décision, il est impératif de tenir compte de votre organisation actuelle et des avantages et inconvénients susmentionnés. Pour résumer, les systèmes monolithiques sont la meilleure option pour les applications légères, tandis que les architectures de microservices conviendront mieux aux applications complexes et évolutives reposant sur des domaines bien délimités.

Dernier conseil, mais non des moindres : ne vous focalisez pas sur l’architecture, mais sur les besoins de votre entreprise. Cela vous aidera à y voir plus clair, à éliminer la complexité superflue à faire avancer les choses en tant que décideur technique.