Huit raisons pour lesquelles l’avenir de la mise à l’échelle des conteneurs passe par le maillage de services

Lori Mac VittieIngénieur émérite et évangéliste en chef | F5

Les microservices permettent d’accélérer considérablement le développement, mais la complexité de ces architectures réside dans la communication interservices dont ils dépendent.

Il existe actuellement au moins trois options d’architecture différentes pour faire évoluer des microservices conteneurisés. Chacune repose, comme toute mise à l’échelle, sur un répartiteur de charge basé sur un proxy. Chacune présente ses propres difficultés. Plusieurs d’entre elles découlent du simple fait que la mise à l’échelle dans les environnements de conteneurs repose souvent sur les tables IP, qui ne prennent en charge que de manière limitée ce qui se situe au-dessus des couches réseau traditionnelles (à savoir IP et TCP).

Tous ces proxys assurent la même fonction essentielle : la mise à l’échelle des services répartis dans l’environnement de conteneurs. Ce qui est étonnant, c’est que les services sont des entités éphémères. Ils n’existent pas réellement, si ce n’est dans les fichiers de ressources (de configuration) qui les définissent. Le problème, pour les solutions de mise à l’échelle basées sur les tables IP, est que ces services sont des entités de couche 7 (HTTP), qui servent souvent de « backend » à un seul appel d’API plutôt qu’à une application entière.

Les applications, telles que nous les connaissons, peuvent sembler constituer, côté client, un ensemble unique et cohérent. En réalité, elles se composent de nombreux microservices distincts (et distribués). Certains de ces services sont purement internes et conçus pour être utilisés par d’autres services. Cela implique donc de nombreux échanges entre services au sein de l’environnement conteneurisé.

Vous avez besoin d’un routage L7 (HTTP) dans ces environnements, car tout repose sur des API via HTTP/HTTP2. Vous devez également adopter une approche cohérente en matière de sécurité, d’authentification et d’application des politiques. Rien de tout cela n’est possible avec une approche basée sur iptables.

Comme souvent, l’Open Source vient à la rescousse. Plusieurs maillages de services open source ont vu le jour pour relever ces défis. À l’instar de nombreux projets Open Source, ces maillages de services (comme Istio) sont enrichis par des projets tels qu’Aspen Mesh qui leur apportent des fonctionnalités (et un support) permettant de proposer des solutions de niveau entreprise.

Ces initiatives élargies visent à résoudre les huit difficultés auxquelles les organisations sont confrontées lorsqu’elles déploient des microservices dans des conteneurs.

Voici les huit défis et la manière dont un maillage de services peut les surmonter :

1. Build – Face à ce défi, un maillage de services n’a pas grand-chose à offrir, si ce n’est l’intégration des politiques aux chaînes d’outils CI/CD et la mise en place d’un modèle de configuration déclaratif permettant de traiter le maillage de services comme une infrastructure en tant que code.
2. Tests et intégration – Un maillage de services peut être utile à ce stade en garantissant l’application de politiques cohérentes entre les environnements de développement, de test, de production, etc. Certaines organisations cherchent à supprimer complètement les déploiements par étapes. Cette approche a bien fonctionné par le passé, mais elle constitue l’un des obstacles qui ralentissent le processus de déploiement. Ces organisations cherchent un moyen de déployer les services directement en production et d’utiliser des mécanismes d’orientation du trafic et de restauration pour gérer les défaillances.
3. Gestion des versions – Un maillage de services peut faire office de passerelle API de base afin d’acheminer le trafic en fonction de variables telles que la version de l’API, et même convertir les versions pour faciliter les périodes de transition entre différentes versions d’une API. Il n’est pas toujours possible d’imposer la mise à niveau des clients, en particulier pour les applications grand public, ce qui signifie que des requêtes correspondant à plusieurs versions peuvent être reçues. Un maillage de services peut convertir les requêtes destinées aux anciennes versions de l’API vers la version la plus récente, afin de réduire les coûts et la charge liés à la maintenance de plusieurs versions d’une même API.
4. Déploiement – Grâce à sa parfaite maîtrise du protocole HTTP, un maillage de services est idéal pour mettre en œuvre des déploiements bleu/vert, des tests canari et le routage du trafic.
5. Journalisation – La journalisation distribuée pose toujours problème, et plus encore dans les environnements où la durée de vie des instances est très variable. Un maillage de services offre un emplacement commun et centralisé pour mettre en œuvre la journalisation, ainsi que la possibilité d’effectuer des opérations telles que le traçage des requêtes.
6. Supervision – La supervision est au cœur du passage à l’échelle. Bien que les applications puissent mettre en œuvre certaines fonctions (nouvelles tentatives, disjoncteurs, etc.) pour faire face à la défaillance inévitable d’un service, cela leur impose une charge qu’elles ne devraient pas avoir à supporter. Un maillage de services prend en charge les communications interservices et fournit un point central pour la supervision. L’objectif est de se concentrer sur le MTTD et le MTTR en production, car l’exploitation en production est complexe et les défaillances sont inévitables.
7. Débogage – Plus un système est complexe, plus il est difficile à déboguer. Un maillage de services peut faciliter l’analyse des causes profondes, fournir des statistiques et des notifications avant défaillance grâce à l’analytique et à la télémétrie, et mettre les conteneurs en quarantaine plutôt que de les arrêter afin de pouvoir les examiner en profondeur. Cela est particulièrement utile lorsque la défaillance est due à des fuites de mémoire lentes.
8. Réseau – Le réseau reste essentiel pour les conteneurs, peut-être même davantage que dans des environnements moins complexes. La volonté de dissocier les services de ce réseau implique de nombreux composants qu’il n’est pas souhaitable d’implémenter dans chaque service : découverte de services, gestion des certificats et du protocole SSL, disjoncteurs, nouvelles tentatives, surveillance de l’état de santé, etc. L’objectif des microservices était de « coder localement, coder en petit ». La nécessité d’intégrer des fonctions liées au réseau alourdit les microservices et génère une dette architecturale et technique supplémentaire. Un maillage de services prend en charge ces fonctions et offre l’évolutivité et la sécurité recherchées sans ralentir le développement.

Le maillage de services est une évolution prometteuse qui associe les principes modernes du cloud et des conteneurs aux bases solides de l’évolutivité. Le maillage de services devrait continuer à gagner du terrain en 2018, à mesure que l’adoption des conteneurs progresse et que la demande en matière d’évolutivité et de support de niveau entreprise augmente.

À propos de l’auteur

Lori Mac VittieIngénieur émérite et évangéliste en chef | F5

Lori MacVittie est ingénieure émérite et évangéliste en chef au sein du bureau du directeur technique de F5. Elle possède une expertise approfondie dans la fourniture d’applications, les stratégies d’automatisation et les infrastructures. Elle est réputée pour sa capacité à rendre la complexité intelligible, qu’elle définisse des garde-fous pour les agents d’IA, analyse des architectures multicloud fragiles ou explore les limites des systèmes évolutifs. Elle cumule plus de trente ans d’expérience dans le secteur, couvrant le développement d’applications, l’architecture informatique ainsi que l’exploitation des réseaux et des systèmes. Avant de rejoindre F5, elle a été rédactrice spécialisée dans les technologies et a reçu plusieurs distinctions. MacVittie est titulaire d’un master en informatique et est une autrice prolifique dont les publications couvrent la sécurité, le cloud et l’architecture d’entreprise. Elle est également une passionnée de jeux de société et de jeux vidéo, et assume pleinement ses avis bien tranchés sur le fromage.

Autres articles de Lori Mac Vittie