DevOps für NetOps dreht sich um Skalierbarkeit

Lori Mac VittieDistinguished Engineer und Chief Evangelist | F5

Und Skalierung führt zu Geschwindigkeit. Und Geschwindigkeit führt zum Erfolg.

Angenommen, ein Entwickler kann eine Änderungsanfrage in zwei Stunden bearbeiten. Ein anderer Entwickler kann dieselbe Änderungsanfrage in 1,5 Stunden bearbeiten. Wie lange brauchen sie, wenn sie gemeinsam zweihundert Änderungsanfragen bearbeiten?

Ja, die Antwort lautet offensichtlich Bier.

Wahrscheinlich erinnern sich alle (mit einer gehörigen Portion Angst und Abscheu) an die berüchtigten Textaufgaben aus dem Mathematikunterricht über „Züge“ oder „Maler“, mit denen uns Bruchverhältnisse nähergebracht werden sollten. Das war tatsächlich ihre Absicht, auch wenn viele von uns daraus vor allem eine Abneigung gegen das Streichen und das Zugfahren mitgenommen haben. Und jede Menge Memes. Vergessen wir die Memes nicht.

Der Punkt ist, dass diese Art formelbasierter Messungen im Rechenzentrum – insbesondere im Netzwerk – zunehmend unverzichtbar wird. Denn die Budgets sind begrenzt (kaum zu glauben, oder? Wie verrückt ist das denn?), und man kann nur X Ingenieure einstellen, um Y Aufgaben zu erledigen. In einer Anwendungswelt, in der schnelle und häufige Release-Zyklen das A und O sind, ist die Anzahl der „X“, die man einstellen kann, um Releases termingerecht bereitzustellen, begrenzt.

Aus diesem Grund ist Skalierbarkeit eine der wichtigsten Triebfedern für „DevOps“ im Netzwerk, auch bekannt als „NetOps“. Durch die Anwendung der Betriebsprinzipien von DevOps auf das Netzwerk soll NetOps die erforderliche betriebliche Skalierbarkeit erreichen, damit „X“ Ingenieure die Arbeit „Y“ termingerecht und innerhalb der Budgetvorgaben erledigen können – selbst wenn das Verhältnis zwischen X und Y exponentiell ist (für Laien: wirklich extrem unausgewogen).

Das Problem mit Änderungsanforderungen ist real. Es wurde von einem Netzwerkingenieur geschildert, der mit einer wachsenden Zahl von Änderungsanforderungen konfrontiert war (definiert als: einen Load-Balancer-Endpunkt für eine Anwendung erstellen, ihn zum DNS hinzufügen und eine Firewall-Regel für den Zugriff erstellen). Diese drohten letztlich, die verfügbaren Mitarbeiter zu überlasten und gleichzeitig die Bearbeitungszeit zu verlängern.

Die Lösung lag natürlich in der Automatisierung, in der Anwendung der DevOps-Prinzipien und in der Bereitstellung einer Self-Service-Oberfläche, über die andere Ingenieure Anfragen stellen konnten, die anschließend im Ticketsystem dokumentiert und über verschiedene APIs für Netzwerk- und Anwendungsdienste ausgeführt wurden.

Die Einführung von Automatisierung (und Orchestrierung, da tatsächlich auch der gesamte Prozess automatisiert wird) ermöglicht es den vorhandenen Technikern nicht nur, den Betrieb zu skalieren, sondern hat den Prozess auch beschleunigt. Die Bearbeitung einer Änderungsanforderung dauert nicht mehr bis zu zwei Stunden, sondern nur noch fünf Minuten.

Ja, Sie haben richtig gelesen. Fünf Minuten statt bis zu zwei Stunden.

Das ist eine erhebliche Verbesserung der Geschwindigkeit, die sich aus der Möglichkeit ergibt, durch Automatisierung und Orchestrierung zu skalieren. Und obwohl es sich nicht um ein ehrgeiziges Projekt für das gesamte Rechenzentrum handelt, behebt es doch ein konkretes Problem, mit dem sowohl Techniker als auch Anwendungsverantwortliche häufig konfrontiert waren – in diesem Fall offenbar bis zu 200-mal pro Woche.

Genau so sollte der Netzwerkbetrieb Automatisierung und Orchestrierung im Produktivnetz angehen. Wenn man wiederholbare Aufgaben identifiziert, die vom Change Advisory Board als trivial eingestuft werden (d. h., sie sind nachweislich unterbrechungsfrei und werden von den meisten Technikern im Schlaf beherrscht), können sich erhebliche Skalierungsmöglichkeiten ergeben. Dadurch lässt sich die Geschwindigkeit erreichen, die laut Fachbereichen und Anwendungsverantwortlichen gleichermaßen im Netzwerk erforderlich ist.

