Le rôle des réseaux dans la performance applicative dans un environnement cloudifié
La cloudification a changé la manière dont on gère l’infrastructure et les applications : plus de 70% des applications d’entreprise sont maintenant des applications SaaS (source). La plupart des sociétés fait appel à plusieurs clouds et a migré des workloads vers des clouds publics. Quel est l’impact sur la livraison des applications aux utilisateurs ? Qu’est-ce que cela signifie pour le rôle des réseaux sur la performance des applications de bout-en-bout ?
Le réseau dans la livraison des applications, avant le cloud
Avant le mouvement vers le cloud, les réseaux privés étaient au coeur de la livraison des applications dans un contexte d’entreprise et l’internet servait de support aux applications exposées à l’extérieur. Les choses étaient simples.
Le cas des applications privées ou internes
Aux bons vieux jours, les utilisateurs accèdaient aux applications hébergées dans le datacenter depuis un site connecté au réseau privé via une connexion MPLS ou une connexion point à point de niveau 2.
Gérer la performance réseau était facile ; les choses étaient claires.
- Où l’utilisateur se situait sur le réseau,
- Dans quel datacenter l’application était hébergée (de façon monolithique le plus souvent)
- Le chemin réseau emprunté par le trafic
- Quel opérateur était responsable de la performance de ce circuit
Le cas des applications exposées sur Internet
Les applications exposées sur Internet sont plus difficiles à maîtriser dans la mesure où la connectivité dépend d’une série de réseaux d’opérateurs. Le titulaire de l’application n’a aucun moyen d’agir sur la majorité de ces opérateurs.
Ceci est compensé en déployant une architecture qui réduit structurellement la latence (et la distance) entre les utilisateurs et les applications :
- Hébergement dans plusieurs régions pour réduire la “distance” entre utilisateurs et workloads
- Utilisation de réseaux de livraison de contenu (CDN) pour être au plus près des utilisateurs
- Affiner (ou demander à votre fournisseur de le faire) la configuration BGP pour optimiser le chemin entre utilisateurs et applications.
Le réseau dans la livraison d’application et leur performance dans un monde cloudifié ou hybride
En se concentrant sur les applications d’entreprise, l’utilisation des technologies cloud a changé la nature des réseaux et leur impact sur la chaîne de livraison des applications.
Le réseau dans la chaîne de livraison des applications : chemin utilisateur vers applications
Le processus de cloudification a profondément changé l’infrastructure que traverse le trafic d’une application depuis un utilisateur. L’utilisateur ne traversera plus un réseau privé (local puis distant pour atteindre un datacenter contrôlé par la même organisation).
Il y aura une variété d’options :
SD-WAN vers les datacenters et les clouds
Un utilisateur situé dans un site distant peut être connecté aux applications par l’intermédiaire d’un équipement SD-WAN, qui route le trafic via un des services réseaux disponibles comme sous-couche :
- Connection MPLS vers un datacenter (et éventuellement une passerelle cloud ou internet pour atteindre des ressources SaaS ou cloud public)
- Un tunnel VPN sur une connexion internet ou publique vers un datacenter (et ensuite éventuellement vers une passerelle internet ou cloud pour joindre un SaaS ou un cloud public)
- Une passerelle internet locale (“Local internet breakout”) pour se connecter à une application SaaS
Ceci a deux conséquences :
- La latence observée au niveau de l’overlay (ou “sur-couche”) varie et est hautement dépendante de l’underlay (ou “sous-couche”) qui est utilisé pour véhiculer le trafic, des changements de chemin sur cet underlay et de la performance réseau de celui-ci (pour en savoir plus sur ce sujet, consultez cet article).
- Au delà de la performance au niveau de l’overlay du SD-WAN, les segments réseau additionnels du côté utilisateur (WiFi ou LAN) et du côté datacenter ou cloud (passerelle cloud sécurisée – CASB, connectivité cloud ou accès internet) auront également un impact sur la performance de l’application de bout-en-bout.
[/vc_column_text][/vc_column][/vc_row][vc_row][vc_column width= »1/1″][vc_single_image media= »4431″ media_lightbox= »yes » media_width_percent= »100″ uncode_shortcode_id= »240436″][/vc_column][/vc_row][vc_row][vc_column width= »1/1″][vc_column_text uncode_shortcode_id= »165922″]
L’internet public pour les accès SaaS et cloud
Bien que les accès SaaS et Cloud soient des ressources critiques pour la plupart des entreprises, la grande majorité d’entre elles s’appuient sur des connexions internet pour les atteindre :
- Soit en faisant transiter leur trafic sur l’internet public
- Soit en établissant des connexions de réseau privé virtuel (VPN) sur une connectivité internet
Cela signifie que le chemin pris pour atteindre le cloud ou la plateforme SaaS est sujet au changement de route au travers des réseaux de multiples opérateurs (à moins que vous ne possédiez votre propre AS et peeriez directement avec votre fournisseur SaaS ou Cloud).
Les changements de chemin ou les congestions en dehors de votre réseau affectent la performance applicative de bout-en-bout.
Les services cloud entre vos utilisateurs et vos clouds
Les passerelles cloud sécurisées (SWG pour Secured Web Gateways) et les CASBs (Cloud Access Security Brokers) représentent maintenant une couche de sécurité courante entre utilisateurs et applications SaaS ou Cloud.
Elles modifient le chemin réseau entre utilisateurs et applications. Elles sont sujettes à :
- Des redirections des utilisateurs vers des noeuds CASB ou SWG en fonction de leur géolocalisation
- Des changements de chemin BGP entre les utilisateurs et les nœuds CASB et entre la plateforme du CASB et les applications SaaS ou Cloud.
Il est maintenant indispensable d’évaluer la latence additionnelle introduite par ces “proxys cloud”. [/vc_column_text][/vc_column][/vc_row][vc_row][vc_column width= »1/1″][vc_single_image media= »4433″ media_lightbox= »yes » media_width_percent= »100″ uncode_shortcode_id= »182111″][/vc_column][/vc_row][vc_row][vc_column width= »1/1″][vc_column_text uncode_shortcode_id= »149708″]
L’impact de la distribution des applications sur la livraison aux utilisateurs
Dans une chaîne de livraison traditionnelle d’applications, les utilisateurs se connectent si ce n’est à un seul serveur frontal, du moins à une série de frontaux situés dans un même environnement. La cloudification a introduit plus de complexité avec les concepts suivants :
- “Cloud availability”
Les clouds rendent beaucoup plus facile la distribution de serveurs frontaux dans plusieurs régions (pour réduire la latence entre utilisateurs et frontaux). Néanmoins la couverture cloud est toujours inégale selon la région et il existe de nombreuses options pour rendre les frontaux de votre application beaucoup plus proches qu’auparavant en s’appuyant sur les zones de disponibilité dans plusieurs régions ou en faisant appel à des services spécialisés comme AWS Global Accelerator.
- CDN
Les réseaux de livraison de contenu sont largement utilisés pour distribuer des contenus statiques aux utilisateurs (images, css, scripts etc…). Dans leur prolongement les services dits “edge” devraient fournir un moyen encore plus abouti.
- Services de tiers
De nombreuses applications s’appuient sur des services prêts à l’emploi fournis par des tiers pour réduire la charge et le temps de développement de nouvelles applications. Ils emploient ces services dans le cadre de leur application, tant et si bien que les utilisateurs y feront inévitablement appel dans leur utilisation de l’application. [/vc_column_text][/vc_column][/vc_row][vc_row][vc_column width= »1/1″][vc_single_image media= »4436″ media_lightbox= »yes » media_width_percent= »100″ uncode_shortcode_id= »207067″][/vc_column][/vc_row][vc_row][vc_column width= »1/1″][vc_column_text uncode_shortcode_id= »148296″]La conclusion est que le nombre de connexions réseau et les opportunités de commettre des erreurs de géolocalisation et de redirection ou de souffir de mauvaises conditions réseau entre utilisateurs et frontaux sont démultipliés par ce nouveau contexte.
Les réseaux à l’intérieur de la plateforme applicative
Mis à part le segment utilisateur vers frontaux, la cloudification introduit enfin de portions de latence réseau où il n’y en avait pas ou peu dans les architectures traditionnelles.
Dans une architecture traditionnelle, dans la plupart des cas, les ressources applicatives sont concentrées dans un seul datacenter rendant la latence entre systèmes limitée à celle observée au sein d’un LAN (réseau local). Avec la cloudification, les systèmes peuvent être distribués au travers de plusieurs localisations, régions cloud ou fournisseurs cloud.
Datacenter vers cloud
C’est une situation classique pour une société effectuant une migration cloud de continuer d’héberger des services applicatifs dans ses data centers traditionnels et d’autres dans des clouds.
De façon amusante, alors que certaines entreprises s’appuient sur des VPNs sur une connectivité internet ou décident d’acheter une “connectivité directe” vers le cloud, peu d’entre elles mesurent la latence entre les localisations de leurs différents workloads applicatifs et évaluent ainsi l’impact sur l’expérience utilisateur… jusqu’à ce qu’elles rencontrent un problème en production (plaintes utilisateurs ou vitesse de transfert lors d’une migration, par exemple). [/vc_column_text][/vc_column][/vc_row][vc_row][vc_column width= »1/1″][vc_single_image media= »4438″ media_lightbox= »yes » media_width_percent= »100″ uncode_shortcode_id= »114443″][/vc_column][/vc_row][vc_row][vc_column width= »1/1″][vc_column_text uncode_shortcode_id= »188072″]
Cloud à cloud
La vaste majorité des entreprises opère des environnements multi clouds ; il y a de nombreuses raisons pour cela : les coûts, les décisions effectuées par différentes parties de leur organisation, des affinités applicatives pour migrer vers tel ou tel cloud (par exemple, migrer une application basée sur une technologie Microsoft comme Active Directory conduit souvent à le faire vers Azure et migrer les données d’une base de données Oracle conduit souvent à le faire dans un cloud d’Oracle pour limiter l’effort de migration).
L’utilisation de la couverture globale d’un seul fournisseur cloud peut tendre à accroître la latence réseau entre les services applicatifs. Voici pourquoi.
Alors que des entreprises utilisent plusieurs régions d’une infrastructure cloud pour limiter la distance entre utilisateurs et frontaux, la plupart d’entre elles trouve plus difficile de distribuer les services de back end comme les serveurs API, les bases de données ou autres.
Ceci introduit une latence significative entre services frontaux et back end, ce qui dans la majorité des cas est une nouvelle situation et peut avoir un impact important sur la réactivité des frontaux (qui doivent attendre la réponse des back ends qui peut être ralentie).
De surcroît, quand on considère que les services de back end peuvent être fournis en PaaS (opéré par le fournisseur cloud sans contrôle de votre organisation) ou en micro services, on comprend que la latence additionnelle est plus complexe à évaluer et anticiper, car elle peut varier de façon inopinée.
Finalement, au sein de grandes organisations, différents systèmes peuvent avoir été migrés dans différents environnements cloud, chez différents fournisseurs ou déployés de façon différente (SaaS, PaaS, IaaS). Ceci implique que la latence entre services applicatifs dépend principalement de l’infrastructure des fournisseurs cloud et de la manière dont ils sont interconnectés.
Ce dernier point est devenu une faille fréquente en matière de performance dans les environnements multi clouds.
En conclusion, la migration vers le cloud a renforcé l’impact des réseaux sur l’expérience des utilisateurs et le rend moins facilement gérable et anticipable.
