Ou s’agit-il plutôt de « larmes » de frustration ? ¯\_(ツ)_/¯ Peut-être un peu des deux.
Il existe une relation entre les architectures réseau et applicatives. En général, nous aimons évoquer la manière dont les changements et les évolutions des architectures applicatives influent sur le réseau, tant sur le plan des solutions que de son architecture. Mais l’inverse est également vrai : l’architecture et le comportement du réseau peuvent avoir un impact considérable sur les applications et leur architecture.
Ainsi, si nous assistons à la décomposition des applications monolithiques en une multitude de microservices aujourd’hui plutôt qu’à l’époque de la SOA, c’est notamment grâce au réseau. Ou, plus précisément, grâce à sa vitesse. À l’époque de la SOA, la nature des réseaux (et les lois de la physique) imposait des contraintes qui rendaient impossible la composition d’une réponse unique à partir de plus de trois ou quatre services. Enfin, pas impossible, mais peu souhaitable en raison de la latence engendrée par chaque appel.
Aujourd’hui, nous disposons de réseaux plus rapides et offrant davantage de bande passante, ainsi que d’une puissance de calcul dix fois supérieure, ce qui rend cette décomposition possible. La nature des conteneurs, si souvent associés aux microservices comme le café aux donuts, facilite encore les choses. Comme « le réseau » entre deux services qui doivent communiquer est souvent une construction virtuelle (les paquets ne quittent jamais réellement le serveur hôte et ne subissent donc pas la latence liée à leur « mise sur le réseau »), le nombre de services pouvant être sollicités pour répondre à une même requête est bien plus élevé que ce que nous pouvions raisonnablement atteindre à l’époque de la SOA.
Cela ne signifie toutefois pas que nous devions négliger le nombre de connexions et de sauts à parcourir pour répondre à une requête, ni l’incidence de l’architecture sur les performances des applications. Car même si la puissance de calcul est plus élevée et les réseaux disposent d’une plus grande bande passante, la surcharge opérationnelle reste une contrainte à laquelle nous devons faire face et qui continue de nuire aux performances. L’un des moyens les plus simples de réduire cette surcharge opérationnelle (et d’améliorer les performances) consiste à diminuer la complexité en supprimant les couches (inutiles) d’une architecture.
Réduire la complexité des environnements de conteneurs
La plupart des déploiements de conteneurs utilisent un type d’équilibreur de charge au sein du cluster afin de gérer la mise à l’échelle des microservices et des applications dans l’environnement conteneurisé. En effet, ils sont souvent chargés d’assurer le routage L7 des API (c’est-à-dire le contrôle du trafic entrant), tandis que les mécanismes natifs d’équilibrage de charge reposent sur iptables, qui ne prend évidemment pas en charge HTTP, le langage du routage L7. Le cluster de conteneurs comporte donc de nombreux équilibreurs de charge L7.
À présent, la plupart des déploiements auront également besoin d’un équilibrage de charge à l’extérieur du cluster afin d’acheminer le trafic externe vers le bon équilibreur de charge à l’intérieur du cluster. Pour ce faire, ils utilisent un équilibrage de charge classique afin de distribuer les requêtes vers le bon équilibreur de charge interne.
Nous appellerons le répartiteur de charge externe BIG-IP et celui situé à l’intérieur du cluster le répartiteur de charge interne. Parce que c’est mon blog, voilà pourquoi.
Le problème, c’est que le nombre d’instances de l’équilibreur de charge interne fluctue (parfois considérablement). À chaque changement, le BIG-IP doit en être informé. Traditionnellement, cette opération était effectuée manuellement et obligeait le responsable du BIG-IP à modifier lui-même le pool. C’est frustrant pour les équipes de développement et DevOps, et fastidieux pour les équipes NetOps. Autrement dit, personne ne veut procéder ainsi.
C’est pourquoi il existe des solutions telles que F5 Container Connector . F5 Container Connector est un service natif pour les conteneurs qui s’intègre à l’orchestrateur de conteneurs et surveille l’environnement. Lorsqu’un changement affecte un équilibreur de charge interne, il déclenche un processus de mise à jour de BIG-IP. Ainsi, au gré des fluctuations de la demande, BIG-IP est automatiquement tenu à jour et peut distribuer correctement les requêtes à un équilibreur de charge interne actif et opérationnel. Aucune modification manuelle n’est nécessaire.
Cette architecture de mise à l’échelle à deux niveaux offre l’avantage de disposer d’un point d’entrée pratique (le BIG-IP) où la connexion SSL/TLS peut être terminée, ce qui permet d’améliorer les performances de manière mesurable. Pas mal.
Mais pourquoi s’arrêter là ? BIG-IP est capable d’assurer le routage L7. Si vous utilisez les services de F5 Container Connector, vous pouvez encore améliorer les performances (et réduire la charge opérationnelle) en supprimant complètement l’équilibreur de charge interne . Vraiment. BIG-IP peut faire office de contrôleur d’entrée pour Kubernetes et Red Hat OpenShift.
En confiant la gestion du trafic entrant à BIG-IP, vous éliminez tout un niveau de mise à l’échelle (le répartiteur de charge interne), ce qui améliore immédiatement les performances. Comme le répartiteur de charge externe est un F5 BIG-IP, vous pouvez également déployer des services applicatifs axés sur la sécurité, tels qu’un WAF avancé avec protection contre les bots, au point de contact plutôt qu’au sein du cluster de conteneurs (voire ne pas en déployer du tout).
Le choc des clans Ops
À mesure que les conteneurs seront déployés plus fréquemment en production (et ils le seront), une collaboration accrue entre les équipes DevOps et NetOps deviendra nécessaire pour mettre en œuvre ce type d’améliorations et garantir l’évolutivité, la rapidité et la sécurité des applications. Après tout, il ne s’agit pas simplement d’appuyer sur des boutons et d’utiliser des pipelines en libre-service. L’architecture est un élément essentiel qui devra être conçu avec la contribution conjointe des équipes DevOps et NetOps, au risque sinon de passer à côté d’occasions d’améliorer notamment les performances des applications.
Parce que les performances applicatives sont un sport d’équipe. Elles dépendent du code (AppDev), de la plateforme sur laquelle celui-ci est déployé (DevOps), de l’architecture réseau et des services applicatifs utilisés pour sécuriser l’application et assurer sa montée en charge (NetOps). Optimiser l’architecture en supprimant des couches lorsque cela est possible est judicieux, tant sur le plan opérationnel que commercial. Mais cela nécessite la participation de tous les membres de l’équipe.
Alors, commandez des pizzas et des bières, réunissez les équipes DevOps et NetOps et lancez la discussion. Voyez si vous pouvez, vous aussi, améliorer les performances des applications en supprimant les couches superflues de votre environnement de conteneurs.
À propos de l’auteur
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 VittieArticles de blog associés
F5 NGINXaaS pour Google Cloud : des applications résilientes et évolutives
Découvrez comment NGINXaaS s’intègre à Google Cloud pour renforcer les performances et la sécurité, et préparer vos applications critiques à un avenir propulsé par l’IA.
L’intégration de F5 Web Application Firewall (WAF) à AWS est disponible dès aujourd’hui
En faisant appel à un partenaire de déploiement AWS WAF tel que F5, vous pouvez renforcer la sécurité de vos applications web grâce à des règles personnalisées qui bloquent les schémas d’attaque courants, comme les injections SQL ou les attaques par scripts intersites (XSS).
Appliquer le principe de Peter Parker à l’inspection TLS
« Un grand pouvoir implique de grandes responsabilités. » Si l’on en trouve des échos chez Voltaire et Churchill, cette citation est surtout connue grâce aux bandes dessinées Spider-Man, où elle est attribuée à l’oncle Ben. Bien entendu, si cette phrase est si répandue dans la culture populaire, c’est notamment parce qu’elle peut s’appliquer à une multitude de situations et de sujets, y compris à l’inspection TLS.
Le NetOps a besoin de défenseurs, pas d’adversaires
Il est important de reconnaître que les équipes NetOps ne sont pas toujours celles qui font obstacle au déploiement de la dernière nouveauté, application ou service. Les freins à la rapidité sont souvent dus au fait que les organisations n’adoptent pas tous les principes du DevOps lorsqu’elles cherchent à transformer leurs opérations informatiques.
Mise à jour des services applicatifs : sécurité, rapidité et visiteurs suspects
Il est de nouveau temps de nous pencher sur les services applicatifs que les entreprises utilisent réellement pour rendre leurs applications plus rapides et plus sûres. On constate notamment une hausse du recours aux services de protection contre les bots, ainsi que la progression lente mais régulière de HTTP/2. Bien qu’il ne s’agisse pas d’une application…
Les templates prennent le contrôle du cloud
Les modèles s’imposent dans le cloud. Lisez le blog de F5 pour découvrir comment l’infrastructure en tant que code et les API déclaratives automatisent la mise à disposition des applications.