In einem früheren Blog habe ich darüber geschrieben, dass Netzwerkingenieure die zweite Geige spielen (egal, dass ich Leonard Bernsteins New Yorker und Wiener Philharmoniker erwähnte!), und wenn Sie sich mein LinkedIn ansehen, habe ich mir damit den Spott einiger Kontakte zugezogen (wir sind immer noch Freunde). Es folgte eine gesunde Debatte, und es wurde eingeräumt, dass Netzwerkingenieure in dieser Cloud-First-Ära, in der wir uns befinden, „NetOps“-Muster einführen müssen. Aber die Tatsache, dass wir versuchen, eine IT-Disziplin umzubenennen, wenn wir sie auf Netzwerke anwenden (DevOps muss irgendwie zu NetOps werden), zeigt für mich, dass wir im Bereich Netzwerke immer noch denken, wir seien anders. Ich bestreite kategorisch, dass Netzwerke anders sind und dass wir umso besser dran sind, je schneller wir DevOps-Modelle (anstelle von NetOps) übernehmen. Devops beherrscht die Cloud-First Anwendungs- und Infrastrukturumgebung, daher muss das Netzwerk dem Beispiel folgen. 
Die Sache mit NetOps ist die: Wann immer es zur Sprache kommt, geht es um die Programmierbarkeit des Netzwerks mit Python, die Automatisierung der Konfiguration oder die Definition von Richtlinien.
Technische Begriffe dominieren die NetOps-Diskussion.
Die DevOps-Diskussion hingegen konzentriert sich auf die Umgestaltung des Unternehmens, die Kultur und die Philosophie.
NetOps ist in vollem Gange – und das ist großartig – aber der wirkliche Wendepunkt im Netzwerkbereich wäre, die Diskussion zu vertiefen und eine echte DevOps-Philosophie zu übernehmen.
Um dies zu erreichen, müssen Netzwerkexperten in erster Linie die geschäftlichen Absichten und die Unternehmenskultur in den Vordergrund stellen – und nicht die Technologie-Tools.
Lassen Sie uns kurz die Geschichte des Application Computing Revue passieren und wie sie zu DevOps geführt hat.
Dann werden Sie als Netzwerktechniker zähneknirschend zugeben müssen, dass es verblüffende Gemeinsamkeiten gibt und dass wir genau denselben Weg einschlagen und sicherlich zum selben Ergebnis kommen werden: DevOps.
Am Anfang war das Eisen.
In der Welt der Anwendungen ging es von Mainframes zu Servern.
Sie mussten sich liebevoll um Ihre Haustiere (aka Server) kümmern: Sie mussten sie installieren, konfigurieren, ihr Betriebssystem patchen und dabei sicherstellen, dass es mit der oder den Anwendungen, die Sie darauf laufen ließen, kompatibel blieb, und die CPU, den Speicher oder die Festplatte manuell aufrüsten, wenn die Leistung nachließ.
Dann kam die Virtualisierung.
Plötzlich war die „Macht der Abstraktion“ da (lesen Sie den legendären Vortrag von Barbara Liskov), und Sie konnten mehr Zeit mit der Entwicklung von innovativem Code verbringen und mussten sich weniger um Serverprobleme kümmern.
Diese Trennung ermöglichte as-a-Service-Modelle, und jetzt sehen wir Dinge wie serverloses Computing, Infrastruktur als Code usw.
„Vieh, nicht Haustiere“ ist eines der Schlagworte, wenn es um eine Anwendungsinfrastruktur geht, die zwischen Containern und Orchestrierung vollständig abstrahiert wurde.
Als Entwickler geben Sie Ihren Code einfach an die Orchestrierung weiter und möchten, dass er sehr schnell und in der erforderlichen Größenordnung bereitgestellt wird, damit Ihre Benutzer ein großartiges Benutzererlebnis haben.
Aber es ist Ihnen egal, wo und wie das geschieht, das müssen die Op(eration)s herausfinden.
Nehmen Sie beide Dinge zusammen: DevOps schafft eine Kultur, die Innovation und Geschäftsergebnisse fördert.
Im Netzwerkbereich müssen wir zugeben, dass wir uns immer noch um unsere Haustiere kümmern: Router, Switches und – ja, ich muss es sagen – Do-It-Yourself SD-WAN.
Werfen wir einen Blick auf die Geschichte des Unternehmens-WAN: Als ich in die Branche kam, haben wir ATM-Infrastrukturen eingeführt.
Dann kamen IP-Router auf, und das war lustig.
Dann begannen wir, alle möglichen Anwendungen in das Router-Betriebssystem zu integrieren, wie VoIP, Sicherheitsfunktionen und vieles mehr.
Diese ‚Haustiere‘ wurden sehr wartungsintensiv und hatten dennoch die Lebenserwartung eines Hamsters.
Alle zwei bis drei Jahre oder so brauchten Sie ein größeres Hardware-Upgrade – größere CPUs, schnellere Schnittstellen, neue Switch-Fabrics.
Was immer Sie wollen.
Einige Leute in der Netzwerkwelt blickten neidisch auf das, was die Anwendungswelt mit der Virtualisierung erreicht hatte, und die SDN-Visionäre begannen, über Netzwerkabstraktionen zu sprechen.
Die Netzwerkvirtualisierung kam in Gang.
Die große Mehrheit der SD-WANs wird als virtuelles Overlay aufgebaut. Das ist großartig, denn dieses Overlay ist im Gegensatz zur darunter liegenden physischen Netzwerkinfrastruktur, auf die es angewiesen ist, um SLAs auf Unternehmensebene zu erfüllen, recht flexibel (ich habe hier über das Overlay-Underlay-Dilemma geschrieben).
Und ja, es gibt Zero Touch Provisioning.
Aber fragen Sie die Leute, die ein globales Do-It-Yourself SD-WAN implementiert haben, ob das so einfach ist wie das Einspielen von Code für einen Anwendungsentwickler.
Das ist es ganz sicher nicht(Link zum Artikel in Network World)!
Es gibt mehrere Design-Leitfäden, die mehrere hundert Seiten lang sind, wenn Sie die andere Dokumentation prüfen, auf die der Design-Leitfaden verweist.
Die Richtlinien, die Sie an Tag 0 definieren müssen, sind ziemlich komplex, und Sie sollten sie besser richtig machen.
Ach ja, und für geschäftskritische Anwendungen benötigen Sie immer noch MPLS, und in vielen Fällen müssen Sie diese Verbindungen selbst über verschiedene Länder hinweg beschaffen und alles selbst zusammenflicken.
Zurück zu DevOps: Es wurde durch X-as-a-Service-Bereitstellungsmodelle möglich.
Das ist genau das, was Aryaka für die Vernetzung tut.
Ich bezeichne es gerne als routerloses Netzwerk, in Anlehnung an Serverless Computing, um es auf den Punkt zu bringen.
Vergessen Sie die Konfiguration und die ständigen Anpassungen.
Lassen Sie sich niemals von einem Verkäufer eines Routerherstellers erzählen, dass es eine neue, viel bessere Hardware gibt und dass es eine Sonderaktion gibt.
Kümmern Sie sich nicht um die Definition komplexer Netzwerkrichtlinien, nicht um die Bereitstellung von SLAs zwischen Verwaltungsgrenzen und auch nicht um die ständige Feinabstimmung Ihres Netzwerks, um mit den sich ständig ändernden IaaS- und SaaS-Verkehrslasten Schritt zu halten.
Aryaka löst einfach Ihre geschäftlichen Absichten: Sagen Sie uns, wo sich Ihre Standorte befinden, welche Redundanz Sie benötigen, welche Ihre wichtigsten Anwendungen sind und wie Sie diese priorisieren möchten – und sehen Sie, wie das Netzwerk, das Sie sich vorgestellt haben, innerhalb von 48 Stunden oder weniger auf magische Weise entsteht.
Und nicht nur das, sondern auch, wie sich Ihr Netzwerk-as-a-Service ständig an Ihre sich ändernden Geschäftsanforderungen anpasst.
Aryaka verarbeitet und überwacht ständig die Daten seines globalen Layer-2-Netzwerks sowie alle Verbindungen der letzten Meile, die mit dem Kernnetzwerk verbunden sind, um Makrotrends zu erkennen und den Kunden ständige Optimierungsmöglichkeiten zu bieten.
Es bedarf eines großen kulturellen Wandels, ja.
DevOps ist eine neue Philosophie, und sie wird sich unweigerlich auch im Netzwerkbereich durchsetzen.
Aryaka wurde als Cloud-First WAN entwickelt, um die DevOps-Kultur in den Netzwerkbereich zu bringen: eine neue Art, Ihr globales Unternehmen mit einem Cloud-First Enterprise WAN zu verbinden, das Agilität und Geschäftsergebnisse liefert.
Über 800 Unternehmen haben sich uns angeschlossen.
Warum kommen Sie nicht zu einer Demo unseres SmartServices-Portfolios?
