Nous avons vu les bénéfices que le Système d’Information peut retirer d’un Réseau de type « Software-Defined Networking » via cet article. Cela lui garantit l’agilité nécessaire afin de répondre à la réactivité attendue par les besoins Métier de l’Entreprise.
Nous avons vu les bénéfices du « SDN augmenté » via l’abstraction entre le couple collaborateur / application et l’infrastructure de transport via cet autre article. Cette abstraction permet d’identifier ce couple et de lui assurer une Qualité d’Expérience Applicative, quel que soit le Réseau de transport WAN, LAN ou Data Center. L’Entreprise a la garantie que tout collaborateur, ou qu’il se trouve, aura la même efficacité opérationnelle.
Nous savons également que plus de la moitié du patrimoine applicatif de l’Entreprise a migré vers un Cloud Public. Que ce soit à l’identique en mode IaaS (type Lift-and-Shift ou Rehost), ou en mode SaaS.
Nous assistons donc à une imbrication totale entre :
- La localisation du collaborateur :
- Site Central
- Bureau distant
- « home-office »
- Le lieu d’exécution de l’application :
- On-premise dans le Data Center de l’Entreprise
- Dans un Cloud Public en mode IaaS ou Saas
Il s’agit maintenant, à la suite de nos précédents articles, de valider que l’infrastructure de transport va assurer la même transparence pour le collaborateur, que l’application réside en interne ou dans un Cloud Public, quel que soit son mode de « hosting », IaaS ou SaaS.
I ) Le réseau basé sur l’intention en LAN, DC, WAN et Cloud Public
Je veux disposer des garanties suivantes afin d’assurer la Qualité d’Expérience Applicative pour mes collaborateurs :
- L’agilité
- L’indépendance de la localisation, soit du support multi-clouds
- L’évolutivité.
L’icône ci dessus représente le composant Réseau, le « muscle » dont je parlais dans un précédent article.
Le composant Réseau de périphérie est à même d’être mis directement dans l’environnement du fournisseur de Cloud Public.
Un élément de terminaison sera vu et traité de la même façon qu’il soit localisé sur :
- Mon datacenter
- Mon campus
- Mes sites distants
- Mes Clouds Publics.
Les bénéfices pour l’Entreprise en seront les suivants :
- Automatisation de la connectivité Cloud
- Macro et micro-segmentation garanties de bout en bout
- Règles propres à chaque application
- Evolutivité assurée de l’application.
Cela est rendu possible à la suite des différents accords technologiques conclus ces derniers mois entre l’équipementier Cisco et les principaux fournisseurs de Cloud Public (AWS, Azure et GCP).
Ces accords permettent à Cisco de porter son composant Réseau directement dans ces Clouds Publics. Ce composant Réseau sera géré comme tout autre composant par le Contrôleur du Réseau SDN WAN. Sachant qu’un point déterminant est la capacité du Système d’Information à projeter un composant du Réseau de l’Entreprise dans le Cloud Public.
L’autre point déterminant est la capacité à récupérer et analyser toutes les métriques qui permettront d’optimiser le dialogue Collaborateur / application. L’élément central ici s’appelle Cloud onRamp (dénommé CoR). Le Cloud onRamp est efficace aussi bien pour du IaaS que pour des applications en mode SaaS. Le IaaS répondra à un besoin d’extension de l’Infrastructure Privée vers un Cloud Public. Sur la partie IaaS, il fonctionnera via des sondes qui permettront de qualifier les meilleurs chemins d’accès à l’environnement du fournisseur de Cloud Public.
II ) L’intégration native entre mon Réseau d’Entreprise et le Réseau Azure
Pour matérialiser l’intégration Réseau, prenons le cas d’Azure de Microsoft :
Deux éléments majeurs apparaissent :
- L’appliance virtuelle SD-WAN de Cisco est directement portée dans le virtual WAN d’Azure
- Intégration complète des infrastructures Réseau WAN et vNET d’Azure
- Toutes les métriques observées sont échangées entre Azure et vManage
- Les dispositions seront prises afin d’optimiser les échanges.
Nous avons la même intégration entre les VPC d’AWS et vManage, le contrôleur SD-WAN. Ceci garantit la cohésion entre l’accès WAN et les règles déployées en interne vers les grands Cloud Publics. Si l’on dispose de diverses applications déployées sur un Azure ou un AWS, ce que nous venons de voir garantit un accès optimisé à ces applications.
Résumons-donc les trois étapes de la connectivité à un Cloud Public pour des besoins IaaS dans l’ordre de criticité :
- Optimisation de la connectivité
- Optimisation du Réseau
- Optimisation de l’expérience applicative.
Les apports d’ACI avaient été présentés dans un article précédent. Ils sont présentés dans le carré de droite. Ces bénéfices sont primordiaux. Ils se résument ainsi :
Avec ACI, j’étends mon Réseau Privé dans un Cloud Public tout en garantissant à mes applications le même niveau d’isolation car je transporte ma micro-segmentation au sein d’Azure / AWS.
III ) L’optimisation des accès Réseau vers les applications en mode SaaS
D’accord pour mon application migrée vers du IaaS, mais pour une application en mode SaaS ?
L’approche semble relativement différente mais les solutions sont très proches. Un même réseau SD-WAN optimisé pour des besoins d’accès WAN vers du IaaS le sera tout autant pour des accès vers des applications en mode SaaS.
Là-aussi, il convient d’obtenir des informations sur le meilleur chemin permettant d’accéder vers telle ou telle application SaaS.
L’infrastructure Réseau va effectuer des mesures de qualité entre le Collaborateur et son application SaaS. Pour cela, il faut disposer de sondes au niveau de l’application SaaS. Nous avons vu que l’équipementier Cisco a signé divers accords avec de grands fournisseurs de Clouds Publics. Cisco a également signé avec ces mêmes fournisseurs sur leurs applications SaaS, ainsi qu’avec d’autres acteurs majeurs du SaaS. Pour une application SaaS donnée, le Réseau effectuera les mesures de qualité sur des paramètres précis :
- Latence
- Gigue
- Bande passante
- Taux d’erreur (drop) et de retransmission…
Le contrôleur du Réseau SDN proposera ensuite le meilleur chemin entre un collaborateur et son application.
Dans le schéma présenté précédemment, nous avions des options via le MPLS de l’Entreprise ou via du Direct Internet Access. Le collaborateur sera orienté vers le chemin le plus efficace à partir du moment où il offre toutes les garanties de Sécurité d’accès.
IV ) Les cas particuliers des multiples applications de la suite Office365
Oui mais j’utilise diverses applications de la Suite Office365 de Microsoft
Là encore, cela est basé sur des accords signés entre l’équipementier Cisco et le fournisseur d’applications SaaS Microsoft pour la suite O365. Microsoft va classer ses applications O365 selon 3 catégories :
- Optimize
- Allow
- Default.
Les différents composants de mon Réseau SD-WAN récupéreront des informations de télémétrie via leurs sondes. Dans le même temps, Office365 sur Azure enverra ses propres informations de télémétrie propres à chaque application O365 aux divers composants Réseau de mon environnement SD-WAN.
Ainsi, le contrôleur SD-WAN sélectionnera le meilleur chemin d’accès à l’application O365 en corrélant les informations issues de ses propres sondes avec celles envoyées par Microsoft Azure O365. L’objectif est alors atteint. La Qualité d’Expérience Applicative est garantie indépendamment de la localisation du collaborateur et de son application
Notre prochain article présentera comment superviser l’environnement de votre Système d’Information via une suite d’outils Open Source.
