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.