Huit raisons pour lesquelles l'avenir des conteneurs évolutifs réside dans le maillage de services

Les microservices sont excellents pour la vitesse de développement, mais la complexité de ces architectures réside dans la communication de service à service dont dépendent les microservices.

Il existe actuellement au moins trois options architecturales différentes pour la mise à l’échelle des microservices conteneurisés . Chacun d'entre eux est basé - comme toutes les échelles - sur un équilibreur de charge basé sur un proxy. Chacun a son lot de défis. Plusieurs d’entre eux découlent du simple fait que l’échelle dans les environnements de conteneurs repose souvent sur des tables IP et sa fluidité limitée avec tout ce qui se trouve au-dessus des couches réseau traditionnelles (c’est-à-dire IP et TCP).

Tous ces proxys fournissent la même fonctionnalité principale : la mise à l’échelle des services distribués dans l’ environnement de conteneur. Le plus fou, c’est que les services sont des constructions éphémères. En réalité, ils n’existent pas, sauf dans les fichiers de ressources (configuration) qui les définissent. Le problème des solutions de mise à l’échelle basées sur des tables IP est que ces services sont des constructions de couche 7 (HTTP), servant souvent de « backend » pour un seul appel d’API au lieu d’une application entière.

Les applications, telles que nous les connaissons, peuvent apparaître du côté client comme une construction unique et holistique. En réalité, ils sont constitués de nombreux microservices différents (et distribués). Certains de ces services sont purement internes, conçus pour être utilisés par d’autres services. Ce qui implique beaucoup de communication de service à service au sein de l’environnement conteneurisé.

Vous avez besoin d'un routage L7 (HTTP) dans ces environnements car tout est une API via HTTP/HTTP2. Vous avez également besoin d’une position de sécurité, d’une authentification et d’une application des politiques cohérentes. Rien de tout cela n’arrivera avec une approche basée sur des tables IP.

Comme c’est souvent le cas, l’Open Source vient à la rescousse. Plusieurs services mesh open source ont été créés pour répondre à ces défis. Comme c'est le cas pour de nombreux projets Open Source, ces maillages de services (comme Istio ) sont étendus par des projets comme Aspen Mesh avec des capacités (et un support) qui fournissent des solutions de niveau entreprise.

Ces efforts élargis visent à résoudre les huit défis auxquels les organisations sont confrontées lorsqu’elles déploient des microservices dans des conteneurs.

Voici les huit défis et comment un service mesh peut les surmonter :

1. Créer – Il s’agit de l’un des défis qu’un service mesh n’a pas grand-chose à offrir, à part intégrer la politique aux chaînes d’outils CI/CD et garantir un modèle déclaratif de configuration afin que le service mesh puisse être traité comme une infrastructure en tant que code.
2. Test et intégration – Un service mesh peut être utile ici en garantissant une politique cohérente entre le développement, les tests, la production, etc. Certaines organisations cherchent à éliminer complètement les déploiements par étapes. Cette approche a bien fonctionné dans le passé, mais elle constitue l’un des obstacles qui insèrent de la latence dans le processus de déploiement.  Ces personnes recherchent un moyen de déployer des services directement en production et d’utiliser des mécanismes de pilotage du trafic et de restauration pour gérer les pannes.  
3. Contrôle de version – Le maillage de service peut agir comme une passerelle API de base pour acheminer le trafic en fonction de variables telles que la version de l'API et même traduire les versions pour aider pendant les périodes de transition de version de l'API. Les mises à niveau des clients, en particulier pour les applications destinées au grand public, ne peuvent pas toujours être forcées, ce qui signifie que des demandes arrivent pour plusieurs versions. Un service mesh peut traduire les demandes d'anciennes versions d'API vers les plus récentes afin de contribuer à réduire les coûts et la charge liés à la maintenance de plusieurs versions de la même API.
4. Déploiement – Grâce à sa capacité à parler couramment HTTP, un service mesh est un endroit idéal pour permettre les déploiements Blue/Green , les tests Canary et la direction du trafic.
5. Journalisation – La journalisation distribuée est toujours un problème, et elle est encore plus gênante dans les environnements où les instances vivent pendant des périodes de temps très variables. Un service mesh offre un emplacement commun et centralisé pour implémenter la journalisation ainsi que la possibilité d'exécuter des fonctions telles que le traçage des demandes.
6. Surveillance – Au cœur de l’échelle se trouve la surveillance. Bien que les applications puissent implémenter certaines fonctions (nouvelles tentatives, coupure de circuit, etc.) pour faire face à l'échec inévitable d'un service, cela représente une charge pour l' application qu'elle ne devrait pas avoir à supporter. Un maillage de services prend en charge la charge de la communication de service à service et fournit un espace de surveillance. L’objectif est de se concentrer sur le MTTD et le MTTR en production, car l’exécution en production est difficile et l’échec est inévitable.
7. Débogage – Plus un système est complexe, plus il est difficile à déboguer. Un service mesh peut aider à l'analyse des causes profondes, fournir des statistiques et des notifications préalables aux pannes à l'aide d'analyses et de télémétrie, et mettre en quarantaine les conteneurs au lieu de les tuer afin qu'ils puissent être examinés en profondeur. Cela est particulièrement utile dans les cas où l’échec est dû à des fuites de mémoire lentes.
8. Mise en réseau – La mise en réseau reste essentielle pour les conteneurs, peut-être plus que dans des environnements moins complexes. Le désir d'abstraire les services de ce réseau signifie qu'il existe de nombreux éléments mobiles que vous ne souhaitez pas implémenter dans chaque service : Découverte de services, gestion SSL et certificats, disjoncteurs, nouvelles tentatives, surveillance de l'état de santé, etc. L’objectif des microservices était de « coder localement, coder petit ». L’introduction de la nécessité d’inclure des fonctions liées au réseau gonfle les microservices et introduit une dette architecturale et technique supplémentaire. Un service mesh prend en charge ces fonctions et offre l'évolutivité et la sécurité souhaitées sans ralentir le développement.

Service Mesh est une évolution passionnante qui combine les principes modernes du cloud et des conteneurs avec les bases solides de l'évolutivité. Attendez-vous à voir le service mesh gagner du terrain alors que 2018 continue de voir l’adoption croissante des conteneurs et la demande d’une évolutivité et d’un support de niveau entreprise.