Il y a quelques jours, j’ai revu le film « Music and Lyrics ».
À un moment donné du film, Hugh Grant chante une chanson extrêmement ringarde intitulée « Don’t write me off yet » (Ne m’arrêtez pas tout de suite).
J’ai pensé que si MPLS pouvait participer au concours du « Chanteur masqué », il choisirait certainement « Don’t write me off yet » comme chanson thème.
Oui, je suis un nerd, je regarde des films ringards et l’exclusion de COVID m’a fait choisir des émissions horribles à regarder sur Hulu – je m’en excuse.
Assez parlé de cela.
Parlons de MPLS.
Je le connais depuis qu’il a été appelé Tag Switching.
Puis nous nous sommes perdus de vue pendant quelques années alors que je faisais d’autres choses, et lorsque je suis revenu à la technologie des réseaux, presque tout ce qui concernait la technologie des réseaux d’entreprise à grande distance tournait autour de MPLS.
Et pourquoi pas ?
Il a apporté aux backbones IP du monde entier de véritables besoins de classe entreprise, tels qu’une fiabilité à cinq neuf et un comportement QoS déterministe, permettant aux entreprises de faire réellement confiance au nouveau mode de transport basé sur IP (à ne pas confondre avec Internet) et rendant obsolète le monde des lignes louées (à moins que vous n’ayez les moyens d’acheter de la fibre noire de nos jours).
Mais ce que je veux dire, c’est que dans le monde du SD-WAN, tout le monde s’est amusé à tirer à boulets rouges sur MPLS.
En voici quelques-unes :
- « C’est super cher ! »
- « Il faut une éternité pour provisionner et être disponible !
- « Il est conçu pour simplement acheminer le trafic vers un site central, et cette topologie n’est absolument pas adaptée aux déploiements de technologies en nuage ! »
Bien que ces affirmations soient vraies, je comprends pourquoi de nombreux gestionnaires de réseaux font encore confiance à la technologie MPLS et, lorsqu’ils envisagent une stratégie de migration, veulent avancer prudemment sur un chemin sûr qui garantit le succès.
Admettons-le : peu d’entre nous aiment jouer et prendre des risques énormes lorsqu’il s’agit de décisions professionnelles clés, et les gestionnaires de réseau ont la charge de fournir une connectivité d’entreprise fiable et prévisible qui soutient leurs activités.
S’il est bon de livrer les nouveaux projets plus rapidement, personne ne veut que le réseau de l’entreprise tombe en panne ou se dégrade, car tout s’écroulerait.
Regardons les choses en face : le réseau doit être fiable, il doit fonctionner de manière prévisible et MPLS est un outil qui a fait ses preuves pour garantir cela.
Si j’étais gestionnaire de réseau aujourd’hui, j’adopterais moi aussi une approche graduelle, mesurée et sans risque lorsque j’envisagerais de migrer vers une solution autre que MPLS.
Ou, pour le dire autrement, puisque nous travaillons à domicile, nous sommes tous, dans une certaine mesure, des gestionnaires de réseaux domestiques : passeriez-vous immédiatement de votre fournisseur d’accès internet actuel, auquel vous faites confiance, à un nouveau fournisseur avec lequel vous n’avez aucune expérience, simplement parce qu’il vous promet de réduire de 20 % le coût de votre bande passante ?
Personnellement, je chercherais une meilleure raison, l’enjeu est trop important puisque mon gagne-pain dépend d’une connectivité internet fiable.
Un autre aspect à prendre en compte est que les grands opérateurs du monde entier sont parfaitement conscients de la pression sur les prix à laquelle est soumise la connectivité MPLS haut de gamme.
Il est possible d’exploiter les performances des liaisons internet (généralement) redondantes dans de nombreuses zones géographiques en appliquant des techniques d’optimisation des liaisons.
C’est pourquoi les prix de MPLS ont baissé.
Il est clair que l’on est loin des niveaux de l’internet à large bande et que le rapport $ par Mbps est encore assez déséquilibré, mais la comparaison des prix n’est plus aussi scandaleuse qu’elle l’était auparavant.
Mais la vérité, c’est que MPLS n’est pas adapté à l’informatique dématérialisée.
À mon avis, c’est cela, plus que les considérations de coût, qui a incité les entreprises à étudier le SD-WAN et la connectivité internet directe dans les succursales.
Vous pouvez considérer cela comme une combinaison de coûts et de prise en charge de la topologie du cloud.
Si vous choisissez de prendre en charge la migration vers le nuage avec une topologie centrée sur MPLS, cela signifie que vous devrez fournir beaucoup plus de bande passante MPLS à chaque site.
Ce serait ruineux, et personne ne tente vraiment cette approche.
Par conséquent, le vrai problème est que MPLS impose une architecture WAN centralisée qui n’est tout simplement pas adaptée aux déploiements dans le nuage.
Par conséquent, le SD-WAN offre la possibilité de répartir le trafic destiné à l’informatique dématérialisée directement sur l’internet public depuis la succursale.
Problème résolu, n’est-ce pas ?
Pardonnez-moi d’être un opposant.
Cette connexion directe à l’internet pose encore deux problèmes : Le premier est celui dont nous parlons beaucoup ces jours-ci… il nécessite une posture de sécurité complètement remodelée.
Nous participons tous à cette discussion et l’ensemble du secteur se compose désormais de labradoodles enthousiastes qui courent avec diligence après la balle de tennis SASE (Secure Access Services Edge).
Il ne fait aucun doute que notre secteur s’attaque au nouveau modèle de sécurité. Mais l’autre problème dont nous ne parlons pas autant, c’est que si vous vous contentez d’envoyer le trafic sur Internet, cela peut fonctionner, mais cela peut se détériorer, et les garanties de SLA des FAI pour le haut débit public ne sont pas les meilleures.
Avec la grande majorité des solutions SD-WAN, vous externalisez les garanties de service de deux façons : (a) pour être entièrement fiable et déterministe, vous avez toujours besoin de MPLS; et (b) pour le reste, vous l’envoyez sur Internet, vous croisez les doigts et vous laissez un ou plusieurs FAI déterminer le meilleur itinéraire et la meilleure façon de gérer le trafic « best effort » que vous leur envoyez.
Et ai-je mentionné que vous n’avez qu’une visibilité opaque sur l’un ou l’autre, puisque vous n’en contrôlez ni n’en connaissez les rouages ?
C’est la raison pour laquelle le SD-WAN est appelé une technologie de superposition : son agilité est impressionnante parce qu’elle est basée sur la virtualisation et l’abstraction.
Son contrôle et sa visibilité sur la couche inférieure sont limités, voire inexistants.
Ne vous méprenez pas : il est clair que cela fonctionne souvent, mais lorsque ce n’est pas le cas, vous pouvez avoir du mal à en déterminer la raison.
Vous aurez besoin d’outils de surveillance des performances du réseau plus performants de la part de fournisseurs tiers, par exemple.
Dans un monde de superposition et de sous-couche, avec des ressources virtualisées en plus, le problème est que le dernier kilomètre et surtout le kilomètre intermédiaire deviennent abstraits et opaques.
Figure 1 : Aryaka HybridWAN : Permettre la diversité du WAN
Et c’est là que le modèle d’architecture Aryaka offre de puissants avantages :
- Il n’y a pas d’opacité sur les premiers, moyens et derniers kilomètres.
Ceci est particulièrement important pour les applications critiques, et la solution Aryaka offre une visibilité complète et permanente sur les performances du réseau et des applications.
Le premier et le dernier kilomètre fonctionnent avec des technologies d’optimisation avancées, et le kilomètre intermédiaire est assuré par le Layer 2 Global Core d’Aryaka, qui garantit toujours la bande passante souscrite par les entreprises. - Aryaka propose une architecture WAN Cloud-First.
Cela signifie que, sur notre infrastructure mondiale, nous fournissons une multitude de points de peering directs vers des services SaaS, IaaS, UCaaS qui optimisent automatiquement la topologie et fournissent une expérience supérieure à l’utilisateur final. - Nous pouvons coexister sans problème avec MPLS.
La grande différence est que, contrairement à la plupart des autres solutions SD-WAN, Aryaka ne perpétue pas la dépendance à MPLS pour les applications critiques de l’entreprise.
Le Global Layer 2 Core Network d’Aryaka constitue une véritable alternative, offrant des niveaux de performance MPLS, à moindre coût, avec une agilité commerciale bien plus élevée et des délais de provisionnement de 48 heures.
Mais je tiens à souligner que nous ne voulons pas forcer les migrations MPLS tout de suite.
Nous comprenons parfaitement et soutenons la migration au rythme qui convient aux gestionnaires de réseau.
Ce que nous observons, c’est que nos clients acquièrent rapidement confiance dans notre plateforme, puis commencent à abandonner MPLS au fur et à mesure de l’expiration des contrats, à des moments différents selon les sites et les zones géographiques.
Nous observons également que, dans plusieurs cas, les entreprises ont encore des applications patrimoniales qu’elles ne sont pas pressées de réarchitecturer, et qu’en raison d’exigences réglementaires ou de risques perçus, elles ne sont pas encore prêtes à abandonner la connectivité MPLS patrimoniale – donc, pour l’instant, nous coexistons pacifiquement et nous la soutenons, facilement compte tenu de notre support MPLS, de l’identification des applications et des politiques de transfert.
Nous vivons dans l’optique d’une architecture Cloud-First, mais nous ne vivons pas encore dans un monde Cloud-Only.
Donc – MPLS, nous ne sommes pas encore en train de vous rayer de la carte, comme le dit la chanson.
🙂 Rejoignez-moi demain pour une courte démonstration de notre support intégré pour MPLS et nous pourrons discuter de ce sujet plus en détail lors de la séance de questions-réponses en direct.
