Vor ein paar Tagen habe ich mir den Film „Music and Lyrics“ noch einmal angeschaut. Es gibt ein extrem kitschiges Lied, das Hugh Grant irgendwann im Film singt, mit dem Titel „Don’t write me off yet“. Ich dachte mir, wenn MPLS irgendwie bei „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, schaue mir kitschige Filme an und die COVID-Ausgrenzung hat dazu geführt, dass ich anfange, schreckliche Serien auf Hulu zu schauen – ich entschuldige mich. 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. Als ich dann in die Netzwerktechnologie zurückkehrte, drehte sich so ziemlich alles im Bereich der Enterprise-Wide-Area-Netzwerktechnologie um MPLS. Und warum 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 Unternehmen, der neuen Art des IP-basierten Transports (nicht zu verwechseln mit dem Internet) wirklich zu vertrauen und die Welt der Mietleitungen überflüssig zu machen (es sei denn, Sie haben heutzutage das Geld, um Dark Fiber zu kaufen).
Aber was ich damit sagen will… in der SD-WAN-Welt war es ein Steckenpferd für alle, MPLS eine große Breitseite zu verpassen. Hier sind ein paar:
- „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 bei der Erwägung einer Migrationsstrategie vorsichtig einen sicheren Weg beschreiten wollen, der den Erfolg garantiert.
Geben wir es zu: Nur wenige von uns spielen gerne und gehen große Risiken 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. Die schnellere Umsetzung neuer Projekte ist zwar großartig, aber niemand möchte, dass das Unternehmensnetzwerk ausfällt oder beeinträchtigt wird, weil dann die Hölle los ist. 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 sich die großen Netzbetreiber weltweit des Preisdrucks, dem MPLS-Premium-Konnektivität ausgesetzt ist, durchaus bewusst sind. Mit Hilfe von Link-Optimierungstechniken ist es möglich, die hohe Leistung von (typischerweise) redundanten Internetverbindungen in vielen Regionen zu nutzen. Daher sind die MPLS-Preise gesunken. Natürlich ist das Verhältnis von $ pro Mbps bei weitem nicht so hoch wie bei den Internet-Breitbandanschlüssen, aber der Preisvergleich ist nicht mehr ganz so skandalös wie er einmal war.
Die Wahrheit ist jedoch, 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 Internetverbindungen in Zweigstellen zu untersuchen. 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üssen. Das wäre ruinös, also 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. Folglich bot SD-WAN die Möglichkeit, den für die Cloud bestimmten Datenverkehr von der Zweigstelle aus direkt in das öffentliche Internet zu leiten. Problem gelöst, richtig?
Verzeihen Sie mir, dass ich ein Pessimist bin. Diese direkte Verbindung zum Internet wirft immer noch zwei Probleme auf:
Die erste ist eine, über die wir in diesen Tagen viel sprechen… sie erfordert eine völlig neue Sicherheitshaltung. Wir alle nehmen an dieser Diskussion teil und die gesamte Branche besteht jetzt aus begeisterten Labradoodles, die fleißig 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 oft 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 die anderen Dinge schicken Sie sie ins Internet, drücken die Daumen und lassen einen oder mehrere ISPs die beste Route und den besten Weg finden, um den von Ihnen gesendeten Datenverkehr bestmöglich zu verarbeiten. Und habe ich schon erwähnt, dass Sie nur einen undurchsichtigen Einblick in beide haben, da Sie weder die Kontrolle noch Einblicke in das Innenleben der beiden Unternehmen haben? Aus diesem Grund wird SD-WAN auch als Overlay-Technologie bezeichnet: Seine Flexibilität ist großartig, weil es auf Virtualisierung und Abstraktion basiert. Seine Kontrolle und Sichtbarkeit auf oder über die Unterlage ist begrenzt bis nicht vorhanden. Verstehen Sie mich nicht falsch: Natürlich funktioniert es oft, aber wenn es nicht funktioniert, fällt es Ihnen vielleicht schwerer, den Grund dafür zu finden. Zum einen benötigen Sie leistungsfähigere Tools zur Überwachung der Netzwerkleistung von Drittanbietern. In einer Overlay-Underlay-Welt, noch dazu 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 bis zur ersten, mittleren oder letzten Meile. Dies ist besonders wichtig für geschäftskritische Anwendungen. Die Lösung von Aryaka bietet einen vollständigen, jederzeit verfügbaren Einblick in die 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.
Aber ich möchte darauf hinweisen, dass wir MPLS-Migrationen nicht sofort erzwingen wollen. Wir verstehen und unterstützen die Migration in jedem Tempo, das den Netzwerkmanagern genehm ist. Wir beobachten, dass unsere Kunden schnell Vertrauen in unsere Plattform gewinnen und dann beginnen, von MPLS wegzuziehen, da die Verträge an den verschiedenen Standorten und in den verschiedenen Regionen zu unterschiedlichen Zeiten auslaufen.
Wir stellen auch fest, dass Unternehmen in vielen Fällen immer noch Legacy-Anwendungen haben, die sie nicht überstürzen wollen, und dass sie aufgrund gesetzlicher Vorschriften oder eines wahrgenommenen Risikos noch nicht bereit sind, sich von der Legacy-MPLS-Konnektivität zu lösen. Daher können wir vorerst friedlich koexistieren und sie unterstützen, was angesichts unserer MPLS-Unterstützung, Anwendungsidentifizierung und Weiterleitungsrichtlinien einfach ist.
Wir leben als Architekten für Cloud-First, 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. 🙂
Sehen 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.
