Architecture de microservices et architecture monolithique

Dans le monde des logiciels, les architectures de microservices constituent une tendance majeure qui peut avoir des répercussions considérables non seulement sur la fonction IT d’une entreprise, mais aussi sur l’ensemble de son processus de transformation digitale.

Quelle est donc la différence entre une architecture de microservices et une architecture monolithique ? Et, plus important encore, quels sont les avantages d’une architecture de microservices qui justifient son adoption par des géants du numérique tels que Netflix, Google et Amazon ?

Qu’est-ce qu’une architecture monolithique ?

Commençons par établir ce qui distingue une architecture de microservices d’une architecture monolithique. Cette dernière est conçue comme un seul bloc. Les applications d’entreprise sont composées de trois éléments :

• une base de données, constituée de nombreuses tables, qui se trouvent généralement dans un système de gestion de base de données relationnelle ;
• une interface utilisateur côté client, constituée de pages HTML et/ou de code JavaScript s’exécutant dans un navigateur ;
• une application côté serveur, qui traite les requêtes HTTP, exécute la logique métier, récupère et actualise les données de la base de données, et remplit les affichages HTML à envoyer au navigateur.

Le caractère monolithique de l’architecture réside dans la réunion de ces trois éléments dans un unique exécutable logique. Pour apporter des modifications au système, un développeur doit créer et déployer une version actualisée de l’application côté serveur.

Qu’est-ce qu’une architecture de microservices ?

Une architecture de microservices diffère d’une architecture monolithique en ce que les fonctionnalités des microservices sont formellement exprimées par des API orientées métiers. Ces API encapsulent une fonctionnalité métier clé, et l’implémentation du service, qui peut impliquer des intégrations avec des systèmes d’enregistrement, est complètement masquée, l’interface étant définie dans une optique purement opérationnelle.

De par leur positionnement en tant que ressource précieuse pour l’entreprise, les services peuvent implicitement être adaptés pour une utilisation dans des contextes multiples. Un même service peut être réutilisé dans le cadre de différents processus métiers, canaux commerciaux ou points de contact numériques.

Les dépendances entre les services et leurs utilisateurs sont atténuées par l’application du principe de couplage lâche. La normalisation des contrats exprimés à travers les API orientées métiers permet d’éviter que les modifications touchant l’implémentation du service n’affectent les utilisateurs. Cela permet aux responsables des services de réviser l’implémentation et de modifier les systèmes d’enregistrement ou les compositions de services, qui peuvent être sous-jacents à l’interface, puis de les remplacer sans la moindre incidence en aval.

Architecture de microservices contre architecture monolithique : la différence pour le développement logiciel

Les processus traditionnels de développement logiciel (en cascade, méthode agile, etc.) conduisent souvent des équipes relativement grandes à travailler sur un artefact de déploiement unique et monolithique. Les gestionnaires de projet, les développeurs et le personnel opérationnel peuvent atteindre différents degrés de succès avec ces modèles, en publiant des applications candidates qui peuvent être validées par l’entreprise, en particulier lorsqu’ils acquièrent de l’expérience à l’aide d’une pile spécifique de logiciels et de mécanismes de déploiement. Les approches traditionnelles comportent toutefois leur lot de problèmes cachés :

• Les applications monolithiques peuvent devenir une « grande boule de boue », ce terme désignant une situation dans laquelle aucun développeur individuel (ni groupe de développeurs) n’est en mesure de comprendre l’application dans son intégralité.
• Les applications monolithiques ne permettent pas une réutilisation optimale.
• Il peut être difficile de faire évoluer une application monolithique.
• Le déploiement répété d’artefacts d’applications monolithiques pèse sur l’agilité opérationnelle.
• Par définition, les applications monolithiques sont implémentées à l’aide d’une seule pile de développement (c’est-à-dire JEE ou .NET), ce qui peut limiter les outils parmi lesquels l’entreprise peut choisir pour répondre à un besoin donné.

Utilisée en combinaison avec des technologies de déploiement cloud, de gestion des API et d’intégration, une architecture de microservices permet une autre approche du développement logiciel. Dans cette approche, le monolithe est décomposé en un ensemble de services indépendants qui sont développés, déployés et gérés séparément. Cette façon de procéder présente les avantages suivants :

• Le développement de services de petite taille est encouragé et ne nécessite, dans l’idéal, qu’une poignée de développeurs.
• Les services peuvent être utilisés et réutilisés par d’autres services et applications sans couplage direct via des liens d’association de langages ou des bibliothèques partagées.
• Les services existent en tant qu'artefacts de déploiement autonomes et peuvent évoluer indépendamment des autres services.
• Le fait de développer les services séparément permet aux développeurs d’utiliser le framework de développement approprié à chaque tâche.

Les inconvénients d’une architecture de microservices par rapport à une architecture monolithique

Une telle souplesse implique une certaine complexité. La gestion d’une multitude de services distribués à grande échelle n’est pas chose facile, et ce pour deux raisons principales :

1. Les équipes de projet doivent pouvoir découvrir facilement le potentiel de réutilisation des services. Ces services doivent s’accompagner d’une documentation, de consoles de test, etc., afin qu’il soit beaucoup plus facile de recourir à la réutilisation que de repartir de zéro.
2. Les interdépendances entre les services doivent être étroitement surveillées. Les temps d’arrêt, les pannes et les mises à niveau des services peuvent avoir des effets en cascade en aval, et un tel impact doit être analysé de manière proactive.

Il est donc important de gérer de façon rigoureuse la livraison de vos microservices et d’automatiser le SDLC autant que possible. En l’absence d’automatisation et de coordination d’équipe de type DevOps, votre adoption des microservices générera plus d’inconvénients que d’avantages.

Les bonnes pratiques en matière de conception de microservices

Vous souhaitez vous lancer dans les microservices ? Lisez notre guide des bonnes pratiques en matière de conception de microservices.