ONUG Herbstkonferenz 2019

Ich habe es wirklich genossen, letzten Monat an der ONUG-Herbstkonferenz in New York teilzunehmen. Falls jemand das bestätigen müsste SD-WAN kommt richtig gut voran und schafft es in den Mainstream, die Anwesenheit hätte den Beweis erbracht: hohe Besucherzahl, tolle Diskussionen vor Ort, viele Enterpsteigt auf und teilt ihre Erfahrungen mit SD-WAN Implementierungen. Darüber hinaus beginnen Diskussionen über Industriestandards und Referenzarchitekturen für SD-WAN Das von ONUG und MEF vorangetriebene Projekt zeigt, dass die Technologie ihre Reife erreicht.

Wie Sie sich vorstellen können, diskutierten wir viele verschiedene Themen auf der überfüllten Ausstellungsfläche sowie in den Proof of Concept-Präsentationen (Sie können meine 10-minütigen Live-Vorträge sehen). Aryaka Demo hier). Aber wenn ich die Themen zusammenfassen müsste, die wir am meisten diskutiert haben, würde ich Folgendes auswählen – und natürlich Ihre eigenen Ansichten einladen.

SD-WAN Komplexität

Während SD-WAN Ursprünglich als die Technologie angepriesen, die die Netzwerkkomplexität beenden würde, berichten viele Benutzer nun, dass dies der Fall sei SD-WAN Die Bereitstellungen hielten das ursprüngliche Versprechen einer Netzwerkvereinfachung nicht ein. Tatsächlich habe ich mit mindestens drei Ärzten gesprochenerpRise-Benutzer, die ihre gestoppt hatten SD-WAN Projekte und bewerteten ihre Herangehensweise neu SD-WAN Implementierung. Der Hauptschmerzpunkt, von dem ich gehört habe, war das gleiche Problem, das auch das Unternehmen verfolgt Enterperhebt euch WAN und getriebene Komplexität in der Vergangenheit: Anwendungsleistung, Benutzererfahrung und QoS (sie sind alle miteinander verwoben). In der Theorie, SD-WAN sollte diesem Problem begegnen, indem „einfache“ Richtlinien zentral definiert und die Verteilung an alle Standorte orchestriert/automatisiert werden. Und siehe da, die Richtlinien scheinen weder so einfach noch universell anwendbar zu sein. Am Ende verbringen Netzwerkingenieure viel Zeit damit, die ersten „universellen“ Richtlinien zu erstellen, die oft noch an die 600+ CLI-Befehle der Vergangenheit erinnern. Darüber hinaus müssen diese Richtlinien aufgrund der Besonderheiten des Last-Mile-Verhaltens häufig für viele Standorte angepasst werden, was im Grunde zu derselben Art von Knoten-für-Knoten-Vorgängen führt, die EnterpAnstieg der Vernetzung in der Vergangenheit ineffizient. Sie werden nicht überrascht sein, wenn ich Ihnen sage, dass dieses Problem bei HNO besonders häufig vorkommterpAufstiege, die sich auf „Do-It-Yourself“ eingelassen hatten SD-WAN Projekte.

Es wird Sie auch nicht wundern, wenn ich Ihnen das sage AryakaDer Ansatz von löst dieses Problem. Und bevor Sie sagen: „Nun, weil es ein ist Managed-Services-Modell und du setzt alles einfach für mich um, sodass ich wenig Kontrolle über meine eigenen habe SD-WAN Umsetzung“, ich fordere Sie auf, sich meine anzusehen ONUG POC-Demo. Wir verfügen über ein Konfigurationsportal, mit dem Sie globale und lokale Richtlinien erstellen und ändern können. Die Navigation ist sehr intuitiv. Darüber hinaus bedeutet unsere Kontrolle über die letzte Meile, dass sie in den allermeisten Fällen universell ist QoS Richtlinien funktionieren einfach. Möglicherweise erstellen Sie mehr als nur eine globale Richtlinie, um ein paar unterschiedliche Anwendungsmixmuster zu berücksichtigen, aber wenn ich durch die Bereitstellungen unserer Kunden navigiere, sehe ich, dass Ihr typisches Netzwerk mit 200 Zweigstellen nur zwei oder vielleicht drei hat QoS Richtlinien, mehr nicht.

Sichtbarkeit und Fehlerbehebung

Die Ausstellungsfläche in New York verdeutlichte dies SD-WAN hat sich zu einem sehr fruchtbaren Spielplatz für Network Performance Monitoring (NPM)-Unternehmen entwickelt. Verstehen Sie mich nicht falsch, ich weiß, dass es viele sehr gute Gründe für eine Entlassung gibterpsteigt auf, um NPM-Tools einzuführen. Wenn ich mein eigenes Netzwerk verwalten würde, würde ich darauf achten, mindestens ein zusätzliches, herstellerneutrales Tool auszuwählen, das mir ein hohes Maß an Transparenz und Fehlerbehebungsfunktionen bietet. Allerdings erscheint es merkwürdig, dass es anscheinend zu einer zwingenden Voraussetzung geworden ist, ein weiteres NPM-Tool als Ent bereitzustellenerpDie Aufsteiger beginnen ihren Tag 0-1-2 SD-WAN Reisen. Die Hauptgründe bestehen darin, bei der Definition funktionierender Verkehrsrichtlinien am Tag 0 zu helfen und das Overlay- und Underlay-Netzwerkverhalten beim Betrieb/Fehlerbehebung in Szenarios am Tag 1 oder 2 mit Do-It-Yourself in Einklang zu bringen SD-WAN. Am ersten Tag Sie want um herauszufinden, warum Verkehrsrichtlinien möglicherweise nicht wie erwartet funktionieren, und an Tag 2 müssen Sie Probleme mit der Anwendungsleistung beheben. In beiden Fällen hilft es sicherlich nicht, wenn die Sicht auf die virtuelle Überlagerung und die physische Unterlage unterbrochen ist.