Das Aufspüren jener Bereiche, die sich mit möglichst geringem Störungsrisiko automatisieren lassen, gibt den Entwicklern den nötigen Freiraum, sich auf Aufgaben zu konzentrieren, die noch nicht für eine Automatisierung geeignet sind. Dieser Fokus ermöglicht zudem eine schnellere Umsetzung anderer Services, da die Entwickler nicht mehr unverhältnismäßig viel Zeit für einfachere, wiederkehrende Aufgaben aufwenden müssen.

Ich kann gar nicht genug betonen, wie entscheidend ein CPR-Ansatz für die Netzwerkautomatisierung ist: Eine konsistente, vorhersehbare und wiederholbare Automatisierung ermöglicht eine effizientere Skalierung und eine schnellere Bereitstellung bei einem geringeren Risiko von Störungen durch Fehler. Dabei werden die sogenannten Betriebsmodelle „Modus 1“ und „Modus 2“ miteinander vereint: Zuverlässigkeit und Stabilität haben oberste Priorität, ohne dass auf Agilität verzichtet werden soll. Durch einen CPR-Ansatz bei der Automatisierung und Orchestrierung im Netzwerk können Unternehmen ihre Agilität steigern, ohne die Zuverlässigkeit eines Netzwerks, das sehr viele andere Anwendungen – im Durchschnitt etwa 200 – bereitstellen muss, nennenswert zu gefährden.

Rechenzentrumsnetzwerke bestehen aus etablierten und neuen Technologien, die oft mit MacGyver-artigen Methoden zusammengehalten werden, für die Kaugummi und Angelschnur nötig sind. Diese Netzwerke müssen gleichzeitig Anwendungen unterstützen, die seit fast fünfzig Jahren produktiv im Einsatz sind (Mainframes gibt es immer noch), sowie neue Anwendungen, die auf Technologien basieren, die kaum den Kinderschuhen entwachsen sind (wie Container). Sie müssen alle Anwendungen zuverlässig und sicher bereitstellen. Diese Standards dürfen nicht zugunsten der Geschwindigkeit und Häufigkeit vernachlässigt werden, die neuere, attraktivere Anwendungen erfordern.

Doch der Netzwerkbetrieb kann ein Gleichgewicht schaffen, das es beiden ermöglicht, nebeneinander zu bestehen, wenn er diejenigen Aufgaben und Optionen für die Servicebereitstellung identifiziert und anschließend weitestgehend automatisiert, die keine Unterbrechungen verursachen und von der Änderungskontrolle und anderen Genehmigungsinstanzen als reine Routineaufgaben betrachtet werden.

Schließlich ändert sich unsere bevorzugte Formel zur Berechnung der Zeit, die für das Streichen eines Hauses benötigt wird, erheblich, wenn die beteiligten Maler statt handgeführter Pinsel automatische Farbroller erhalten.

Machen Sie sich nicht so viele Gedanken darüber, das Netzwerk zu ändern – ändern Sie stattdessen einfach die Gleichung.

Über den Autor

Lori Mac VittieDistinguished Engineer und Chief Evangelist | F5

Lori MacVittie ist Distinguished Engineer und Chief Evangelist im Office of the CTO von F5 und verfügt über umfassende Expertise in den Bereichen Anwendungsbereitstellung, Automatisierungsstrategie und Infrastruktur. Sie ist dafür bekannt, Komplexität verständlich zu machen – ob sie Leitplanken für KI-Agenten definiert, fragile Multicloud-Architekturen analysiert oder die Grenzen skalierbarer Systeme auslotet. Sie verfügt über mehr als dreißig Jahre Branchenerfahrung in der Anwendungsentwicklung, IT-Architektur sowie im Netzwerk- und Systembetrieb. Bevor sie zu F5 kam, war sie als mehrfach ausgezeichnete Technologie-Redakteurin tätig. MacVittie hat einen Masterabschluss in Informatik und ist eine produktive Autorin, deren Veröffentlichungen die Bereiche Sicherheit, Cloud und Unternehmensarchitektur abdecken. Außerdem spielt sie leidenschaftlich gern Brett- und Videospiele und vertritt mit voller Überzeugung klare Ansichten zum Thema Käse.

Weitere Blogbeiträge von Lori Mac Vittie