SOA et microservices : quelle est la différence ?

Si vous travaillez dans le domaine de l'informatique ou du cloud computing , vous êtes probablement au courant du débat qui oppose l'architecture orientée services (SOA) et les microservices. Après tout, tout le monde parle de microservices et d'applications Agile de nos jours.

À première vue, les deux approches semblent similaires, et à certains égards, elles le sont. Les deux impliquent des environnements cloud ou cloud hybride pour le développement et le déploiement agiles d’applications, et les deux peuvent évoluer pour répondre aux exigences opérationnelles et de rapidité des big data. Les deux décomposent les applications volumineuses et complexes en petits composants flexibles, plus faciles à utiliser. Les deux diffèrent des architectures monolithiques traditionnelles en ce sens que chaque service a sa propre responsabilité.

Cependant, malgré ces points communs, un examen plus approfondi des deux approches révèle des différences importantes.

L’architecture orientée services (SOA) est une approche globale du développement de composants d’application qui tire profit des composants logiciels réutilisables, ou services. Dans l’architecture logicielle SOA, chaque service est composé du code et des intégrations de données nécessaires pour exécuter une fonction métier (par exemple, vérifier la solvabilité d’un client, se connecter à un site Web ou traiter une application de prêt immobilier).

Les interfaces de service fournissent un couplage faible, ce qui signifie qu’il est possible de les appeler avec peu ou pas de connaissances sur la façon dont l’intégration est mise en œuvre. Grâce à ce faible couplage et à la façon dont les services sont publiés, les équipes de développement gagnent du temps en réutilisant les composants pour d’autres applications au sein de l’entreprise. C’est à la fois un avantage et un risque. Parce que l’accès au bus de service d’entreprise (ESB) est partagé, tout problème est susceptible d’affecter également les autres services connectés.

Les données XML sont un élément clé des solutions reposant sur une architecture SOA. Les applications SOA basées sur XML peuvent être utilisées pour créer des services Web, par exemple.

La SOA est apparue à la fin des années 1990 et représente une étape importante dans l’évolution du développement et de l’intégration d’applications. Avant la création de la SOA, connecter une application monolithique aux données ou aux fonctions d’un autre système exigeait une intégration point à point complexe, que les développeurs devaient recréer pour chaque nouveau projet de développement. Exposer ces fonctions par le biais de l’architecture SOA élimine la nécessité de recréer à chaque fois l’intégration profonde.

La SOA propose quatre types de services différents :

1. Les services fonctionnels (c’est-à-dire les services d’entreprise), qui sont essentiels aux applications d’entreprise.
2. Les services d’enterprise, qui servent à mettre en œuvre les fonctions.
3. Les services d’application, qui sont utilisés pour développer et déployer des applications.
4. Les services d’infrastructure, qui jouent un rôle essentiel dans les processus de back-end tels que la sécurité et l’authentification.

Chaque service comprend trois composants :

1. L’interface, qui définit la manière dont un fournisseur de services exécute les demandes du consommateur.
2. Le contrat, qui définit les modalités d’interaction entre le fournisseur et le consommateur de services.
3. La mise en œuvre, qui est le code du service.

Les services SOA peuvent être combinés pour créer des services et des applications de niveau supérieur.

À l’instar de la SOA, les architectures de type microservices sont constituées de composants faiblement couplés, réutilisables et spécialisés, qui fonctionnent souvent indépendamment les uns des autres. Les microservices emploient également un degré élevé de cohésion, également appelé contexte délimité. Le contexte délimité désigne la relation entre un composant et ses données en tant qu'entité ou unité autonome avec peu de dépendances. Au lieu d’être adoptés à l’échelle de l’entreprise, les microservices communiquent généralement via des interfaces de programmation d’application (API) pour créer des applications qui exécutent une fonctionnalité métier particulière. Cette approche les rend plus agiles, plus évolutifs et plus résilients, en particulier pour certains aspects de l’entreprise. Java est le langage de programmation généralement privilégié pour développer des microservices. D’autres langages de programmation peuvent également être utilisés, tels que Golang et Python.

Les microservices constituent une véritable approche architecturale cloud native. Ils fonctionnent souvent dans des conteneurs, ce qui les rend plus évolutifs et portables pour la création de services indépendants. Les équipes peuvent utiliser les microservices pour mettre à jour le code plus facilement, utiliser différentes piles pour différents composants et faire évoluer les composants indépendamment les uns des autres. Cette approche permet de réduire le gaspillage et les coûts associés à la mise à l’échelle d’applications entières, car une seule fonctionnalité risquerait d’être surchargée. En raison de leur indépendance, les microservices produisent des services plus tolérants aux pannes que leurs alternatives.

Regardez la vidéo suivante pour en savoir plus sur l’architecture de type microservices :

La principale distinction entre les deux approches réside dans leur portée. Pour faire simple, la portée de l’architecture orientée services (SOA) concerne l’entreprise, tandis que l’architecture de type microservices a une portée limitée aux applications.

La plupart des principes fondamentaux de chaque approche deviennent incompatibles si vous négligez cette différence. Si vous acceptez la différence de portée, vous vous rendrez vite compte que les deux peuvent se compléter au lieu de se concurrencer.

Voici quelques cas d’utilisation qui illustrent cette distinction :

Avec la SOA, la réutilisation des intégrations est l’objectif principal et, au niveau de l’entreprise, il est essentiel de viser un certain niveau de réutilisation. La réutilisation et le partage des composants dans une architecture SOA augmentent l’évolutivité et l’efficacité.

