Architecture orientée services, API et microservices

Informatique de gestion · Master 1

Monolithe, SOA et microservices : couplage, API, ESB, cohérence, compromis et critères de choix.

Introduction

Une architecture monolithique regroupe toutes les fonctions d'une application dans une seule unité déployable. Elle est simple à développer et à tester au départ, mais devient difficile à faire évoluer lorsque la base de code et les équipes grandissent. L'architecture orientée services (SOA), apparue dans les années 2000, propose de découper le système d'information en services métier réutilisables, exposés par des contrats et souvent reliés par un bus de services d'entreprise (ESB).

Les microservices poussent cette idée plus loin : de petits services, déployables indépendamment, organisés autour de capacités métier (contextes bornés au sens du Domain-Driven Design), chacun avec ses propres données. Ils communiquent par des API légères (HTTP, messagerie) et s'exposent via une passerelle d'API. Les bénéfices sont l'autonomie des équipes, la scalabilité ciblée et la résilience ; les coûts sont une complexité opérationnelle accrue, la gestion de la cohérence éventuelle des données et la supervision de nombreux composants.

En architecture d'entreprise, le choix n'est pas dogmatique. Un monolithe modulaire peut être pertinent pour une PME, tandis qu'une plateforme aux domaines très indépendants peut justifier des microservices. L'urbanisation du SI consiste à raisonner par domaines, contrats d'interface et gouvernance des API.

Objectifs d'apprentissage

Comparer monolithe, SOA et microservices
Expliquer les rôles d'un ESB et d'une passerelle d'API
Décrire contexte borné et autonomie des données
Analyser les compromis (cohérence, complexité, déploiement)
Justifier un choix d'architecture selon le contexte

Concepts clés

Monolithe: Une seule unité déployable : simple au départ, rigide à grande échelle.
SOA: Services métier réutilisables avec contrats, souvent via un bus d'entreprise.
Microservices: Petits services autonomes, une base par service, déployés indépendamment.
Compromis: Autonomie et scalabilité contre complexité d'exploitation et cohérence éventuelle.
Gouvernance des API: Versionnement, contrats, sécurité et catalogue pour éviter le chaos d'interfaces.

Conclusion

Il n'existe pas d'architecture universellement meilleure : monolithe, SOA et microservices répondent à des contextes différents. Le bon choix pèse la taille des équipes, la volatilité du domaine et la maturité d'exploitation.

Dans tous les cas, des contrats d'interface clairs, un catalogue d'API et une gouvernance évitent que l'intégration ne devienne le principal problème.

Cartes

Qu'est-ce qu'un monolithe ?: Une application dont tous les modules sont déployés ensemble comme une seule unité.
Quel est l'intérêt de la SOA ?: Découper le SI en services métier réutilisables, décrits par des contrats, pour réduire les duplications et faciliter l'intégration.
À quoi sert un ESB ?: À acheminer, transformer et orchestrer les messages entre services et applications ; risque : devenir un point central trop lourd.
Qu'est-ce qu'un microservice ?: Un petit service autonome, centré sur une capacité métier, déployable indépendamment et propriétaire de ses données.
Qu'est-ce qu'un contexte borné ?: Une frontière métier du Domain-Driven Design à l'intérieur de laquelle un modèle et un vocabulaire sont cohérents.
Pourquoi une base de données par service ?: Pour préserver l'autonomie et éviter un couplage par le schéma, au prix d'une cohérence éventuelle entre services.
Rôle d'une passerelle d'API ?: Point d'entrée unique pour les clients : routage, authentification, limitation de débit, agrégation.
Communication synchrone ou asynchrone ?: Synchrone (requête-réponse HTTP) : simple mais couplé en disponibilité ; asynchrone (messages, événements) : plus découplé mais plus complexe à suivre.
Quand préférer un monolithe modulaire ?: Quand l'équipe est petite, le domaine encore incertain et que les coûts d'exploitation des microservices ne sont pas justifiés.

Glossaire

SOA: Style d'architecture fondé sur des services métier réutilisables aux contrats explicites.
Microservice: Service de petite taille, autonome et déployable seul.
Passerelle d'API: Composant frontal qui centralise l'accès aux services.
Cohérence éventuelle: Les données divergent temporairement et convergent ensuite.
Contexte borné: Frontière d'un modèle métier cohérent.
Urbanisation du SI: Organisation du SI en zones, domaines et services alignés sur le métier.