Le traducteur de langage familier de conteneur pour NetOps

Il y a des jours où le jargon qui sort du monde des conteneurs vous fait tourner la tête. Chaque nouvelle capacité ou fonctionnalité offerte par des solutions connexes (service mesh, orchestrateurs, registres) semble nécessiter un nouveau terme ou une nouvelle expression. Cette phrase a souvent du sens pour DevOps, mais évoque une expression louche et confuse de la part de NetOps.

Un peu comme celui que tu fais quand je demande où se trouve le barboteur le plus proche. Vous l'appelez une fontaine à eau. Dans le Wisconsin, on l'appelle un bubbler. Même chose, terme différent.

Il s’avère qu’un grand nombre des « nouvelles » capacités et fonctionnalités liées à la mise à l’échelle des conteneurs en interne et dans les scénarios multicloud ne sont en réalité que des fontaines à eau que DevOps appelle un barboteur. Ce conflit d'expressions familières peut provoquer des frictions avec NetOps à mesure que les conteneurs continuent de se généraliser sans relâche. Même si les clusters de conteneurs conservent une existence isolée, de type mini-cloud, en production, il existe toujours des points de contact avec le réseau d'entreprise sur lesquels NetOps continue de régner. Et invariablement, NetOps et DevOps devront travailler ensemble pour faire évoluer ces clusters en toute sécurité dans un monde multi-cloud.

Contrôleur d'entrée

• Comme cela a été noté , le terme « contrôleur d’entrée » a jeté une nouvelle couche de peinture sur l’équilibrage de charge de la couche 7 (commutation de contenu, routage de contenu, etc…). Un contrôleur d'entrée est un proxy prenant en charge la couche 7 (HTTP) qui achemine les requêtes vers la ressource appropriée à l'intérieur d'un cluster de conteneurs.  La différence significative entre les proxys HTTP utilisés par NetOps dans le réseau et ceux servant de points d’entrée aux clusters de conteneurs est qu’un contrôleur d’entrée doit être compatible avec les conteneurs. Par « considérant le conteneur », j'entends qu'il est configuré et géré automatiquement en fonction des modifications qui se produisent dans l' environnement de conteneur , en particulier celle du fichier de ressources qui décrit comment l'entrée doit acheminer les demandes entrantes.

Équilibrage de charge prenant en compte la latence

• Cela semble cool et frais, n'est-ce pas ? Mais lorsque vous retirez le kimono, NetOps hochera la tête avec emphase en découvrant qu'il ne s'agit en réalité que de l'exploitation d'un algorithme d'équilibrage de charge à « réponse la plus rapide ». L’objectif est d’améliorer les performances de l’application en « déplaçant le trafic loin des instances lentes ». La raison pour laquelle cela est mentionné est que, d’une manière générale, les algorithmes d’équilibrage de charge natifs utilisés par les orchestrateurs de conteneurs sont apathiques. Round Robin est à peu près la norme, et nous savons qu'il s'agit du dernier algorithme que vous devriez choisir si vous essayez d'optimiser les performances. Être capable d'acheminer les requêtes en fonction des meilleures performances est assez important étant donné que chaque appel microservice-microservice effectué pour répondre à une seule requête client ajoute sa propre latence.

Entrée multi-cluster

• Je vais commencer par dire que cela semble bien plus cool que le terme que l’industrie utilise depuis près de vingt ans maintenant. Il s’agit essentiellement de GSLB (Global Server Load Balancing). Ouais, je sais que vous êtes déçu, mais sous le capot, c'est ce que fait l'entrée multi-cluster . Vous prenez un contrôleur d’entrée et vous saupoudrez dessus un peu de gestion du trafic global et voilà ! Vous disposez de GSLB pour les clusters de conteneurs dans une configuration multicloud. Je vote pour remplacer GSLB par ce terme du côté NetOps, car cela semble plus impressionnant.

Ce ne sont pas les seuls termes à apparaître, ni les derniers. Ils sont les plus pertinents en termes de fonctionnalités et de capacités « dans le réseau » étant absorbés par DevOps. Certains d'entre eux nécessiteront l'attention de NetOps lorsqu'ils évolueront vers des environnements de production (comme Multi-Cluster Ingress) et d'autres non. L'équilibrage de charge prenant en compte la latence dans les environnements de conteneurs restera probablement du ressort de DevOps, même s'il est bon d'avoir une compréhension lors des discussions sur l'amélioration des performances ou de la disponibilité.

DevOps comporte une composante culturelle qui est souvent négligée ou complètement ignorée. Alors que le mouvement continue de laisser son empreinte sur NetOps et que les opérations de réseau traditionnelles adoptent lentement mais sûrement ses principes pour parvenir à un réseau agile, la communication devient essentielle. Cela signifie trouver un terrain d’entente. Comprendre le jargon de chacun peut être une bonne première étape vers la création d’une culture plus collaborative nécessaire pour garantir que les déploiements application sont aussi rapides, sécurisés et fiables que leur livraison.