Les microservices : est-ce réaliste ? Les avantages et inconvénients de l'architecture

La capacité de monter en charge ou "scalabilité" dans le jargon informatique est sans nul doute l'argument numéro 1 des microservices. "La taille réduite des services favorise les évolutions rapides ainsi que le dimensionnement du système", souligne Romain Niveau. "Les outils d’aujourd’hui permettent une scalabilité automatique des services pour absorber une charge importante tout en économisant les ressources quand la charge se fait plus faible."

Choisir les technologies les plus appropriées à chaque microservice

Autre avantage du microservice, son étanchéité totale offre une grande liberté de choix dans son implémentation. Jérôme Mainaud, architecte logiciel chez Ippon Technologies, détaille ainsi cet argument : "la séparation stricte des services impose de définir une interface et renforce l’encapsulation des composants en masquant complètement les détails d’implémentation. Les langages ne garantissent généralement pas ce même niveau d’encapsulation dans une application monolithique, ce qui conduit parfois à du code où des composants sont liés entre eux par leur implémentation et non plus par leur seule interface. Lorsque cette situation se généralise, on parle alors de code spaghetti dont la maintenance est digne des meilleurs films de Wes Craven !" L'encapsulation et l’utilisation d’un protocole de communication standard permettent d'utiliser des technologies et des langages différents pour chaque microservices et d’exploiter pour chacun d'eux les plus appropriés.

La topologie des microservices mis en œuvre par Netflix : un enchevêtrement permanent d'appels entre des milliers de microservices que seuls des logiciels sont à même de suivre. © Netflix

Rien n'empêche de faire cohabiter dans une même architecture des services Java avec des services développés en Ruby, Node.js, C++, etc. La règle n'est plus d'uniformiser l'ensemble des composants, mais de donner le choix à chaque chef de projet dans l'implémentation du microservice dont il a la charge. Une approche que peuvent avoir les géants de la Silicon Valley aux poches pleines et aux effectifs pléthoriques, mais qu'il convient de manier avec prudence selon l'architecture : "le cloisonnement des services permet d’utiliser le bon outil au bon endroit, c'est vrai. Chaque service peut en effet être codé dans un langage différent ou utiliser un framework spécifique selon le besoin. Attention toutefois à ne pas multiplier les frameworks et langages, ce qui entraînerait une maintenance plus compliquée" ajoute Jérôme Mainaud.

L'importance des logiciels d'automatisation

Autre critique souvent formulée à l'égard de cette architecture : sa complexité. Ce sont des milliers, des dizaines de milliers d'instances de microservices qui sont en permanence à l'œuvre dans les infrastructures de Google, Twitter ou Netflix. Chaque seconde, certaines meurent, d'autres sont instanciées et ce à grande échelle sur des milliers de serveurs situés dans plusieurs data centers. Administrer un tel capharnaüm n'est plus humainement possible sans une batterie de logiciels qui réalisent les tâches de base automatiquement. Le leitmotiv des équipes d'exploitation n'est plus d'administrer une plateforme, mais de développer des outils d'automatisation de l'administration. "La multiplication des services entraîne une complexification de la compréhension du système", souligne Jérôme Mainaud. "Il devient donc primordial d’avoir un système de monitoring performant se basant sur des indicateurs techniques mais aussi business permettant de connaître l’état de santé du système en temps réel."

Un autre impact dont le DSI va devoir tenir compte, c'est le coût en termes de puissance machine de ces microservices. "Il y a un risque de dégradation des performances", reconnait l'architecte. "Les appels entre services introduisent une latence réseau qui n’existait pas dans les applications monolithiques. Il est donc nécessaire de tester et mesurer les performances de façon systématique." En outre, alors que l'application monolithique était synonyme de panne exceptionnelle (mais catastrophique), dans le cas d'une application constituée d'une myriade de microservices, la panne devient courante. Au logiciel de détecter les microservices qui ne répondent plus et de router les appels applicatifs intelligemment, c'est-à-dire vers les services qui seront capables de répondre. "Heureusement, il existe des outils pour résoudre ces difficultés, notamment la suite de frameworks développés par Netflix", souligne Jérôme Mainaud.