BT

Microservices vs Bibliothèques Partagées

| par Jan Stenberg Suivre 33 Abonnés , traduit par Nicolas Frankel Suivre 7 Abonnés le 07 oct. 2014. Durée de lecture estimée: 2 minutes |

Dans un article récent, Robert C. Martin conseille de démarrer avec des bibliothèques partagées et une architecture basée sur les plugins, et de n'introduire la ségrégation entre les services et les microservices uniquement que lorsque cela se révèle insuffisant.

Dans sa réponse, Giorgio Sironi invoque des contre-arguments, mettant en exergue les différences entre les interactions parmi les microservices et celles parmi les objets d'une application, et met en garde contre les coûts de migration vers les microservices d'une base de code existante.

Robert (Oncle Bob) décrit les microservices comme de petits exécutables isolés qui communiquent entre eux, l'une des manières courantes étant http et REST, avec comme avantages la possibilité de tester de plus petites parties, la flexibilité dans le déploiement et la liberté du choix de stockage des données et des autres composants d'infrastructure pour chaque service. Robert résume ces avantages sous le terme de Capacité de Déploiement Indépendante, mais rappelle qu'il est possible d'atteindre la plupart de ceux-ci par l'utilisation de bibliothèques partagées p.e. fichiers jar ou DLLs. L'un des désavantages de l'utilisation des microservices, sur lequel Robert insiste, est que la communication entre les services via p.e. les sockets prend beaucoup plus de temps en comparaison de la communication directe entre les objets dans les bibliothèques partagées.

Robert note qu'il n'est pas entièrement contre les microservices mais qu'ils doivent être utilisés de manière judicieuse. Bien souvent, les bibliothèques partagées sont plus qu'adéquates et évitent le coût supplémentaire de la communication entre les processus.

Giorgio, un développeur italien, mentionne d'autres avantages qu'il perçoit dans l'utilisation des microservices : ils peuvent monter en charge de manière indépendante l'un de l'autre et être écrits dans des langages différents. Il trouve également plus aisé de déceler les serveurs avec des charges élevées qui peuvent nécessiter un remplacement et il croît qu'ils simplifient les améliorations dans l'implémentation ; remplacez juste un microservice par un autre.

Giorio note également l'impact négatif que les appels synchrones peuvent avoir sur les systèmes distribués en se référant à une étude écrite en 1996. Il préfère utiliser à la place un style d'intégration Commande et Evènement pour les microservices, qui rend leurs interfaces publiques très différentes de celles que les objets exposent, en opposition avec le conseil de Robert de toujours commencer avec une architecture basée sur les plugins.

Dans un tweet récent, Rober proclamait que "Monolithe vs Microservices est une fausse dichotomie", ce qui a démarré une discussion parmi quelques participants.

Plus tôt cette année, Peter Kriens affirmait avoir défini les µservices OSGi comme un service qui communique toujours au sein du même processus, et ceci il y déjà quatre ans.

Evaluer cet article

Pertinence
Style

Bonjour étranger!

Vous devez créer un compte InfoQ ou cliquez sur pour déposer des commentaires. Mais il y a bien d'autres avantages à s'enregistrer.

Tirez le meilleur d'InfoQ

Donnez-nous votre avis

Html autorisé: a,b,br,blockquote,i,li,pre,u,ul,p

M'envoyer un email pour toute réponse à l'un de mes messages dans ce sujet

Entre deux ? by Romain Bessuges-Meusy

Et pourquoi n'existerait-il pas un juste milieu ? En utilisant une couche d'abstraction niveau HTTP, on peut mocker requêtes et réponses et approcher les performances de librairies partagées.
Dans ce cas, les deux microservices sont exécutées sur le même système et la couche d'abstraction HTTP résout localement les requêtes en court-circuitant socket, TCP/IP, HTTP, serveur web et routeur logiciel !

Re: Entre deux ? by Mathieu Bruyen

Ca me semble similaire à CORBA et cie. Selon Martin Fowler c'est une mauvaise idée de vouloir abstraire les appels distants pour qu'ils se comportent comme si il étaient locaux: martinfowler.com/articles/distributed-objects-m...

Sur l'article je trouve la stratégie bien plus judicieuse que de vouloir découper un système en services à priori. L'architecture émmerge progressivement et les services en ressortent. Par contre cela nécessite de la discipline pour ne pas tout emmêler.

Html autorisé: a,b,br,blockquote,i,li,pre,u,ul,p

M'envoyer un email pour toute réponse à l'un de mes messages dans ce sujet

Html autorisé: a,b,br,blockquote,i,li,pre,u,ul,p

M'envoyer un email pour toute réponse à l'un de mes messages dans ce sujet

2 Discuter

Se connecter à InfoQ pour interagir sur ce qui vous importe le plus.


Récupérer votre mot de passe

Follow

Suivre vos sujets et éditeurs favoris

Bref aperçu des points saillants de l'industrie et sur le site.

Like

More signal, less noise

Créez votre propre flux en choisissant les sujets que vous souhaitez lire et les éditeurs dont vous désirez suivre les nouvelles.

Notifications

Restez à jour

Paramétrez vos notifications et ne ratez pas le contenu qui vous importe

BT