Pourquoi la mise en réseau IP traditionnelle est mauvaise pour le cloud

Cela a été incroyable d’assister à la transition de l’entreprise vers le cloud. En quelques années à peine, la technique du cloud est devenue un outil incontournable dans la plupart des grandes entreprises. Cependant, d’après mon expérience, les clients et les partenaires n’ont en fait pas hésité à faire face aux difficultés du voyage vers le cloud, en particulier lorsqu’il s’agit de la mise en réseau dans le cloud.

L’une des plus grandes difficultés : la présomption que la mise en réseau IP conventionnelle de la tradition stack soutiendra leur transition vers le cloud. Avec le recul, les clients découvrent que ces méthodes héritées ne présentent que plus de complexité, qu’elles ne correspondent pas à la manière dont les fournisseurs de cloud créent des services ou y accèdent.

La technique générale est logique. Les entreprises prennent leurs outils de mise en réseau IP conventionnels, spécialement conçus pour le centre de données, et libèrent leurs variantes virtuelles sur le cloud. Cependant, le réseautage n’est que la moitié – ou plutôt un tiers – du combat. Les entreprises doivent également tenir compte de la sécurité, de l’efficacité des applications et des dépenses lors de leur transfert vers le cloud.

Voici les raisons (quelque peu techniques) pour lesquelles les méthodes de mise en réseau IP uniquement – avec des réseaux tordus de VPC, VNET, et les logiciels de pare-feu– ne fonctionneront pas pour la liaison vers et au sein du cloud, et pourquoi les entreprises ont besoin d’une technique fondamentalement nouvelle pour la mise en réseau du cloud.

L’observabilité des applications est limitée

Bien sûr, la couche réseau IP fournit une méthode pour relier votre centre d’information au cloud. Cependant, l’une des principales difficultés des réseaux hérités est qu’ils offrent une présence restreinte dans les applications du cloud, la bouée de sauvetage des entreprises d’aujourd’hui et peut-être le principal moteur de l’adoption du cloud.

À la couche 7, ou le dite couche application, les entreprises ont une vue holistique de ce qui se passe à ce niveau (applications et collections de services) ainsi que dans la pile ci-dessous, comme au niveau des ports TCP et UDP et des points de terminaison IP. En s’exécutant uniquement avec la pile standard (c’est-à-dire la couche IP), les équipes d’entreprise ont beaucoup plus de mal à voir ce qui se trouve au-dessus d’elles dans la pile. Ils n’ont qu’une vue sur le réseau et des zones aveugles pour tout le reste.

Pourquoi est-ce important ? D’une part, cela peut augmenter considérablement le temps de correction lorsque des problèmes d’efficacité surviennent. Sans aucun doute, les entreprises doivent comprendre comment leurs installations cloud fonctionnent par rapport à l’application et aux configurations de test A/B pour s’aligner sur les performances de l’application. Au niveau du réseau, néanmoins, les entreprises peuvent simplement appliquer des politiques générales d’efficacité et de sécurité pour toutes les applications. Que se passe-t-il lorsqu’une partie de votre service ou application est défaillante ? Sans exposition à l’ensemble de la pile d’infrastructure, il peut être très difficile de déterminer précisément où se situe le problème.

La performance est une réflexion après coup

D’une manière comparable , les entreprises doivent tenir compte des différentes exigences de latence, de performances et de sécurité pour différentes applications. Par exemple, même une seule application peut avoir besoin de 3 variantes distinctes – mise en scène, contrôle qualité et production – qui ont des objectifs d’efficacité et de latence différents. Vous n’aurez peut-être pas besoin d’améliorer les performances des applications en préparation, alors que vous le feriez absolument avec le travail de production.

Au niveau de la couche réseau IP, il n’est pas possible d’atteindre ces objectifs distingués. Au niveau de la couche d’application, il est possible d’utiliser des politiques cohérentes pour divers types d’applications, même sur un éventail de clouds, de fournisseurs de clouds ou de circonstances sur site. En utilisant des fonctionnalités cloud telles que la réécriture d’URL ou le filtrage FQDN avec la surveillance DNS, les entreprises peuvent atteindre ces objectifs sans toucher du tout aux adresses IP. Les équipes peuvent appliquer une limitation ou une limitation du débit en fonction des profils d’application pour tout type d’application (HTTP/HTTPS), ou diriger le trafic à l’aide de fonctions de style GSLB–aucun outil élégant requis.

La complexité opérationnelle augmente

Au-delà de cela, comme de nombreux clients et partenaires l’ont en fait partagé, la mise en réseau traditionnelle peut développer une complexité fonctionnelle considérable dans le cloud. Les entreprises sont tenues de conserver des entrées hub and spoke pour chaque VPC ou VNET nécessaire pour connecter leur centre d’information au cloud, ou pour connecter divers environnements cloud.

