Le réseau multicloud est-il vraiment magique ?
Dans le domaine en pleine évolution du cloud computing, la mise en réseau multicloud connaît un regain d’intérêt. Les récentes acquisitions réalisées par des fournisseurs qui ne disposaient pas auparavant d’une solution multicloud complète témoignent de la demande croissante des clients pour une solution simplifiée leur permettant de mieux appréhender les complexités du multicloud.
Cependant, dans ce contexte de regain d’intérêt, il apparaît de plus en plus clairement que les initiatives de nombreux acteurs du marché manquent quelque peu de vision à long terme et passent à côté de la véritable occasion de réduire la complexité à laquelle les clients sont confrontés.
Le réseau est fondamental, mais limité
À mesure que le cloud computing évolue, les réseaux multicloud s’imposent désormais comme une préoccupation technologique majeure pour les entreprises. La multiplication des capacités de calcul au-delà des centres de données traditionnels, jusque dans les installations périphériques distantes et les succursales physiques, impose un nouveau paradigme entre les environnements physiques et cloud. Avec l’essor de la conteneurisation, des microservices et des API, les applications sont devenues de plus en plus décentralisées et dynamiques, ce qui pose de nouveaux défis aux architectures réseau conventionnelles. Elles peuvent désormais être déployées sur des sites très dispersés, sans être limitées par la nécessité de disposer d’immenses fermes de serveurs.
La grande majorité des solutions de réseau multicloud disponibles aujourd’hui se concentrent principalement sur la couche de transport réseau. Le réseau tel que nous le connaissons aujourd’hui n’a pas connaissance des applications — ce n’est pas pour cela qu’il a été conçu. En outre, le réseau a principalement été conçu pour assurer une connectivité de site à site (nord-sud) et n’est pas équipé pour prendre en charge l’essor de la connectivité est-ouest entre services applicatifs, qui s’étend au-delà des clusters d’un même cloud ou site physique. C’est pourquoi des problèmes surviennent lorsque des entreprises réalisent d’importantes fusions ou acquisitions : des adresses IP distinctes, stockées dans les tables de routage réseau, doivent alors partager la même infrastructure et se heurtent inévitablement à des problèmes de chevauchement d’adresses IP, ce qui accroît la complexité opérationnelle.
Les réseaux traditionnels sont souvent perçus comme de simples « tuyaux » passifs et engendrent une charge opérationnelle ainsi que des inefficacités considérables qui entravent les équipes de développement au sein d’organisations très agiles. Beaucoup tentent de résoudre ces problèmes en intervenant d’abord sur le réseau, avant de constater les limites de cette approche.
Le dilemme de Kubernetes
Kubernetes s’est imposé comme un outil essentiel pour orchestrer ces écosystèmes distribués de conteneurs, offrant une agilité et une évolutivité à très grande échelle. Kubernetes, une plateforme open source d’orchestration de conteneurs initialement développée par Google, a rapidement été adoptée comme la norme de facto pour le déploiement et la gestion d’applications conteneurisées.
Kubernetes fournit une plateforme permettant d’automatiser le déploiement, la mise à l’échelle et la gestion des applications conteneurisées. En faisant abstraction de l’infrastructure sous-jacente, Kubernetes permet aux développeurs de se concentrer sur la création et le déploiement d’applications sans être freinés par la complexité de la gestion des ressources d’infrastructure. Cependant, Kubernetes présente lui-même un certain degré de complexité, du moins dans sa version open source. D’où la prédominance des distributions commerciales qui visent à en simplifier certains aspects.
Mais cela nous ramène à notre point de départ. Prenons par exemple l’une des distributions commerciales les plus répandues, Red Hat OpenShift. OpenShift est largement déployé dans les environnements d’entreprise, principalement dans les centres de données sur site. Ces mêmes entreprises déploient également des clusters de services dans le cloud, par exemple sur AWS, et utilisent très probablement Amazon Elastic Kubernetes Service (EKS). Elles souhaiteraient par ailleurs intégrer des services à Red Hat OpenShift on AWS (ROSA). Des environnements d’outils distincts qui ne sont pas conçus pour être intégrés : le problème du multicloud refait une fois de plus surface.
La faille de sécurité des réseaux cloud
Toutes les solutions de mise en réseau multicloud actuellement disponibles sur le marché offrent un certain niveau de sécurité intrinsèque, allant de la segmentation avancée aux fonctionnalités natives de pare-feu réseau et d’insertion de services. Mais, là encore, elles négligent le rôle moteur des applications. Ces solutions ne prennent pas en compte les menaces malveillantes qui exploitent des attaques visant la logique métier pour compromettre les services applicatifs distribués et les points de terminaison d’API répartis sur plusieurs sites cloud et en périphérie. Le réseau peut être sécurisé tout en laissant les applications qu’il dessert vulnérables aux attaques. Les entreprises sont contraintes de déployer plusieurs solutions de sécurité ponctuelles, tandis que leurs équipes de sécurité doivent mettre en place une gouvernance considérable afin de garantir la protection de l’ensemble de leurs catalogues d’applications hybrides distribuées et multicloud.
Plaidoyer en faveur d’un réseau multicloud sécurisé
Extrait vidéo : Définir la mise en réseau multicloud sécurisée avec Kyndryl et F5
Les entreprises visionnaires relèvent le défi et redessinent le paysage. Prenons l’exemple de McGraw Hill qui, face à la nécessité urgente de migrer des applications critiques vers le cloud, a donné la priorité aux besoins des applications et aux exigences de sécurité, en choisissant F5 Distributed Cloud Services pour répondre à ses exigences strictes. Grâce à F5, l’entreprise peut étendre en toute transparence son réseau sur site à n’importe quel environnement cloud, tout en garantissant une sécurité cohérente au niveau des applications dans tous les clouds.
De même, la Direction de l’agriculture et de l’économie rurale (ARE) du gouvernement écossais a reconnu la nécessité d’adopter un nouveau paradigme pour répondre aux enjeux des architectures applicatives modernes. Grâce à Distributed Cloud Services, l’ARE a transféré sans difficulté des charges de travail entre OpenShift et EKS, tirant ainsi parti de la flexibilité et de l’agilité des environnements multicloud. Comme l’explique Neil Smith, responsable de l’infrastructure : « Les environnements multicloud sont là pour durer. Avec F5, nous pouvons nous adapter et tirer parti d’un environnement Kubernetes conteneurisé, assorti d’une gamme complète de services et de solutions pour accompagner cette transition. »
Ces réussites illustrent l’évolution vers une approche des réseaux multicloud centrée sur les applications et axée sur la sécurité. En donnant la priorité aux besoins des applications et aux exigences de sécurité, tout en tirant parti de l’infrastructure réseau sous-jacente existante, les entreprises peuvent appréhender la complexité des environnements multicloud avec confiance et efficacité. Ce sont les réseaux multicloud sécurisés, et non la « magie », qui aideront les organisations reposant sur des architectures applicatives modernes à exploiter leur potentiel pour stimuler l’innovation et réussir à l’ère du numérique.
À propos de l’auteur
Articles 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.