Umfassende DevOps mit Aryaka Cloud-Zuerst WAN

Traditionelles-Networking-vs-Network-as-a-Service

In einer vorangegangenen BlogIch habe über Netzwerktechniker geschrieben, die die zweite Geige spielen (ganz zu schweigen davon, dass ich Leonard Bernsteins New Yorker und Wiener Philharmoniker erwähnt habe!), und wenn Sie auf LinkedIn nachschauen, habe ich bei einigen Kontakten (wir sind immer noch Freunde) einige Verachtung hervorgerufen. Es folgte eine lebhafte Debatte, und es wurde eingeräumt, dass Netzwerkingenieure dabei „NetOps“-Muster berücksichtigen müssen Cloud- Erste Ära, in der wir uns befinden. Aber für mich zeigt die Tatsache, dass wir versuchen, eine IT-Disziplin umzubenennen, während wir sie auf Netzwerke anwenden (DevOps muss irgendwie zu NetOps werden), dass wir im Netzwerkbereich immer noch denken, dass wir anders sind. Ich habe kategorisch dispBedenken Sie, dass Netzwerke anders sind und dass es uns umso besser geht, je schneller wir DevOps-Modelle (anstelle von NetOps-Modellen) einführen. Devops regiert die Cloud-Erste Anwendungs- und Infrastrukturumgebung, daher muss das Netzwerk diesem Beispiel folgen.

Traditionelles-Networking-vs-Network-as-a-Service

Das Besondere an NetOps: Wann immer es darum geht, liegt der Fokus auf Netzwerkprogrammierbarkeit mit Python, Konfigurationsautomatisierung oder Richtliniendefinition. Fachbegriffe dominieren die NetOps-Diskussion. Die DevOps-Diskussion hingegen konzentriert sich auf Geschäftstransformation, Kultur und Philosophie. NetOps findet statt – und das ist großartig –, aber der wirkliche Game-Changer im Networking bestünde darin, die Diskussion anzuregen und eine echte DevOps-Philosophie einzuführen. Um dies zu erreichen, müssen Networking-Experten in erster Linie geschäftliche Absichten und Unternehmenskultur verfolgen – und nicht technische Hilfsmittel.

Werfen wir einen kurzen Blick auf die Geschichte des Application Computing und darauf, wie es zu DevOps führte. Dann müssen Sie als Netzwerktechniker widerwillig zugeben, dass es da auffallende Vertrautheiten gibt und dass wir genau den gleichen Weg einschlagen und mit Sicherheit zum gleichen Ergebnis kommen werden: DevOps. Am Anfang war Eisen. In der Anwendungswelt ging es von Großrechnern zu Servern. Sie mussten sich liebevoll um Ihre Haustiere (auch Server genannt) kümmern: Sie mussten sie installieren, konfigurieren, ihr Betriebssystem patchen und gleichzeitig sicherstellen, dass es mit der Anwendung oder den Anwendungen, die Sie darauf ausgeführt haben, kompatibel blieben, die CPU oder den Speicher oder das Laufwerk manuell aktualisieren, wenn die Leistung nachließ degradieren. Dann kam die Virtualisierung. Plötzlich trat die „Kraft der Abstraktion“ ein (siehe Der legendäre Vortrag von Barbara Liskov), und Sie könnten mehr Zeit für Innovationen im Code aufwenden und weniger Zeit für die Behebung von Serverproblemen aufwenden. Diese Trennung ermöglichte As-a-Service-Modelle, und jetzt sehen wir Dinge wie Serverless Computing, Infrastructure as Code usw. „Vieh statt Haustiere“ ist eines der Schlagworte, wenn es um eine Anwendungsinfrastruktur geht, die zwischen Containern und Orchestrierung geworden ist völlig abstrahiert. Als Entwickler übermitteln Sie einfach Ihren Code an die Orchestrierung wanSorgen Sie dafür, dass die Einführung sehr schnell und im erforderlichen Umfang erfolgt, damit Ihre Benutzer ein großartiges Benutzererlebnis haben. Aber es ist Ihnen egal, wo und wie es passiert, das herauszufinden liegt bei Op(eration)s. Wenn man beide Dinge zusammennimmt: DevOps schafft eine Kultur, die Innovation und Geschäftsergebnisse vorantreibt.

