Vor ein paar Tagen habe ich mir den Film „Music and Lyrics“ noch einmal angeschaut.
Es gibt einen extrem kitschigen Song, den Hugh Grant irgendwann in dem Film singt, mit dem Titel „Don’t write me off yet“.
Ich dachte mir, wenn MPLS irgendwie in „The Masked Singer“ antreten könnte, würde es ganz sicher „Don’t write me off yet“ als Titelsong wählen.
Ja, ich bin ein Nerd, sehe mir kitschige Filme an und die COVID-Ausgrenzung hat dazu geführt, dass ich anfange, schreckliche Serien auf Hulu zu schauen – ich entschuldige mich dafür.
Also genug davon.
Lassen Sie uns über MPLS sprechen.
Ich kenne es, seit es ursprünglich Tag Switching genannt wurde.
Dann haben wir uns für ein paar Jahre aus den Augen verloren, während ich mich mit anderen Dingen beschäftigte, und als ich wieder in die Netzwerktechnologie zurückkehrte, drehte sich so ziemlich alles in der Enterprise-Wide-Area-Netzwerktechnologie um MPLS.
Und warum auch nicht?
Es brachte echte Anforderungen der Unternehmensklasse wie 5-Nines-Zuverlässigkeit und deterministisches QoS-Verhalten in die IP-Backbones der Welt und ermöglichte es den Unternehmen, der neuen Art des IP-basierten Transports (nicht zu verwechseln mit dem Internet) wirklich zu vertrauen und die Welt der Mietleitungen zu verdrängen (es sei denn, Sie haben heutzutage das Geld, um Dark Fiber zu kaufen).
Aber worauf ich hinaus will… in der SD-WAN-Welt war es für alle ein Steckenpferd, MPLS eine große Breitseite zu verpassen.
Hier sind ein paar Beispiele:
- „Es ist super teuer!“
- „Es dauert ewig, bis wir etwas bereitstellen und verfügbar sind!“
- „Sie ist darauf ausgelegt, den Datenverkehr einfach an einen zentralen Standort weiterzuleiten, und diese Topologie ist für den Einsatz von Cloud-Technologie völlig ungeeignet!“
Und obwohl an diesen Aussagen natürlich etwas Wahres dran ist, verstehe ich, warum viele Netzwerkmanager immer noch auf MPLS vertrauen und sich bei der Erwägung einer Migrationsstrategie vorsichtig auf einen sicheren Weg begeben wollen, der den Erfolg garantiert.
Geben wir es zu: Nur wenige von uns gehen gerne ein Risiko ein, wenn es um wichtige berufliche Entscheidungen geht, und Netzwerkmanager tragen die Last, zuverlässige und vorhersehbare Unternehmensverbindungen bereitzustellen, die ihr Geschäft unterstützen.
Zwar ist es schön, neue Projekte schneller umzusetzen, aber niemand möchte, dass das Unternehmensnetzwerk ausfällt oder sich verschlechtert, weil dann die Hölle losbricht.
Machen wir uns nichts vor: Das Netzwerk muss zuverlässig sein und vorhersehbar funktionieren, und MPLS ist ein bewährtes Instrument, um dies zu gewährleisten.
Wenn ich heute ein Netzwerkmanager wäre, würde auch ich einen schrittweisen, gemessenen und risikofreien Ansatz wählen, wenn ich eine Migration weg von MPLS in Betracht ziehe.
Oder anders ausgedrückt, da wir alle bis zu einem gewissen Grad Heimnetzwerkmanager sind, da wir von zu Hause aus arbeiten: Würden Sie sofort von Ihrem derzeitigen, vertrauten Internetanbieter zu einem neuen Anbieter wechseln, mit dem Sie keine Erfahrung haben, nur weil dieser Ihnen verspricht, Ihre Breitbandkosten um 20% zu senken?
Ich persönlich würde nach einem besseren Grund suchen, es steht zu viel auf dem Spiel, da mein Lebensunterhalt von einer zuverlässigen Internetverbindung abhängt.
Ein weiterer Aspekt ist, dass die großen Netzbetreiber auf der ganzen Welt den Preisdruck, dem MPLS-Premium-Konnektivität ausgesetzt ist, genau kennen.
Mit Hilfe von Link-Optimierungstechniken ist es möglich, die hohe Leistung von (normalerweise) redundanten Internetverbindungen in vielen Regionen zu nutzen.
Daher sind die MPLS-Preise gesunken.
Natürlich sind sie noch lange nicht auf dem Niveau von Internet-Breitbandverbindungen, und das Verhältnis von $ pro Mbps ist immer noch recht unausgewogen, aber der Preisvergleich ist nicht mehr ganz so skandalös wie früher.
Aber die Wahrheit ist, dass MPLS nicht Cloud-freundlich ist.
Meiner Meinung nach sind es eher diese Faktoren als Kostenerwägungen, die Unternehmen dazu veranlasst haben, SD-WAN und direkte Internetkonnektivität in den Zweigstellen zu erforschen.
Sie können es als eine Kombination aus Kosten und Unterstützung der Cloud-Topologie betrachten.
Wenn Sie sich dafür entscheiden, die Cloud-Migration mit einer MPLS-zentrierten Topologie zu unterstützen, bedeutet dies, dass Sie an jedem Standort viel mehr MPLS-Bandbreite bereitstellen müssten.
Das wäre ruinös, und deshalb versucht niemand diesen Ansatz wirklich.
Der eigentliche Knackpunkt ist also, dass MPLS eine zentralisierte WAN-Architektur erzwingt, die für Cloud-Implementierungen einfach ungeeignet ist.
SD-WAN bietet daher die Möglichkeit, den für die Cloud bestimmten Datenverkehr von der Zweigstelle aus direkt in das öffentliche Internet zu leiten.
Problem gelöst, oder?
Verzeihen Sie mir, dass ich ein Pessimist bin.
Diese direkte Verbindung zum Internet wirft immer noch zwei Probleme auf: Das erste ist eines, über das wir in diesen Tagen viel sprechen… es erfordert eine völlig neu gestaltete Sicherheitshaltung.
Wir alle beteiligen uns an dieser Diskussion, und die gesamte Branche besteht inzwischen aus begeisterten Labradoodles, die eifrig dem SASE (Secure Access Services Edge) Tennisball hinterherjagen.
Es besteht kaum ein Zweifel daran, dass sich unsere Branche mit dem neuen Sicherheitsmodell auseinandersetzt. Aber das andere Problem, über das wir nicht so viel sprechen, ist, dass der Datenverkehr, wenn Sie ihn einfach ins Internet leiten, zwar funktionieren, aber sich auch verschlechtern kann, und die SLA-Garantien der ISPs für öffentliche Breitbandnetze sind nicht die besten.
Bei der überwiegenden Mehrheit der SD-WAN-Lösungen lagern Sie die Servicegarantien im Grunde auf zwei Arten aus: (a) um absolut zuverlässig und deterministisch zu sein, benötigen Sie immer noch MPLS; und (b) für den anderen Kram schicken Sie ihn ins Internet, drücken die Daumen und lassen einen oder mehrere ISPs die beste Route und den besten Weg herausfinden, um den bestmöglichen Datenverkehr zu verarbeiten, den Sie ihnen schicken.
Und habe ich schon erwähnt, dass Sie nur einen undurchsichtigen Einblick in beide Systeme erhalten, da Sie weder die Kontrolle noch Einblicke in das Innenleben der Systeme haben?
Aus diesem Grund wird SD-WAN als Overlay-Technologie bezeichnet: Ihre Flexibilität ist großartig, weil sie auf Virtualisierung und Abstraktion basiert.
Die Kontrolle und der Einblick in oder über das Underlay sind begrenzt bis nicht vorhanden.
Verstehen Sie mich nicht falsch: Natürlich funktioniert sie oft, aber wenn sie nicht funktioniert, ist es schwierig, die Gründe dafür zu ermitteln.
Zum einen benötigen Sie leistungsfähigere Tools zur Überwachung der Netzwerkleistung von Drittanbietern.
In einer Overlay-Underlay-Welt mit virtualisierten Ressourcen besteht das Problem darin, dass die letzte und vor allem die mittlere Meile abstrahiert und undurchsichtig wird.
Abbildung 1: Aryaka HybridWAN: Ermöglichung der WAN-Diversität
Und genau hier bietet das Architekturmodell von Aryaka starke Vorteile:
- Es gibt keine Undurchsichtigkeit der ersten, mittleren oder letzten Meilen.
Dies ist besonders wichtig für geschäftskritische Anwendungen. Die Lösung von Aryaka bietet eine vollständige, jederzeitige Transparenz der Netzwerk- und Anwendungsleistung.
Die erste und die letzte Meile arbeiten mit fortschrittlichen Optimierungstechnologien, und die mittlere Meile wird vom Aryaka Layer 2 Global Core bereitgestellt, der den Unternehmen stets die abonnierte Bandbreite garantiert. - Aryaka bietet eine Cloud-First WAN-Architektur.
Das bedeutet, dass wir über unsere globale Infrastruktur eine Vielzahl direkter Peering-Punkte zu SaaS-, IaaS- und UCaaS-Diensten bereitstellen, die automatisch die Topologie optimieren und eine hervorragende Endbenutzererfahrung bieten. - Wir können reibungslos mit MPLS koexistieren. Der große Unterschied ist, dass Aryaka – im Gegensatz zu den meisten anderen SD-WAN-Lösungen – die Abhängigkeit von MPLS für geschäftskritische Anwendungen nicht aufrechterhält. Das Aryaka Global Layer 2 Core Network ist eine echte Alternative, die MPLS-Leistungsniveaus zu niedrigeren Kosten, mit weitaus höherer geschäftlicher Agilität und 48 Stunden Bereitstellungszeit bietet.
Ich möchte jedoch betonen, dass wir MPLS-Migrationen nicht sofort erzwingen wollen.
Wir haben volles Verständnis für die Migration und unterstützen sie in jedem Tempo, mit dem sich Netzwerkmanager wohl fühlen.
Wir beobachten, dass unsere Kunden schnell Vertrauen in unsere Plattform gewinnen und dann beginnen, von MPLS weg zu migrieren, da die Verträge an verschiedenen Standorten und in verschiedenen Regionen zu unterschiedlichen Zeiten auslaufen.
Wir stellen auch fest, dass Unternehmen in einigen Fällen immer noch Legacy-Anwendungen haben, die sie nicht überstürzen wollen, und dass sie aufgrund gesetzlicher Vorschriften oder wahrgenommener Risiken noch nicht bereit sind, die Legacy-MPLS-Konnektivität aufzugeben.
Wir leben, um für Cloud-First zu bauen, aber wir leben noch nicht in einer reinen Cloud-Welt.
Also – MPLS, wir schreiben Sie noch nicht ab, wie es in dem Lied heißt.
🙂 Schauen Sie sich morgen eine kurze Demo zu unserer integrierten MPLS-Unterstützung an, und wir können dieses Thema in der Live-Antwortrunde weiter diskutieren.