BT

Accueil InfoQ Actualités Microservices vs Bibliothèques Partagées

Microservices vs Bibliothèques Partagées

Favoris

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

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

Commentaires de la Communauté

  • Entre deux ?

    by Romain Bessuges-Meusy /

    Ce message a été marqué comme possible SPAM. Un modérateur le relira et le publiera sans notification dans les 24 heures. Merci.

    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 /

    Ce message a été marqué comme possible SPAM. Un modérateur le relira et le publiera sans notification dans les 24 heures. Merci.

    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

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

BT

Votre profil est-il à jour? Merci de prendre un instant pour vérifier.

Note: en cas de modification de votre adresse email, une validation sera envoyée.

Nom de votre entreprise:
Rôle dans votre entreprise:
Taille de votre entreprise:
Pays/Zone:
État/Province/Région:
Vous allez recevoir un email pour confirmer la nouvelle adresse email. Ce pop-up va se fermer de lui-même dans quelques instants.