Introduction
Dans notre dernier article sur les microservices nous vous avions teasé sur les miniservices, un système que l’on peut presque comparer à un compromis entre une architecture monolithique et une architecture en microservices.
Quelles différences entre microservices et les miniservices ?
Lorsque nous avons entendu parler pour la première fois de miniservices et de nanoservices, nous avons mis en doute la parole de notre interlocuteur sur la véracité et l’existence de ces types d’architecture. Et pourtant…
Il faut convenir que la nuance est fine entre microservices et miniservices, même si l’on peut d’ores et déjà considéré que de nombreuses entreprises les utilisent déjà sous le nom de microservices sans vraiment avoir considéré cette même nuance.
Quelle est cette nuance ? Les miniservices sont en fait un simple (léger) amas de microservices qui permettent surtout de limiter le fractionnement des services et ainsi améliorer la recherche, la documentation et la maintenabilité du programme. Servant globalement sur les mêmes systèmes d’entreprise et de même taille que pour les microservices, les miniservices ont cet avantage de palier au défaut principal des microservices de ne pas pouvoir/savoir partager les données avec les autres services et, donc, se cantonner au traitement des siennes.
S’il est compliqué de donner une définition de la nuance, elle peut s’expliquer par le fait que les miniservices sont avant tout la récupération de ce qu’il y a de mieux dans les microservices, le tout rapporté au maximum de sa simplicité, notamment au niveau des données.

Comment se distingue-t-elle dans le monde de l’entreprise ?
D’après les retours de certains de nos consultants travaillant via des modèles architecturaux en microservices, c’est avant tout l’équipe de développeurs qui va tendre vers les micro-services ou les miniservices selon leur appétence sur les modèles d’intégration et des technologies à usiter.En sommes, et bien qu’il soit important de distancier la réussite commerciale d’une entreprise de la beauté de son architecture, le choix de la seconde influera de manière nette sur la première.
Un miniservice adopte l’approche pragmatique du concept d’architecture des microservices. Les microservices représentent un modèle architectural très spécifique, où Martin Fowler et d’autres ont clairement décrit comment ce modèle architectural devrait fonctionner et comment chaque service devrait exister et communiquer avec ceux qui l’entourent. Les miniservices sont comme les microservices en ce qui concerne l’agilité, l’évolutivité, la fonctionnalité et la liaison autour des services sans être tenus aux conditions préalables autour de la conception événementielle qu’une architecture de microservices puriste prescrirait.
En choisissant votre approche, il faut d’abord comprendre que vous n’avez pas toujours à suivre les exigences puristes des micro-services pour atteindre les mêmes objectifs. Tout peut encore être réalisé du point de vue de l’intégration sans suivre les exigences du modèle architectural des microservices. En effet, tandis que les miniservices ne visent à remplir qu’une seule et même fonction en tant que service pur et sont très utiles pour des fonctions classiques qui serviront à valoriser une seule fonctionnalité, les microservices auront une rentabilité moins directe. On peut donc d’ores et déjà considéré que les miniservices auront une utilité toute particulière pour les entreprises à besoin de rentabilité immédiate.
L’évolutivité est une raison importante d’adopter l’approche de l’architecture des microservices. HTTP ne résout pas le problème, mais ce n’est pas parce que vous avez une centaine ou un millier de services que HTTP est nécessairement le mauvais choix. Il peut être tout aussi fonctionnel que n’importe quelle autre technologie d’intégration. Mais il y aura un moment où la quantité de trafic rendra les choses peu pratiques.
Nous n’avons de cesse que de le répéter, mais il faut vraiment réfléchir à l’ensemble de son architecture en amont.
Et vous, qu’en pensez-vous ?