Beim Networking 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 Enterperhebt euch WAN: Als ich in die Branche eintrat, führten wir gerade Geldautomaten-Infrastrukturen ein. Dann kamen IP-Router, und das hat Spaß gemacht. Dann haben wir begonnen, alle möglichen Anwendungen in das Router-Betriebssystem zu integrieren, wie VoIP, Sicherheitsfunktionen und vieles mehr. Diese „Haustiere“ waren sehr pflegeintensiv und hatten dennoch die Lebenserwartung eines Hamsters. Etwa alle zwei bis drei Jahre schien ein größeres Hardware-Upgrade erforderlich zu sein – größere CPUs, schnellere Schnittstellen, neue Switch-Struktur. Sie nennen es. Einige Leute in der Netzwerkwelt blickten mit etwas Neid über den Zaun, was die Anwendungswelt mit der Virtualisierung erreicht hatte, und SDN-Visionäre begannen, über Netzwerkabstraktionen zu sprechen. Es begann mit der Netzwerkvirtualisierung. Die überwiegende Mehrheit davon SD-WANs werden als virtuelle Überlagerung aufgebaut. Das ist großartig, weil dieses Overlay im Gegensatz zur zugrunde liegenden physischen Netzwerkinfrastruktur, auf die es für die Bereitstellung auf Geschäftsebene angewiesen ist, recht agil ist SLAs (Ich habe hier über das Overlay-Underlay-Dilemma geschrieben). Und ja, es gibt Zero-Touch-Provisioning. Aber fragen Sie Leute, die ein globales implementiert haben Do-It-Yourself SD-WAN wenn es für einen Anwendungsentwickler so einfach wäre, Code herauszugeben. Es ist sicherlich nicht (Link zum Network World-Artikel)! Es gibt mehrere Designhandbücher, die mehrere hundert Seiten lang sind, wenn man sich die andere Dokumentation anschaut, auf die sich der Designleitfaden bezieht. Die Richtlinien, die Sie am Tag 0 definieren müssen, sind ziemlich komplex, und Sie sollten sie besser richtig umsetzen. Oh, und du wirst es noch brauchen MPLS für geschäftskritische Anwendungen, und in vielen Fällen müssen Sie diese Links in verschiedenen Ländern selbst beschaffen und alles selbst zusammenfügen.

Zurück zu DevOps: Möglich wurde es durch X-as-a-Service-Bereitstellungsmodelle. Genau das ist es Aryaka tut für die Vernetzung. Ich nenne es gerne „Routerless Networking“ und leihe es mir zur Verdeutlichung vom Serverless Computing. Vergessen Sie Konfiguration und ständige Anpassungen. Niemals wird Ihnen ein Verkäufer eines Router-Anbieters sagen, dass es neue, viel bessere Hardware gibt und dass es eine Sonderaktion gibt. Liefern Sie klare Geschäftsergebnisse, machen Sie sich keine Gedanken über die Definition komplexer Netzwerkrichtlinien oder über die Art und Weise der Bereitstellung SLAs zwischen administrativen Grenzen, noch geht es um die ständige Feinabstimmung Ihres Netzwerks, um mit den ständigen Veränderungen Schritt zu halten IaaS und SaaS Verkehrsbelastungen. Aryaka löst einfach Ihre Geschäftsabsicht: Sagen Sie uns, wo sich Ihre Standorte befinden, welche Redundanz Sie benötigen, welche Ihre Top-Apps sind und wie Sie sind want, sie zu priorisieren – und zu sehen, wie das Netzwerk, das Sie sich vorgestellt haben, innerhalb von 48 Stunden oder weniger auf magische Weise entsteht. Darüber hinaus passt sich Ihr Network-as-a-Service ständig an Ihre sich ändernden Geschäftsanforderungen an. Aryaka verarbeitet und überwacht ständig die Daten seines globalen Layer-2-Netzwerks sowie aller Last-Mile-Links, die mit dem Kernnetzwerk verbunden sind, um Makrotrends zu erkennen und Kunden ständige Optimierungsmöglichkeiten zu bieten.

Es bedarf einer großen kulturellen Veränderung, ja. DevOps ist eine neue Philosophie und wird sich unweigerlich auch im Netzwerkbereich durchsetzen. Aryaka wurde als gebaut Cloud-Zuerst WAN um die DevOps-Kultur in die Vernetzung zu bringen: eine neue Art, Ihr globales Unternehmen global zu vernetzenerpsteigen Sie mit a cloud-erster Enterperhebt euch WAN Das sorgt für Agilität und Geschäftsergebnisse. Über 800 enterpAufstiege haben sich uns angeschlossen. Kommen Sie doch mal zu uns Demo unseres SmartServices-Portfolios?

Ü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.