Ce qui est vraiment différent entre SOA et Microservices

Avertissement

J'espère que je ne marche sur les orteils de personne ni n'offense les passionnés des deux concepts

Contexte

Je cherchais de réelles différences entre l'architecture orientée services et les microservices, sans trouver de réponse claire.

Je lis des choses comme:

• les effets secondaires de SOA
• SOA étant anti-modèle
• Les microservices sont venus corriger les échecs de SOA
• Les ESB ne sont pas vraiment des ESB mais plutôt des EAI
• Dépendance excessive envers les courtiers de messages
• Les vendeurs abusent de la notion de SOA et tentent de vendre leurs produits
• SOA se développe de façon incontrôlable

Mais encore, rien ne définit clairement les différences architecturales entre l'architecture orientée services (en tant que concept) et les microservices (en tant que concept)

D'après ce que j'ai compris, ils ont tous les deux:

• Fournisseurs de services, ne faisant qu'une seule chose
• Service Gateway / ESB exposant ces services aux consommateurs
• Consommateurs de services, accès aux services via ESB / Service Gateway

Question

Alors, y a-t-il autre chose que le réétiquetage de SOA en microservices? est-ce une contrainte technologique placée pour empêcher les microservices de devenir macro?

Remarque: je ne recherche pas d'opinions, seulement des faits concrets, espérons-le dans des puces

Références

• Questions d'ingénierie logicielle
• Site de Martin Fowler (je pense qu'il déteste ça beaucoup de temps)
• Monde de l'information
• Site Web de Michael Fethers
• Questions de débordement de pile

Mise à jour

Il semble qu'un débat similaire ait eu lieu dans une question de débordement de pile , avec des opinions divisées, que les microservices soient ou non une architecture orientée services déguisée.

Conclusion de la question SO:

• MS est un cas particulier de SOA
• Les MS approuvent les services d'hébergement d'applications de plus petite taille
• MS dépend de la technologie (l'utilisation de HTTP plutôt que des options de protocole ouvertes)
• MS s'appuie sur la technologie pour faire respecter la discipline (déploiement automatique des services)
• MS considère les ESB (mal), mais utilise des passerelles API dont IMHO est un type d'ESB

Cela conclut que MS est SOA, si ce qui suit est vrai:

• MS soutient-il la notion d'orchestration? Un ou plusieurs processus maîtres gèrent les workflows
• Existe-t-il une couche de courtier de messages dans MS? Un ensemble d'adaptateurs traduisant des formats de message de l'espace de message des producteurs de services aux consommateurs de services
• Les microservices peuvent-ils lire les données des applications d'entreprise monolithiques? Peut-il s'agir des API d'une application monolithique? ou doit-il s'agir d'applications autonomes autonomes, capables de fonctionner indépendamment?

Si la réponse à la dernière question s'avérait non, alors les microservices ne seraient pas capables de gérer des systèmes de workflow complexes, par exemple des systèmes de gestion de cartes de crédit ou des systèmes de rapprochement.

Fournisseurs de services, ne faisant qu'une seule chose

La principale différence, qui a des conséquences étendues sur le projet, est qu'avec les microservices, ces fournisseurs de services sont déployables et évolutifs indépendamment .

C'est super, car vous pouvez être plus agile. Si un service a besoin de changer, vous changez simplement celui-là, aucun de ses proches. Si vous voulez essayer un nouveau framework ou un nouveau langage, faites simplement un remplacement pour ce service. Si vous avez soudainement besoin d'une capacité de 100x, faites tourner de nouvelles machines avec ce service pour gérer cet afflux. Si vous souhaitez mettre à jour quelque chose, il suffit de le mettre à jour sans toucher à l' ensemble de l' application. Et cela rend les choses plus faciles à surveiller, à instrumenter, à partager entre les équipes, obsolètes ...

Mais cela a de lourdes implications:

• Votre processus de publication doit changer, car le déploiement de quelques services est très différent du déploiement de quelques dizaines de services.
• Votre processus de publication doit changer, car le déploiement d'un service sur une machine est très différent du déploiement sur quelques dizaines de machines.
• La conception, l'utilisation et le déploiement de votre base de données doivent changer, car cela n'a pas de sens de déployer un service s'il a besoin de déployer cette grande base de données partagée pour fonctionner (en cassant tous vos autres services).
• Votre conception et votre utilisation des bibliothèques doivent changer car cela n'a pas de sens de déployer un service s'il a besoin de mettre à jour cette bibliothèque partagée (en cassant tous vos autres services).
• Votre enregistrement / autorisation / gestion des sessions / etc besoins de changement , car il est assez facile de partager des choses quand vous êtes juste un service, mais différent quand vous avez un groupe de services de petits indépendants qui composent le produit - et ils vont à veulent partager des trucs. Oh, et toutes ces choses partagées doivent faire face à la possibilité d'être sur différentes versions.
• Votre communication doit changer. Avec peu de services, vous pouvez casser les choses le long des lignes où la communication ne se produit pas souvent et / ou pourrait se produire lentement. Avec les microservices, ils vont beaucoup se parler et une latence élevée ne va pas le couper.

Voici les résultats La seule différence évidente entre SOA et Microservices est la notion de

Smart Endpoints Dumb Pipes

Contrairement à SOA , cela dépendrait de consommateurs et de producteurs de services inconscients, déléguant la gestion du trafic, la traduction du format des messages et l'orchestration des services à des systèmes externes, par exemple ESB, Service Orchestrator, Message Broker.