Après l’échec des SOA, dû en grande partie à la granularité trop élevée des services, pas plus de 200 par entreprise, on voit apparaître les MSA (Micro-Services Applications), qui reprennent le même concept, celui de l’urbanisation des services, mais sans la nécessité de les maintenir dans le cadre des métiers, avec une granularité beaucoup plus faible et fondées sur des technologies plus récentes, REST pour le protocole de sollicitation par exemple et JSON, comme format d’échanges.

Le problème est que si la définition des services est plus simple qu’avec les SOA, car il y a moins de monde à mettre d’accord, l’orchestration et l’exécution sont à priori beaucoup plus complexes, qui vont nécessiter un plus grand nombre d’interactions entre les services, intermédiations techniques qu’il faudra soit développer soi-même (ce qui est illusoire), soit passer par les fourches caudines d’un bus, dont on sollicitera les fonctionnalités.

Très grosses difficultés d’exploitation

Ce que l’on gagne avec les MSA par rapport aux SOA, on le perd en simplicité d’exploitation, car orchestrer des centaines de micro-services, sera évidemment beaucoup plus compliqué que s’il n’y en avait que 3 ou 4. Sachant que chaque micro-service sera installé dans son propre environnement d’exécution, généralement un container, qui comportera l’application et les routines système pour lui permettre de communiquer avec les services système installés sur sa plate-forme matérielle, la JVM par exemple, s’il s’agit d’un code Java.

Sans compter la consommation de ressources, puisqu’il y aura autant de plates-formes que de micro-services. Ce qui risque d’être très lourd.

De plus, la technologie est encore jeune, qui nécessite de monter quelques « échafaudages » un peu branlants, tant les API sur lesquelles on pourrait se baser manquent pour l’instant de maturité.

Nous avons expliqué par le détail quelles sont les techniques sur lesquelles on peut se reposer aujourd’hui, qui en termes d’API peuvent se résumer en quatre grandes familles :

les intégrés tels le « Service Fabric » de Microsoft, qui traitent la totalité des besoins, dans un environnement Windows mais aussi Linux
les API dédiées, telles que celles qui traitent les problèmes de communication entre services, en passant par un bus évènementiel, celui-ci étant un format d’échanges de données, plus qu’une véritable API (mais ce n’est pas obligatoire, il existe d’autres bus…)
les API de répartition de charge, pour des questions de sécurité et de performances
les API d’administration et de monitoring (Kubernetes, Helios, Swarm…)

Le risque aujourd’hui est de partir sur une voie non pérenne qu’il faudra abandonner dans quelques mois, ce qui serait d’autant plus gênant que la MSA est au cœur des architectures applicatives, un passage obligé, une plaque tournante incontournable, dès lors que l’on aura opté pour cette forme de réutilisation.

Que faut-il faire ?

S’il est un domaine où l’expression « il est urgent d’attendre » s’applique, c’est bien celui des MSA. Le terrain est encore trop incertain, pour s’aventurer dans un domaine qui peut être aussi décevant que l’ont été les SOA.

En attendant, rien n’empêchera les entreprises de préparer le travail. A délimiter les domaines qui leur semblent éligibles pour justifier une refonte éventuelle de leurs applications en mode MSA. Pour procéder à une phase lourde de modélisation aussi, sans laquelle le processus d’urbanisation aura toutes les chances de de ne pas fonctionner.

A vouloir trop se précipiter et à écouter sans recul les consultants qui voient dans les MSA une excroissance toute aussi lucrative que les SOA, les projets d’urbanisation risquent de se réduire à quelques Web Services et d’être abandonnés tout aussi piteusement que les SOA.

Ce qui est gênant dans les MSA et les rapprochent des SOA, c’est que ce sont les dirigeants qui sont les premiers convaincus. Eblouis par des promesses de réduction des coûts, d’industrialisation des processus de développement, par des réductions d’effectifs qui n’arrivent jamais.

Nous maintenons que les MSA ne sont pas mûres et ce n’est pas parce que le haut management des compagnies se dit convaincu que cela nous fera changer d’avis. A chacun son métier.

Ne leur en déplaise, l’approche MSA est avant tout technique et la réutilisation est un palier qui va coûter (très) cher. Et ce n’est pas parce que l’on aura donné l’instruction de réutiliser un code, que celui-ci sera effectivement réutilisable.

Nous avons maintenant 12 ans d’expériences et de constats d’échecs sur les SOA, qui a de très rares exceptions, se sont traduites par des gouffres financiers sans lendemains.

Même si nous pensons que les MSA peuvent constituer à terme une architecture crédible, il faudra faire beaucoup d’efforts pour les faire passer dans la boîte à outils de nos développeurs.

En attendant, un minimum de prudence s’impose.