La différence entre les microservices et la SOA
L'architecture orientée services (SOA) est une méthode de développement de logiciels qui utilise des composants logiciels appelés services pour créer des applications métier. Chaque service fournit une capacité métier. Ces services peuvent également communiquer entre eux sur différentes plateformes et langages. Les développeurs utilisent la SOA pour réutiliser des services dans différents systèmes ou combiner plusieurs services indépendants pour effectuer des tâches complexes. L'architecture de microservices est une évolution du style d'architecture de SOA. Alors que chaque service SOA constitue une capacité métier complète, chaque microservice est un composant logiciel beaucoup plus petit qui se spécialise dans une seule tâche. Les microservices comblent les lacunes des SOA afin de rendre le logiciel plus compatible avec les environnements d'entreprise cloud modernes.
Quelles sont les limites de l'architecture monolithique que résout l'architecture SOA ?
Au sein d'une architecture monolithique, les développeurs écrivent du code pour toutes les fonctions de service dans une base de code unique. Grâce à l'architecture orientée services (SOA), les développeurs peuvent relever les défis de l'architecture monolithique, par exemple :
- Les défis de mise à l'échelle, qui exigent la mise à l'échelle de l'ensemble de l'application même si seul un composant spécifique nécessite des ressources supplémentaires.
- L'impossibilité d'ajouter ou de modifier des fonctionnalités de manière flexible, car les fonctionnalités sont disséminées dans la base de code.
- L'impossibilité de réutiliser les composants dans différentes applications.
- La tolérance limitée aux pannes. La défaillance d'un composant peut potentiellement entraîner la panne de l'ensemble du système.
- Le défi que représente l'adoption de nouvelles technologies ou l'intégration à des systèmes externes utilisant des technologies différentes.
Les architectures monolithiques centralisent également la propriété et les équipes de développement responsables de l'ensemble de l'application. La taille et la complexité des architectures entraînent également l'apparition de défis liés à la distribution continue et aux pratiques DevOps.
La SOA permet aux développeurs de décomposer les fonctionnalités du logiciel en couches de fournisseurs de services et de consommateurs de services. Ces couches communiquent et échangent des données par l'intermédiaire d'un Enterprise Service Bus (ESB). Les développeurs utilisent la SOA pour simplifier les applications complexes et les transformer en plusieurs services réutilisables.
Quelles sont les limites de l'architecture SOA que résout l'architecture de microservices ?
Bien que l'architecture orientée services (SOA) puisse convenir à la création d'applications d'entreprise de grande envergure, ses besoins en flexibilité sont accrus lorsqu'il s'agit de mettre à l'échelle des applications plus petites spécifiques aux activités. Voici quelques-unes des limites de la SOA :
- L'Enterprise Service Bus (ESB) relie plusieurs services entre eux, ce qui en fait un point de défaillance unique.
- Tous les services partagent un référentiel de données commun, ce qui complique leur gestion individuelle.
- Chaque service a une large portée : si l'un d'eux est défaillant, l'ensemble du flux de travail de l'entreprise sera affecté.
Les développeurs se tournent donc vers l'architecture de microservices pour une approche plus précise de la création d'applications.
Le modèle de microservices divise un service SOA en services plus petits. Chaque microservice fonctionne dans son propre contexte limité, indépendamment des autres services. En résumé, l'architecture de microservices présente des interdépendances réduites, voire inexistantes, entre les différents services et diminue le risque de défaillance à l'échelle du système.
Différences d'architecture : SOA vs. microservices
L'architecture orientée services (SOA) englobe un champ d'activité plus large. Les différentes unités opérationnelles collaborent efficacement sur une plateforme commune de partage de données. La portée des microservices est en revanche plus limitée :
par exemple, la gestion des stocks serait un service SOA au sein d'un système d'e-commerce, mais une approche de type microservice diviserait la gestion des stocks en services de plus petite taille, comme la vérification des disponibilités, le traitement des commandes et la comptabilité.
Implémentation
La mise en œuvre de la SOA implique d'intégrer différents types de services dans une application. Il utilise un Enterprise Service Bus pour relier les types de services, par exemple :
- Les services fonctionnels pour permettre des opérations commerciales spécifiques
- Les services d'entreprise pour exposer une fonctionnalité commerciale particulière à d'autres services
- Les services applicatifs utilisés par les développeurs pour créer et déployer des applications
- Les services d'infrastructure pour gérer les fonctionnalités non fonctionnelles comme l'authentification et la sécurité
Au contraire, l'architecture de microservices consiste en une implémentation plus granulaire et indépendante de la SOA. Les microservices ne partagent pas les ressources comme le font les services SOA : chacun fonctionne en toute indépendance pour fournir des fonctionnalités hautement spécifiques.
Communication
Pour accéder aux services distants, l'architecture SOA utilise un Enterprise Service Bus (ESB) centralisé pour connecter divers services à l'aide de plusieurs protocoles de messagerie, notamment SOAP, Advanced Messaging Queuing Protocol (AMQP) et Microsoft Message Queuing (MSMQ). Tous les services SOA seront affectés en cas de défaillance de l'ESB.
Les architectures de microservices utilisent quant à elles des systèmes de messagerie plus simples, comme des API RESTful, le service de messagerie Java (JMS) ou le streaming d'événements par publication-abonnement (Pub/Sub). Ces méthodes n'obligent pas les microservices à maintenir une connexion active lorsqu'ils échangent des données.
Les API sont des outils couramment utilisés dans les architectures de microservices. Une API permet à deux ou plusieurs microservices d'échanger des données directement sans passer par un canal centralisé, mais elle peut créer des parcours de données complexes entre des dizaines de microservices, que les développeurs surveillent et gèrent.
Stockage de données
L'environnement SOA comprend une seule couche de stockage de données partagée par d'autres services connectés. Différentes applications d'entreprise accèdent aux mêmes données et les réutilisent dans les implémentations SOA pour optimiser la valeur des référentiels de données.
Par contraste, chaque microservice possède son propre stockage de données. Dans les architectures de microservices, l'indépendance des données prime la réutilisabilité.
Déploiement
Le déploiement de services SOA peut s'avérer difficile, car ils sont couplés dans une certaine mesure : les développeurs doivent par exemple recréer l'intégralité de l'application lorsqu'ils modifient ou ajoutent un nouveau service. De plus, les applications SOA ne peuvent pas tirer pleinement parti de la conteneurisation, qui les soustrait des systèmes d'exploitation et du matériel.
Par ailleurs, les microservices sont plus faciles à déployer, car ils sont conçus en vue d'une mise à l'échelle horizontale au sein d'un environnement cloud. Chaque microservice est une application indépendante que les développeurs peuvent conteneuriser et déployer sur le cloud.
Principaux avantages : microservices vs. SOA
L'architecture orientée services (SOA) et les microservices permettent tous deux aux équipes de développement de créer, de déployer et de gérer efficacement des applications modernes pour les environnements cloud. Cela dit, les microservices sont plus avantageux que les déploiements SOA sur certains points.
Réutilisabilité
L'un des principes des conceptions SOA est l'importance de la réutilisabilité et du partage des composants. Dans une architecture de ce type, plusieurs applications de premier plan utilisent les mêmes services SOA ; par exemple, un tableau de bord de facturation et de suivi des commandes peut accéder à un même service pour récupérer des informations sur les clients.
Les microservices adoptent quant à eux une approche différente, en dupliquant les données au lieu de partager des ressources communes. De cette façon, une application basée sur les microservices fonctionne plus efficacement et n'est pas imitée par les opérations de données réalisées par d'autres services.
Rapidité
Les implémentations simples réalisées avec la SOA peuvent bénéficier d'une vitesse convenable, mais la latence des données augmente à mesure que les développeurs ajoutent de nouveaux services au système. Tous les services se disputent les mêmes ressources de communication et capacités de données.
Par contraste, les architectures de microservices restent agiles et réactives à mesure que le système évolue, car elles ne partagent pas de ressources qui se chevauchent. Les développeurs peuvent affecter et augmenter les ressources de calcul d'un microservice spécifique si la demande de trafic augmente, permettant ainsi aux applications basées sur les microservices de s'exécuter à une vitesse correcte à tout moment.
Flexibilité de gouvernance
Les applications basées sur la SOA assurent une gouvernance cohérente des données dans les référentiels communs utilisés par différents services.
Cependant, les développeurs travaillant avec des microservices peuvent décider de mettre en place des stratégies de gouvernance différentes pour les unités de stockage de données indépendantes. Les équipes de développement collaborent plus efficacement et sont libres de déterminer les mécanismes de gouvernance des données.
Faire le bon choix : SOA vs. microservices
Grâce à l'architecture orientée services (SOA) et aux microservices, les entreprises disposent de différentes manières de migrer d'une architecture monolithique vers des environnements cloud. En fonction de certains facteurs, une méthode peut être mieux adaptée que l'autre en pratique.
SOA
Les entreprises dotées d'applications d'entreprise autonomes ou héritées sont avantagées par une architecture SOA. La SOA simplifie les logiciels conventionnels en pièces modulaires plus petites. Elle met également en commun les ressources partagées afin de rationaliser les fonctionnalités de l'entreprise. Plutôt que de créer des services redondants qui se chevauchent, les développeurs peuvent réutiliser les services SOA existants pour implémenter davantage de solutions métier.
Microservices
L'architecture de microservices est idéale pour accompagner les équipes de développement agiles. Les développeurs peuvent apporter des modifications rapides et incrémentielles au code sans affecter la stabilité de l'application à l'aide d'outils d'intégration et de livraison continues (CI/CD). Les microservices conviennent parfaitement lorsque les développeurs ont les objectifs suivants :
- Utiliser différents langages, bibliothèques ou cadres de programmation pour créer une seule application
- Associer des services individuels créés avec différents cadres logiciels
- Mettre en service des ressources informatiques et mettre à l'échelle des services distincts en temps réel
Les microservices permettent aux entreprises de profiter de fonctionnalités cloud modernes et de déployer des centaines de microservices en toute simplicité.
Résumé des différences : SOA vs. microservices
| SOA |
Microservices |
|
| Mise en œuvre |
Différents services avec des ressources partagées. |
Plus petits services indépendants et destinés à un objectif spécifique. |
| Communication |
Un ESB utilise plusieurs protocoles de messagerie comme SOAP, AMQP et MSMQ. |
API, service de messagerie Java, Pub/Sub |
| Stockage de données |
Stockage de données partagé. |
Stockage de données indépendant. |
| Déploiement |
Difficile. La reconstruction complète est nécessaire pour les petites modifications. |
Facile à déployer. Chaque microservice peut être conteneurisé. |
| Réutilisabilité |
Des services réutilisables grâce à des ressources communes partagées. |
Chaque service dispose de ses propres ressources indépendantes. Vous pouvez réutiliser les microservices par l'intermédiaire de leurs API. |
| Rapidité |
Ralentit à mesure que de nouveaux services sont ajoutés. |
Vitesse constante à mesure que le trafic augmente. |
| Flexibilité de gouvernance |
Gouvernance cohérente des données pour tous les services. |
Des politiques de gouvernance des données différentes pour chaque stockage. |
Comment AWS peut-il vous aider à répondre à vos exigences en matière de microservices ?
Concevez des applications modernes sur Amazon Web Services (AWS) avec des schémas d'architecture modulaire, des modèles opérationnels sans serveur et des processus de développement agiles. Nous offrons la plateforme la plus complète pour concevoir des microservices hautement disponibles qui impulsent des applications modernes de toute portée et échelle.
Voici comment vous pouvez utiliser les microservices sur AWS :
- Créer, isoler et exécuter des microservices sécurisés dans des conteneurs gérés afin de simplifier les opérations et de réduire les frais de gestion. Pour en savoir plus, consultez la page Conteneurs chez AWS.
- Utiliser AWS Lambda afin d'exécuter vos microservices sans provisionner ni gérer de serveurs.
- Choisir parmi 15 bases de données dans le Cloud AWS sur mesure, relationnelles et non relationnelles, pour prendre en charge l'architecture de microservices.
- Facilement surveiller et contrôler les microservices exécutés sur AWS avec AWS App Mesh.
- Surveiller les interactions complexes des microservices et régler les problèmes qui y sont associés avec AWS X-Ray.
Les microservices sur AWS vous permettent d'innover plus rapidement, de réduire les risques, d'accélérer les délais de commercialisation et de réduire votre coût total de possession. Commencez à utiliser les microservices sur AWS en créant un compte dès aujourd'hui.
