La folie des microservices grand public : Les défis augmentent avec l’adoption
Il y a quelques années à peine, les microservices étaient une curiosité dont les développeurs discutaient avec une sorte d'enthousiasme vertigineux face aux possibilités et aux opportunités offertes par l'architecture d'application naissante.
Aujourd'hui, même nous, les gens du réseau, en parlons parce qu'ils sont devenus – comme le déclare la dernière étude de Lightstep – courants dans l'entreprise. Sérieusement. Dans notre rapport 2018 sur l’état de la distribution des applications , même les rôles liés au réseau ont indiqué qu’ils souhaitaient que les services d’application soient fournis dans des conteneurs. Il n’est donc pas surprenant de constater que l’enquête Lightstep susmentionnée a révélé que non seulement 91 % des personnes interrogées utilisent ou prévoient d’utiliser des microservices, mais que 86 % s’attendent également à ce qu’ils deviennent la valeur par défaut d’ici cinq ans.
Cela ne veut pas dire qu’il n’y a pas de défis. En fait, 99 % des personnes interrogées dans le cadre de l’enquête de Lightstep ont signalé des difficultés lors de l’utilisation de microservices. D’après les réponses, on pourrait raisonnablement dire que presque tout est plus difficile (et parfois plus coûteux) avec les microservices.
L'enquête a mis en évidence des défis commerciaux et opérationnels allant de l'augmentation du coût de l'agrégation des journaux (21 %) à l'ignorance de ce qu'il faut faire avec l'augmentation des données (17 %) jusqu'aux difficultés de résolution des problèmes (73 %).
Plus troublant encore, cependant, est le constat selon lequel « 98 % des personnes confrontées à des difficultés pour identifier la cause profonde des problèmes dans les environnements de microservices signalent que cela a un impact commercial direct. »
C’est l’un des principaux défis évoqués ailleurs, généralement sous les termes de « visibilité » ou d’« observabilité », selon que vous êtes du côté réseau ou que vous travaillez avec DevOps.
Les deux décrivent essentiellement les mêmes capacités : être capable de voir ce qui se passe lorsque les messages traversent le réseau du client au service et vice-versa. Dans l’environnement des conteneurs, cela est particulièrement difficile en raison de la portée et de l’échelle des services impliqués.
Avec une application Web traditionnelle à trois niveaux, vous disposez de trois ensembles de journaux et de trois systèmes que vous devez suivre. Avec une architecture de microservices, probablement dotée d’une API potentiellement utilisée par les clients Web et mobiles, vous pouvez avoir des dizaines ou des centaines de services différents dont vous devez assurer le suivi.
Le modèle de mise à l’échelle reste le même : nous effectuons une mise à l’échelle horizontale (vers l’extérieur) avec des clones, mais l’ampleur au sein d’un environnement de conteneur est nettement plus grande. C'est comme jouer au chat et à la taupe avec cent trous au lieu de dix. Déterminer le chemin emprunté par une transaction donnée s’avère être un véritable défi, c’est le moins qu’on puisse dire. Surtout quand le chemin a peut-être disparu. Après tout, le principe de la plupart des environnements de conteneurs est d’échouer rapidement et de remplacer les instances plutôt que d’attendre une intervention manuelle.
Il existe plusieurs façons de relever ce défi. En premier lieu, il faut disposer d’instruments permettant de détecter et de résoudre les problèmes. Cette approche n’est pas nouvelle, mais elle est rendue plus difficile par la nature volatile des environnements de conteneurs. Néanmoins, l’insertion d’éléments de traçage (tels que des en-têtes HTTP personnalisés avec des identifiants uniques) peut être une aubaine pour les opérations lorsqu’elles tentent de détecter des erreurs ou des problèmes de performances. Bien qu'il ne s'agisse généralement pas d'une capacité des options de mise à l'échelle des conteneurs natifs, c'est une capacité que les maillages de services abordent dans le cadre de leurs offres.
Deuxièmement, il est possible de mettre en quarantaine les microservices défaillants pour permettre aux opérateurs et aux développeurs d’examiner le système dans l’état qui a provoqué sa défaillance. La quarantaine supprime essentiellement le conteneur défectueux de l'environnement actif afin que les appels ne lui soient plus envoyés, mais le maintient en vie pour analyse et inspection.
Il n’existe pas de baguette magique, mais la possibilité de suivre et de mettre en quarantaine les conteneurs dans les déploiements basés sur des microservices peut contribuer grandement à réduire le délai moyen de résolution (MTTR) et à réduire l’impact sur l’entreprise.