Und noch einmal kann ich Ihnen sagen – und Ihnen beweisen –, dass dieses Problem mit dem nicht auftritt Aryaka Ansatz. Das MyAryaka Die Kundenkonsole bietet Kunden eine vollständige End-to-End-Transparenz über die erste, mittlere und letzte Meile. Es gibt keine Probleme mit der geteilten Sichtbarkeit von Overlay und Underlay, die in Einklang gebracht werden müssen, weil Aryaka verfügt über die vollständige Kontrolle über die mittlere Meile (unseren Global Layer 2 Core) und den Closed-Loop-Ansatz, der diese eng verbindet Aryaka PoPs mit den Edge-Geräten (Aryaka Network Access Points aka ANAP) bietet umfassende Echtzeiteinblicke in die Leistung auf der ersten und letzten Meile. Wenn irgendwo ein Problem auftritt, ist der Fehlerbehebungsprozess sehr einfach (siehe auch hier). meine ONUG-Demo). Ich sollte auch erwähnen, dass unsere SLAs Arbeiten Sie einfach vom ersten Tag an. So einfach ist das.

Die Rolle des Netzwerkingenieurs

Es gab zwar auch viele andere Diskussionsthemen, aber eines, das ich sehr regelmäßig ansprach, war die Zukunft der Rolle des Netzwerkingenieurs. Ich schätze, das liegt daran, dass mein Hintergrund mich als einen kleinen Netzwerk-Graubart erkennen lässt (vielleicht sollte ich mir den Bart rasieren :-D) und auch daran, dass ich für ein Network-as-a-Service-Unternehmen arbeite Aryaka dass Netzwerktechniker mich fragen: „Was soll ich den ganzen Tag tun, wenn ich Ihren Dienst kaufe?“ Mache ich mich nicht überflüssig?“ Es ist keine einfache Diskussion, aber wir alle wissen, dass sich die Rolle des Netzwerktechnikers verändert, und zwar schon seit einiger Zeit. Hier ist ein Blog Ich habe vor über drei Jahren als Ghostwriter zu diesem Thema geschrieben (obwohl sich einige meiner Meinungen geändert haben!). Netzwerkingenieure müssen sich ansehen, wie sich die Rolle des Servers/Anwendungsingenieurs verändert hat. DevOps muss unser neues Schlagwort im Networking werden. Kurz gesagt bedeutet dies eine ständige und schnelle Anpassung der Infrastruktur an die Geschäftsanforderungen und einen Zustand kontinuierlicher betrieblicher Veränderungen. Das muss ich auch ganz klar sagen AryakaDie Hauptkunden von 's sind Experten für Netzwerkthemen, wie man jedes Mal leicht erkennen kann Sie nehmen an unseren Webinaren teil, der sich der Technologie und ihrer Möglichkeiten vollkommen bewusst ist. Aber sie sind auch Netzwerkingenieure, die schon früh entschieden haben, dass sich ihre Prioritäten verschieben und dass sie sich an der IT-Geschäftsdiskussion beteiligen und aus dem Netzwerk-Elfenbeinturm herauskommen müssen. Im WAN Router-Ära, ein Netzwerkmodell passte fast zu jedem GeräterpAufstieg, und Konnektivität war der Schlüsseldienst. Netzwerkingenieure mussten sich nicht der übergreifenden Geschäftsmodelle oder Prioritäten bewusst sein. Im digitalen, cloudIn der ersten Ära muss sich das Netzwerk ständig und schnell an die Geschäftsanforderungen anpassen – sonst steht es im Weg und wird umgangen und/oder ausgelagert. Der Aryaka Das Bereitstellungsmodell hilft Netzwerktechnikern, indem es ihnen (mehreren Studien zufolge) mehr als 70 % ihrer Zeit für die Fehlerbehebung entlastet und ihnen mehr Zeit für die Planung des Geschäftserfolgs gibt.

Bitte kontaktieren Sie uns dazu Holen Sie sich eine Demo von einem unserer Experten!

Über den Autor

Paul Liesenberg

Paul ist Direktor in Aryaka's Produktlösungsteam. Paul verfügt über mehr als 20 Jahre Erfahrung in den Bereichen Produktmarketing, Produktmanagement, Vertriebstechnik, Geschäftsentwicklung und Softwareentwicklung in Cisco, LiveAction, Bivio Networks und StrataCom. Paul liebt Tauchen, Motorradfahren, offene Softwareprojekte und Ölmalerei.