Les stratégies DevOps engagées par les entreprises présentent de multiples challenges techniques, notamment en termes de réseau. Piocher des services Cloud chez de multiples fournisseurs à l’échelle mondiale entraîne immanquablement une complexification des architectures réseaux. L’Infra as Code apporte de solides éléments de réponse.

Il y a quelques années, dimensionner un réseau ne posait guère de problèmes aux ingénieurs. Chaque application hébergée dans le datacenter de l’entreprise nécessitait une bande passante plus ou moins fixe et il suffisait de dimensionner correctement chaque lien réseau pour que le WAN puisse répondre aux contraintes de qualité de service souhaitées. Si les performances étaient jugées insuffisantes, il suffisait d’allouer plus de bande passante à l’application pour retrouver de la marge.

Le mouvement vers DevOps bouscule les réseaux « classiques »

Avec la vague du DevOps et des applications « Cloud natives », une telle approche ne tient plus. Les serveurs ne sont plus directement accessibles aux ingénieurs réseaux et l’architecture même des applications rend cette approche obsolète. Les applications « Cloud natives » sollicitent des services managés hébergés proposés par le CSP, peuvent accéder à des données éventuellement stockées chez un second fournisseur Cloud. Les ingénieurs réseaux doivent passer par les API des hyperscalers pour provisionner des services réseaux et des firewalls et monitorer à la fois la performance des applications et des réseaux. De même, il n’est plus question d’attribuer une bande passante fixe à chaque application.

L’un des atouts majeurs du Cloud, c’est d’offrir une scalabilité potentiellement infinie. La puissance de traitement et la bande passante affectée à une application doit pouvoir évoluer dans le temps en fonction de la charge réelle générée par les utilisateurs. Mieux, la tendance est de placer l’intelligence réseau au niveau de l’application. Celle-ci instancie elle-même la bande passante nécessaire à son bon fonctionnement.

L’approche « Infrastructure as Code » fait aujourd’hui totalement partie de l’architecture de ces applications « Cloud natives ». C’est la raison pour laquelle il faut opter pour un partenaire réseau qui soit lui-même pilotable « as Code » et indépendant des fournisseurs Cloud afin de prendre à sa charge tout ce pilotage de l’aspect réseaux de ces nouvelles architectures logicielles. Le réseau est désormais considéré comme un service qui fait pleinement partie de l’application. L’application peut instancier des liens réseau, augmenter la bande passante qui lui est dédiée ou la réduire en fonction de ses propres besoins.

Cette approche « Infrastructure as Code » est désormais intimement liée à une démarche DevOps. Il faut pouvoir piloter les liens réseau via des API à l’échelle mondiale via des réseaux de type SDN (Software Defined Networks) et pas seulement dans le datacenter du fournisseur Cloud.

Une couche réseau agnostique vis-à-vis des CSP

Déployer une telle approche automatisée présente un certain nombre d’enjeux.

Le premier défi à relever est celui de l’hétérogénéité des technologies des hyperscalers. Si les offres des trois grands acteurs du Cloud mondial sont en train de converger, chacun propose son propre jeu d’API de pilotage, un vocabulaire qui lui est propre. Or toutes les entreprises s’orientent aujourd’hui vers des stratégies multicloud afin de tirer profit des technologies les plus avancées du marché, mais aussi limiter leur dépendance auprès de ces acteurs.

Pour les équipes DevOps, cette hétérogénéité implique de devoir maîtriser des environnements techniques différents, ce qui est une source de surcoûts liés à la formation et de délais pour la montée en compétence des équipes sur ces nouveaux environnements. S’appuyer sur une solution « Infra as Code » agnostique vis-à-vis des spécificités techniques de ces services va gommer cette hétérogénéité. Cela va permettre d’interconnecter tant les offres Cloud des hyperscalers que celles de CSP nationaux ou même des acteurs de niche positionnés sur des secteurs d’activités précis, comme le monde de la distribution, par exemple. Recourir à un tiers « Infrastructure as Code » est aussi un moyen de résoudre le problème de « Lock-In » inhérent aux offres Cloud puisque le pilotage du réseau sera réalisé avec les mêmes outils, les mêmes API quel que soit le fournisseur Cloud.

De même, s’appuyer sur une infrastructure réseau indépendante de ces acteurs est aussi un moyen de traiter des problématiques liées à la sécurité des flux de données à large échelle. Récemment, le conflit russo-ukrainien a poussé de nombreuses grandes entreprises à rediriger leurs flux réseaux de l’Europe à destination de l’Asie ou de la zone Pacifique afin de contourner la Russie. Si on s’appuie uniquement sur les liens SDN des opérateurs, cela demande un gros travail sur le routage des données sur l’ensemble des points d’accès réseau que l’entreprise peut avoir dans le monde. Là encore, s’appuyer sur un tiers agnostique des CSP et des opérateurs permet aux équipes DevOps de piloter l’ensemble de ces flux réseaux depuis un point unique.

Une réponse à la hausse de la complexité du Cloud

Un autre effet de bord d’une approche multicloud est de devoir interconnecter des datacenters de fournisseurs Cloud différents à l’échelle du globe. Si, pour d’évidentes raisons de confidentialité des données et de conformité, l’entreprise ne souhaite pas que ses données ne transitent par l’Internet public, il lui faut installer des équipements dans les datacenters des fournisseurs SDCI (Software-Defined Cloud Interconnect) locaux, provisionner des liens réseaux spécifiques et enfin paramétrer ce WAN. Cette approche reste possible, mais elle est à la fois coûteuse et peu flexible car il faut intervenir sur les équipements et les liens à chaque nouvelle demande métier.

S’appuyer sur un tiers permet de s’affranchir de ces contraintes bien réelles. Il suffit de se connecter à lui et de mettre en œuvre ses points de présence dans le monde et mettre en œuvre tous les nœuds d’interconnexion et tous les opérateurs de liens internationaux. L’entreprise dispose alors d’une plateforme d’automatisation qui est totalement unifiée pour se connecter via n’importe quel opérateur ou n’importe quel SDCI à l’échelle mondiale. La solution se comporte comme un jeu de construction universel où l’entreprise va assembler les ressources réseaux dont elle a besoin. Une couche d’orchestration intelligente permet de venir déployer le service avec n’importe quel réseau d’opérateurs et l’entreprise n’a qu’un seul contrat à gérer pour l’ensemble de cette problématique réseau.

Si beaucoup de DSI ont initié leur stratégie DevOps avec un fournisseur privilégié, le sens de l’histoire va clairement vers le multicloud. Chaque équipe de développement doit solliciter de multiples services auprès de plusieurs fournisseurs Cloud pour créer les applications « Cloud natives » les plus performantes. C’est la stratégie actuellement la plus populaire pour mener une transformation digitale réussie, mais la contrepartie de cette diversité, c’est l’élévation du niveau de complexité que cela fait peser sur les réseaux. L’infrastructure as code s’est maintenant clairement imposée comme un moyen de faire face à cette problématique et aider les métiers à mener leur transformation digitale sans entraves.
_____________________________

Par Amine Gharbaoui, C.O.O et E.V.P. Engineering chez InterCloud

 

À lire également :

Infrastructure as Code, IaaS, hyperconvergence : l’architecture idéale existe-t-elle ?

Infrastructure « as Code » (IaC) : nécessité, besoin ou faux problème ?

C’est officiel, IBM va racheter HashiCorp pour 6,4 milliards de dollars

Sécuriser l’Infrastructure-as-Code du on-prem jusqu’au cloud