La mise en réseau à l'ère des conteneurs
Au cours des dernières années, la virtualisation et désormais la conteneurisation ont augmenté la densité des applications sur n’importe quel matériel. Nous sommes donc devenus obsédés par le défi de gérer le trafic est-ouest plutôt que le trafic nord-sud.
Pour ceux qui sont encore un peu légers sur les modèles de trafic de leurs centres de données, récapitulons : Le Nord-Sud correspond à une connexion utilisateur-application ou client-serveur ou à une connexion entrante-sortante du centre de données. Est-ouest signifie serveur à serveur, application à application, service à service ou simplement au sein du centre de données.
Les schémas de circulation nord-sud sont impactés par l'augmentation du nombre d'utilisateurs, d'applications et d'objets. Plus les connexions utilisateur-application sont nécessaires, plus vous verrez de trafic nord-sud. Le trafic est-ouest est affecté par les architectures d’application et la technologie de l’infrastructure. Lorsque vous combinez des technologies telles que la virtualisation et les conteneurs avec des architectures émergentes telles que les microservices, vous vous retrouvez avec une augmentation exponentielle du nombre d’« applications » ou de « services » qui doivent communiquer entre eux dans le centre de données.
Fondamentalement , plus une architecture d’application et son infrastructure deviennent distribuées, plus vous verrez de trafic est-ouest.
Cette augmentation est aggravée par la tendance à « dimensionner correctement » les applications. Plutôt que de baser la planification des capacités sur des projections de croissance, celle-ci est basée sur les besoins actuels, plus un peu plus. Grâce à des technologies de plus en plus matures, comme la mise à l'échelle automatique, nous sommes en mesure d'utiliser les ressources plus efficacement, laissant moins de ressources de calcul et de réseau inutilisées, consommant ainsi du budget sans produire de valeur proportionnelle . C’est d’ailleurs l’un des avantages du cloud privé : la possibilité de mieux tirer parti des ressources qui, autrement, resteraient inutiles, en fournissant un provisionnement et une gestion orientés services qui permettent une utilisation des ressources en temps réel.
Mais je m'égare. Le fait est que le trafic est-ouest augmente grâce aux architectures et aux technologies à un rythme qui dépasse probablement celui de l’augmentation nord-sud.
Aujourd’hui, chaque changement significatif dans les architectures d’application et les technologies au cours des vingt dernières années a entraîné une réaction équivalente dans « le réseau ». C’est parce que le réseau est responsable de la gestion du trafic, quelle que soit sa direction. Est-ouest, nord-sud, peu importe. Qu'il soit virtuel ou physique, un réseau est nécessaire pour garantir que le trafic arrive de là où il est à là où il doit aller.
La question qui se pose désormais, alors que nous constatons une augmentation encore plus importante du trafic est-ouest en raison de la décomposition des applications due aux microservices, est de savoir comment le réseau doit réagir. Plus précisément, comment les services du réseau doivent-ils réagir pour assurer les fonctions critiques (disponibilité, sécurité, optimisation) nécessaires pour fournir des applications aux utilisateurs ou, de plus en plus, à d’autres applications ?
IMPACT UN : PASSER À L'APPLICATION
La première réponse à cette question est clairement que les services affines aux applications doivent se rapprocher de l'application . Ils ne peuvent pas rester à la limite du modèle nord-sud et fournir des services aux applications qui les consomment principalement selon un modèle est-ouest. Il s’agit d’une utilisation inefficace des ressources du réseau et de l’impact des modèles de routage qui induit une latence dans la communication des applications. C'est ici que nous commençons à entendre des termes tels que « tromboning » et « hairpinning » de modèles de trafic qui décrivent un itinéraire à travers le réseau qui nécessite de quitter une machine, de traverser le réseau vers le nord, puis de revenir à la même machine. Cette latence se traduit par des coûts commerciaux réels en termes de productivité réduite (« soyez patients avec moi, mon « ordinateur » est lent aujourd’hui ») et d’abandon accru des paniers d’achat et des applications Web par les consommateurs. C'est ce que nous voulons éviter ; si le trafic va d'est en ouest, alors les services doivent se trouver dans ce chemin de données.
IMPACT DEUX : COMPATIBILITÉ OPÉRATIONNELLE
La deuxième réponse est que ces services comme l’équilibrage de charge et la sécurité des applications Web doivent pouvoir être déployés dans des formats compatibles sur le plan opérationnel. En d’autres termes, nous n’allons pas installer du matériel réseau devant chaque application (ou microservice) qui apparaît. Les plateformes sur lesquelles ces services sont fournis doivent donc être virtualisées ou conteneurisées afin d’être opérationnellement compatibles avec les architectures et technologies émergentes. Ils doivent également être programmatiques, en fournissant des API et des modèles qui permettent une approche orientée DevOps pour le provisionnement et la gestion. Les services, qu’ils soient applicatifs ou réseau, doivent être orchestrables. Le SDN, s’il peut s’intégrer aux outils et aux cadres qui dominent les environnements d’exploitation des infrastructures et des applications, peut également répondre à ce besoin.
IMPACT TROIS : L'ARCHITECTURE EST ESSENTIELLE
La troisième réponse est que l’architecture devient encore plus importante que jamais. Ce n’est pas parce que l’on peut déployer un service réseau sur le même hôte que son application que cela signifie nécessairement qu’il doit y être déployé. En fonction de ce dont il s'agit et de son interaction avec d'autres services (et instances de services), le placement devient un problème sérieux à prendre en compte. Un équilibrage de charge mal conçu, par exemple, peut entraîner des schémas de trafic terrifiants qui entraînent une latence inutile ; une latence qui se traduit directement en bénéfices – ou en pertes – pour l’entreprise . Toute défaillance (matérielle, logicielle, réseau, stockage) dans ce scénario sur l'hôte sur lequel les services sont déployés entraîne des temps d'arrêt (et des temps d'arrêt désagréables, en plus) car les services responsables de garantir la disponibilité des applications sont également en panne. Dans une architecture d’application hautement décomposée (microservices), cela pourrait être désastreux si les dépendances sur ces applications sont élevées.
Une réflexion approfondie (architecture) est nécessaire pour garantir que les meilleures pratiques en matière de performances et de disponibilité ne soient pas ignorées par l’attrait de la réponse la plus évidente (et la plus simple).
LA MISE EN RÉSEAU RESTE UN EXERCICE D'ARCHITECTURE
La mise en réseau est et continue d’être un effort architectural. Il ne s’agit pas seulement de facteurs de forme, c’est simplement un moyen d’obtenir les ressources réseau là où vous en avez besoin plus rapidement et plus efficacement. Il s’agit du placement de ces ressources et de la manière dont cela impacte tout ce qui se trouve en amont de la pile : les services réseau, les services d’application, les performances des applications et, en fin de compte, la réussite ou l’échec de l’entreprise.
À l’ère des conteneurs, de la virtualisation et du cloud, la mise en réseau est autant une question d’architecture que d’opérations.