Gibt es eine minimal praktikable Bereitstellung für NetOps?
Geht es bei der Netzwerkautomatisierung wirklich um alles oder nichts?
Netzwerkautomatisierung – die Praxis des DevOpsing der Produktionspipeline – wird bereits von einem erheblichen Prozentsatz von Organisationen eingesetzt. Während nur sehr wenige die Automatisierung vollständig nutzen, führt die Mehrheit (77 % laut unserem jüngsten State of Application Delivery ) entweder Pilotprojekte durch oder setzt sie teilweise in der Produktion ein.
Eines der Konzepte, das eng mit DevOps verknüpft ist – und daher oft mit NetOps verbunden ist – ist die Vorstellung eines minimal funktionsfähigen Produkts (MVP).
Es ist Teil der Agile-Methodik und wird verwendet, um Entwicklungszyklen zu beschleunigen und Lösungen schneller auf den Markt zu bringen. Das ist etwas, was wir im „Netzwerk“ dringend brauchen. Sie erinnern sich vielleicht an die Appian-Umfrage, auf die in einem früheren Blog verwiesen wurde. Sie überraschte uns mit dem Ergebnis, dass 72 % der Befragten kein Vertrauen in die Skalierungsfähigkeit der IT haben, um die Anforderungen des Unternehmens zu erfüllen.
Autsch. Trotz des relativ umfassenden Einsatzes von Automatisierung in der IT mangelt es Entwicklern und Geschäftspartnern immer noch an Vertrauen in unsere Fähigkeit, die Aufgaben zu erledigen.
Daher ist es gar nicht so verrückt, Tools, Technologien und Methoden aus DevOps zu übernehmen, um die Dinge zu beschleunigen (durch intelligentere Skalierung). Aber bevor wir herausfinden können, wie MVP auf das Netzwerk angewendet wird, müssen wir verstehen, was es ist. Für alle, die mit DevOps, Agile oder MVP nicht vertraut sind, hier eine einfache Definition der Agile Alliance:
Ein Minimum Viable Product (MVP) ist ein Konzept aus dem Lean Startup, das die Bedeutung des Lernens bei der Entwicklung neuer Produkte betont. Eric Ries definierte ein MVP als die Version eines neuen Produkts, die es einem Team ermöglicht, mit geringstem Aufwand ein Maximum an validierten Erkenntnissen über die Kunden zu sammeln . Dieses validierte Wissen zeigt, ob Ihre Kunden Ihr Produkt tatsächlich kaufen werden.
Eine zentrale Prämisse hinter der MVP-Idee besteht darin, dass Sie ein tatsächliches Produkt erstellen (das möglicherweise nicht mehr als eine Zielseite oder ein scheinbar automatisierter Dienst ist, hinter den Kulissen jedoch vollständig manuell abläuft), das Sie Kunden anbieten und deren tatsächliches Verhalten im Umgang mit dem Produkt oder Dienst beobachten können. Zu sehen, was Menschen in Bezug auf ein Produkt tatsächlich tun, ist viel zuverlässiger, als sie zu fragen, was sie tun würden.
Ein Team nutzt MVP effektiv als Kernstück einer Experimentierstrategie. Sie gehen von der Hypothese aus, dass ihre Kunden ein Bedürfnis haben und dass das Produkt, an dem das Team arbeitet, dieses Bedürfnis befriedigt. Das Team liefert diesen Kunden dann etwas, um herauszufinden, ob die Kunden das Produkt tatsächlich zur Befriedigung dieser Bedürfnisse nutzen werden. Auf der Grundlage der aus diesem Experiment gewonnenen Informationen setzt das Team die Arbeit am Produkt fort, ändert sie oder bricht sie ab.
An diesem Punkt dieser Abhandlung stelle ich fest, dass sich viele der mit DevOps (und den damit verbundenen Technologien und Methoden) verbundenen Konzepte nicht immer gut auf eine NetOps-Initiative übertragen lassen. „Experimentieren“ ist kein Begriff, den Ingenieure, Architekten oder Führungskräfte in der IT verwenden, wenn sie über Änderungen am Netzwerk diskutieren.
Den Explosionsradius, verstehen Sie. Es ist groß und mächtig. Die Toleranz der meisten Organisationen gegenüber operationellen Risiken ist gering – und das aus gutem Grund. Ausfälle kosten echtes Geld – und manchmal auch Arbeitsplätze. Das Netzwerk ist nicht wirklich ein guter Ort zum Experimentieren.
Dies bedeutet jedoch nicht, dass es für NetOps keine minimal funktionsfähige Bereitstellung (MVD) gibt.
Definieren eines MVD für NetOps
Die Produktionspipeline besteht heute sowohl aus gemeinsam genutzten Ressourcen wie Switches, Routern, DNS und Multi-Cloud-Routing (GSLB) als auch aus Application pro App wie Load Balancern, WAF und Application .
Interessanterweise stellen wir fest, dass die mit gemeinsam genutzten Ressourcen verbundenen Änderungsraten recht gering sind. Das heißt, sie weisen eine niedrige Änderungsrate auf. Das ist gut, denn auch sie haben eine geringe Störungstoleranz. Wechseln Sie zu den Ressourcen pro App und Sie werden eine höhere Änderungsrate und eine größere Toleranz gegenüber Störungen feststellen.
Schließlich ist dies einer der Vorteile einer Pro-App-Architektur: Die Isolierung des Datenpfad schützt andere Apps vor Störungen, wenn etwas schief geht.
Entlang dieses Datenpfad befinden sich laut unserer Forschung durchschnittlich sechzehn verschiedene Application , die Unternehmen zur Bereitstellung und Sicherung ihrer Applications nutzen. Einige davon – wie eine Netzwerk-Firewall und DNS – sind gemeinsam genutzte Ressourcen. Andere sind es nicht, oder müssen es zumindest nicht sein. Sie werden heute möglicherweise auf einer gemeinsam genutzten Plattform bereitgestellt, könnten aber aus guten Gründen auch in ihren eigenen Datenpfad integriert werden.
Und genau das werde ich Ihnen natürlich geben.
Der gute Grund dafür ist, dass Sie effektiv ein MVD für eine Application entwickeln können , wenn Sie eine Pro-App-Architektur für die Application übernehmen, die von vornherein eng mit der App verknüpft sind.
Wie unsere Definition eines MVP sagt, muss das „Produkt“ (in unserem Fall eine App-Bereitstellung) nicht vollständig automatisiert sein. Wenn wir davon ausgehen, dass die riskantesten und am wenigsten toleranten Ressourcen weiterhin manuell konfiguriert (und überprüft) werden müssen, gewinnen wir dennoch an Boden. Firewalls und Kerndienste wie DNS unterliegen einer sehr geringen Änderungsrate. Daher können wir davon ausgehen, dass manuelle Methoden den Zeitrahmen für die Bereitstellung nicht wesentlich beeinflussen. Dies gilt umso mehr, wenn wir den Großteil der Application pro App automatisieren, weil dann den Bedienern und Ingenieuren mehr Zeit bleibt, um bei Bedarf manuelle Änderungen vorzunehmen.
Unter der Annahme, dass das Verhältnis von zentralen (gemeinsam genutzten) Diensten zu Application pro App etwa eins zu drei* beträgt, bedeutet dies, dass unsere durchschnittliche Organisation mindestens vier gemeinsam genutzte Ressourcen manuell verwalten und zwölf Ressourcen pro App automatisieren muss.
Bei der Betrachtung der umfangreichen Liste der Application ( aktuell verfolgen wir dreißig verschiedene Dienste ) stellen wir fest, dass einige davon für die Bereitstellung oder Sicherung einer App erforderlich sind (DDoS, WAF, Lastausgleich für Skalierung, App-Zugriff), während andere eher, sagen wir mal, Erweiterungen sind . Das wären etwa Application wie leistungssteigernde Beschleunigungsoptionen oder produktivitätssteigerndes Single-Sign-On (SSO).
Wenn wir also die Implementierung eines MVD in Betracht ziehen, wählen wir möglicherweise einen agilen Ansatz und konzentrieren uns auf die Application , die für die Bereitstellung vom ersten Tag an und die Sicherheit von entscheidender Bedeutung sind. Das heißt nicht, dass wir die Verbesserungen ignorieren, sondern nur, dass wir uns zunächst auf die entscheidenden konzentrieren und diese zuerst automatisieren. Wir können die Dienste, die die Produktivität oder Leistung verbessern, immer noch manuell verwalten, für einen MVD möchten wir uns jedoch auf Dienste konzentrieren, die sich auf den Gewinn auswirken.
Ein MVD-Ansatz für das Agile-Netzwerk
Wenn wir die Automatisierung mit der Absicht angehen, ein MVD zu definieren und bereitzustellen, kommen wir schneller voran (wir sind agiler) und haben die Möglichkeit, die Automatisierung zu iterieren, um sie mit jedem Sprint (gemessen in Wochen, nicht in Quartalen) zu verbessern und zu erweitern, bis wir ein solides, nachhaltiges Produkt haben (automatisierte Bereitstellung).
Die Einführung einer auf MVD basierenden Strategie zur Automatisierung erfordert nicht nur das Engagement für eine Architektur, sondern auch für einen Ansatz und eine Einstellung, die sich auf Applications konzentrieren. Der Grund hierfür ist, dass ein solcher Ansatz ein Verständnis der Application und ihrer Anforderungen sowohl aus betrieblicher als auch aus geschäftlicher Sicht erfordert. Der MVD einer App stimmt möglicherweise nicht mit dem MVD einer anderen überein. Dies ist einer der Gründe, warum die Pro-App-Architektur eine so wichtige Komponente beim Übergang von einem festen, manuellen Netzwerk zu einer agilen (automatisierten) Pipeline ist.
Es stellt sich also heraus, dass es eine minimal praktikable Bereitstellung für NetOps gibt. Das bedeutet, dass Sie bei der Netzwerkautomatisierung einen agilen Ansatz wählen können, der unendlich schneller (und sicherer) ist, wenn Sie im Rahmen Ihrer agilen Netzwerkinitiativen zu einer Pro-App-Architektur übergehen.
Automatisieren Sie (fast) alle Netzwerkfunktionen.
*das ist absolut ein SWAG, basierend auf der Liste, meiner Erfahrung und meiner (festen) Meinung. Ihre Laufleistung und Definition können abweichen.