Dans l’architecture de type microservices, créer un composant de microservices qui sera réutilisé au moment de l’exécution de l’application entraîne des dépendances qui réduisent l’agilité et la résilience. Les composants de microservices préfèrent généralement réutiliser le code en copiant et en acceptant la duplication des données pour améliorer le découplage.

Les services réutilisables de la SOA sont rendus disponibles à l’échelle de l’entreprise en utilisant principalement des protocoles synchrones tels que les API RESTful.

Cependant, au sein d’une application de microservices, les appels synchrones introduisent des dépendances en temps réel, ce qui entraîne une perte de résilience. Ces dépendances peuvent également se traduire par une latence qui affecte la performance. Dans une application de microservices, on privilégie les schémas d’interaction basés sur la communication asynchrone, tels que l’event sourcing, où l’on utilise un modèle de publication/abonnement pour permettre à un composant de microservices de rester informé des modifications apportées aux données d’un autre composant.

L'objectif clair de la fourniture de services dans le cadre d'une SOA est de permettre à toutes les applications d'obtenir et de modifier des données de manière synchrone directement à leur source principale, ce qui réduit la nécessité de gérer des modèles de synchronisation des données complexes.

Dans les applications de microservices, idéalement, chaque microservice dispose d’un accès local à toutes les données dont il a besoin pour garantir son indépendance des autres microservices — et des autres applications — même si cela implique une certaine duplication des données dans d’autres systèmes. Bien entendu, cette duplication ajoute de la complexité. Elle doit donc être mise en balance avec les gains d'agilité et de performance, mais cela est considéré comme une réalité de microservice.

• Communication : dans une architecture de type microservices, chaque service est développé de manière indépendante, avec son propre protocole de communication. Avec la SOA, chaque service doit partager un mécanisme de communication appelé bus de services d’entreprise (ESB). La SOA gère et coordonne les services qu’elle fournit par l’intermédiaire de l’ESB. Cependant, l’ESB peut devenir un point de défaillance unique pour l’ensemble de l’entreprise ; si un seul service ralentit, c’est tout le système qui peut être affecté.
• Interopérabilité : dans un souci de simplicité, les microservices utilisent des protocoles de messagerie légers tels que HTTP/REST (Representational State Transfers) et JMS (Java Messaging Service). Les SOA sont plus ouvertes aux protocoles de messagerie hétérogènes tels que SOAP (Simple Object Access Protocol), AMQP (Advanced Messaging Queuing Protocol) et MSMQ (Microsoft Messaging Queuing).
• Granularité des services : les architectures de type microservices sont composées de services hautement spécialisés, chacun étant conçu pour accomplir une seule tâche très bien. Les services qui composent les SOA, en revanche, peuvent aller des petits services spécialisés aux services à l’échelle de l’entreprise.
• Rapidité : en tirant parti d’une architecture commune, les SOA simplifient le développement et le dépannage. Cependant, cela rend également les SOA plus lentes que les architectures de type microservices, qui minimisent le partage au profit de la duplication.
• Gouvernance : la nature de la SOA, qui implique le partage des ressources, permet la mise en œuvre de normes de gouvernance des données communes à tous les services. Le caractère indépendant des microservices ne permet pas une gouvernance des données cohérente. Chaque service bénéficie ainsi d’une plus grande flexibilité, ce qui peut favoriser une meilleure collaboration au sein de l’entreprise.
• Stockage : la SOA et les microservices diffèrent également en termes d’allocation des ressources de stockage. L’architecture SOA comprend généralement une seule couche de stockage de données, partagée par tous les services d’une application donnée, tandis que les microservices dédient un serveur ou une base de données au stockage de données par tout service qui en a besoin.

Pour certaines entreprises, l'architecture SOA est un tremplin pour remplacer le monolithe, en fournissant un environnement plus flexible et plus agile. Les services SOA peuvent être développés et utilisés dans un vaste environnement, mais ils ne répondent pas aux besoins spécifiques des entreprises individuelles qui souhaitent adresser les processus métier dans leur champ de compétence. DevOps peut être utilisé pour aider une entreprise à passer d'une architecture SOA à des microservices pour répondre à des besoins spécifiques.

Les styles architecturaux ont leurs avantages, alors comment pouvez-vous déterminer lequel convient le mieux à vos besoins ? En général, cela dépend de la taille et de la diversité de votre environnement d'applications.

Les SOA et les microservices peuvent utiliser l’automatisation pour accélérer les processus métier. Les environnements plus vastes et plus diversifiés tendent à privilégier l’architecture orientée services (SOA), qui permet l’intégration entre les applications hétérogènes et les protocoles de messagerie via un bus de services d’entreprise (ESB). Les environnements plus petits, comme les applications Web et mobiles, ne nécessitent pas une couche de communication aussi robuste et sont plus faciles à développer avec une architecture de type microservices.

Certains souligneront que la distinction entre SOA et microservices est beaucoup plus complexe, et c’est vrai. Il y aurait beaucoup plus à dire. Pour une explication technique plus détaillée de ces nuances, nous vous invitons à consulter les articles du Centre d’apprentissage portant sur la SOA et les microservices. Cependant, du point de vue de l’entreprise, la portée est la principale distinction.

• Qu’est-ce qu’un microservice ?
• Qu’est-ce que la SOA (architecture orientée services) ?
• Agile et Waterfall

Pour en savoir plus sur la manière de créer des applications agiles, téléchargez votre exemplaire gratuit de l'ebook Agile Applications Architecture.