Ces maillages de connexion nécessitent une orchestration de chemin et de politique autrement inutiles , ce qui pose des défis supplémentaires. D’une part, les outils réseau comme ICMP ou traceroute ne peuvent fournir que des diagnostics au niveau IP, sans aucun moyen de traiter les problèmes au niveau de la couche application. Comme mentionné, les entreprises ont besoin d’une connaissance approfondie des applications pour optimiser le réseau ; Les vues au niveau du port ou au niveau du protocole seules ne sont pas adéquates. Plus précisément, les entreprises ont besoin d’une véritable surveillance des utilisateurs (RUM) combinée à une répartition précise de la connectivité utilisateur-application, consistant en tous les sauts intermédiaires susceptibles de poser problème.

D’un autre côté, avec les réseaux existants, la division du réseau est généralement détachée du raisonnement commercial. Les adresses IP du cloud changent souvent, ce qui suggère que la résolution des adresses IP n’est pas adjacente et crée une échelle de routage inutile. Cela ne développe pas seulement des adresses IP qui se chevauchent ; cela indique également que les équipes ont constamment besoin de mettre sur liste blanche et sur liste noire les variétés d’IP, bien que l’identité de l’utilisateur et les noms de point de terminaison d’application dans le cloud ne changent jamais.

Outils de plate-forme en tant que service (PaaS) et cloud-native les services ne sont pas routés par IP ; ils sont routés par nom de ressource et URL. Enfin, les tunnels IPsec requis pour la connexion régionale et intercloud ne peuvent pas évoluer, laissant les entreprises sujettes aux erreurs et aux zones aveugles de sécurité. Au lieu de cela, mTLS ou HTTPS est nécessaire pour l’interconnectivité du cloud et de la zone. Ces procédures de connexion sécurisées ne créent pas seulement des frais généraux plus fonctionnels, nécessitant des compétences en réseau, des ressources d’ingénierie et des coûts de maintenance pour chaque cloud, mais minimisent également la présence de flux réseau au sein et entre les clouds à presque aucun.

La sécurité peut devenir un cauchemar

Enfin, la gestion de la sécurité du cloud devient un défi de taille. Ce défi, essentiellement, découle de la nécessité de gérer de nombreuses politiques de sécurité réseau et logiciels de pare-feu virtuels dans diverses circonstances, régions et fournisseurs de services de cloud – une tâche qui finit par être presque difficile à mesure que les charges de travail natives du cloud évoluent vers le haut et vers le bas. Par conséquent, les groupes de réseau et de sécurité sont confrontés à un jeu implacable de complexité choquante.

Naturellement, le travail basé sur le cloud est axé sur l’application. En termes de sécurité, il n’est pas possible de sectoriser votre réseau en fonction des endpoints applicatifs. Il n’est pas non plus possible de vérifier en permanence les utilisateurs et les appareils ou d’obtenir des données de conscience contextuelle ou comportementale – toutes des parties cruciales des techniques d’accès réseau sans confiance (ZTNA) – avec les couches de mise en réseau traditionnelles.

Gestion des adresses IP, avec éventuellement dupliquer et se chevaucher des adresses IP dans les environnements cloud, développe des dangers pour la sécurité. En effet, essentiellement, la mise en réseau dans le cloud ne se produit pas avec les adresses IP ; il se produit plutôt avec l’identité, c’est-à-dire les espaces de noms et les points de terminaison de service. Le résultat pour les entreprises est que la sécurité native du cloud nécessite une approche essentiellement nouvelle qui se déroule au niveau de l’application.

La méthode à suivre pour la mise en réseau du cloud

Alors que les entreprises évoluent rapidement vers le cloud, ils découvrent que les méthodes de mise en réseau traditionnelles fournissent un moyen fiable de se connecter – au départ. Au fur et à mesure qu’elles adoptent et se développent, les entreprises comprennent qu’avec les réseaux hérités, la complexité augmente considérablement, mais aucun moyen fiable de gérer les performances, la sécurité et les dépenses des applications. Il est temps de rationaliser la mise en réseau du cloud et de déplacer la mise en réseau du cloud vers la couche d’application.

Ramesh Prabagaran est le PDG et co-fondateur de Prosimo, la société Application Experience Infrastructure, qui permet aux entreprises d’accepter le cloud à à grande échelle, tout en améliorant l’efficacité et la disponibilité des applications. La plate-forme Prosimo comprend les applications, fournit les principes de mise en réseau du cloud et l’observabilité, tout en utilisant le ML enraciné pour fournir des recommandations en temps réel pour l’expansion ou la contraction de l’infrastructure, les optimisations de performances, la résolution rapide des problèmes, les améliorations de la sécurité et le contrôle des coûts du cloud.

— Nouveau

Tech Forum offre un endroit pour vérifier et passer en revue les technologies d’entreprise émergentes avec une profondeur et une ampleur inégalées. La sélection est subjective, basée sur notre choix des technologies que nous jugeons importantes et qui intéressent le plus les lecteurs d’InfoWorld. InfoWorld n’accepte pas les supports marketing pour publication et se réserve le droit de modifier tout le contenu fourni. Envoyez toutes les questions à newtechforum@infoworld.com.