Ist Netzwerkautomatisierung wirklich eine Alles-oder-nichts-Entscheidung?
Netzwerkautomatisierung – also die Anwendung von DevOps-Prinzipien auf die Produktionspipeline – wird bereits von einem erheblichen Anteil der Unternehmen eingesetzt. Zwar nutzen sie nur sehr wenige Unternehmen in vollem Umfang, doch die Mehrheit (77 % laut unserem aktuellen Bericht „State of Application Delivery“) erprobt Automatisierung entweder in Pilotprojekten oder setzt sie teilweise in der Produktion ein.
Eines der eng mit DevOps – und damit häufig auch mit NetOps – verbundenen Konzepte ist das sogenannte Minimum Viable Product (MVP).
Es ist Teil der agilen Methodik und dient dazu, Entwicklungszyklen zu beschleunigen und Lösungen schneller auf den Markt zu bringen. Genau das brauchen wir im Netzwerk dringend. Vielleicht erinnern Sie sich an die in einem früheren Blogbeitrag erwähnte Appian-Umfrage, die uns mit dem Forschungsergebnis konfrontierte, dass 72 % der Befragten nicht darauf vertrauten, dass die IT entsprechend den Anforderungen des Unternehmens skalieren kann.
Autsch. Trotz des recht umfassenden Einsatzes von Automatisierung in der IT fehlt Entwicklern und Stakeholdern aus den Fachbereichen nach wie vor das Vertrauen in unsere Fähigkeit, die Sache zu stemmen.
Es ist also gar nicht so abwegig, Tools, Technologien und Methoden aus dem DevOps-Bereich zu übernehmen, um die Abläufe zu beschleunigen (indem intelligenter skaliert wird). Doch bevor wir herausfinden können, wie sich MVP auf das Netzwerk anwenden lässt, müssen wir zunächst verstehen, was es überhaupt ist. Für alle, die mit DevOps, Agile oder MVP nicht vertraut sind, folgt hier eine verständliche Definition der Agile Alliance:
Ein Minimum Viable Product (MVP) ist ein Konzept aus dem Lean-Startup-Ansatz, das die Bedeutung des Lernens bei der Entwicklung neuer Produkte hervorhebt. Eric Ries definierte ein MVP als diejenige Version eines neuen Produkts, die es einem Team ermöglicht, mit dem geringstmöglichen Aufwand ein Höchstmaß an validierten Erkenntnissen über Kunden zu gewinnen. Diese validierten Erkenntnisse zeigen, ob Ihre Kunden Ihr Produkt tatsächlich kaufen werden.
Eine zentrale Prämisse des MVP-Konzepts besteht darin, ein echtes Produkt zu entwickeln (bei dem es sich lediglich um eine Landingpage oder um eine Dienstleistung handeln kann, die automatisiert erscheint, hinter den Kulissen jedoch vollständig manuell erbracht wird), das Sie Kunden anbieten können, um deren tatsächliches Verhalten im Umgang mit dem Produkt oder der Dienstleistung zu beobachten. Zu sehen, wie Menschen tatsächlich mit einem Produkt umgehen, ist wesentlich aussagekräftiger, als sie danach zu fragen, wie sie sich verhalten würden.
Ein Team setzt ein MVP effektiv als Kernelement einer experimentellen Strategie ein. Es stellt die Hypothese auf, dass seine Kunden einen Bedarf haben und dass das Produkt, an dem das Team arbeitet, diesen Bedarf deckt. Anschließend stellt das Team diesen Kunden etwas zur Verfügung, um herauszufinden, ob sie das Produkt tatsächlich nutzen, um ihren Bedarf zu decken. Auf Grundlage der aus diesem Experiment gewonnenen Erkenntnisse setzt das Team die Arbeit am Produkt fort, ändert es oder stellt die Arbeit daran ein.
An dieser Stelle dieser Abhandlung möchte ich darauf hinweisen, dass sich viele der mit DevOps (und den damit verbundenen Technologien und Methoden) verknüpften Konzepte nicht immer ohne Weiteres auf eine NetOps-Initiative übertragen lassen. „Experimentieren“ ist kein Begriff, den IT-Ingenieure, -Architekten oder -Führungskräfte verwenden, wenn sie über Änderungen am Netzwerk sprechen.
Der Auswirkungsradius ist nämlich groß und schwer zu beherrschen. Die meisten Unternehmen haben aus gutem Grund nur eine geringe Toleranz gegenüber betrieblichen Risiken. Ausfälle kosten bares Geld – und manchmal auch Arbeitsplätze. Das Netzwerk ist daher nicht wirklich ein geeigneter Ort für Experimente.
Das bedeutet jedoch nicht, dass es für NetOps keine minimal funktionsfähige Bereitstellung (Minimal Viable Deployment, MVD) gibt.
Definition eines MVD für NetOps
Die heutige Produktionspipeline umfasst sowohl gemeinsam genutzte Ressourcen wie Switches, Router, DNS und Multi-Cloud-Routing (GSLB) als auch anwendungsspezifische Dienste wie Load Balancer, WAF und Zugriffskontrollen für Anwendungen.
Interessanterweise stellen wir bei der Betrachtung der Änderungshäufigkeit gemeinsam genutzter Ressourcen fest, dass diese recht gering ist. Das heißt, sie ändern sich nur selten. Das ist gut, denn sie sind auch wenig tolerant gegenüber Störungen. Bei anwendungsspezifischen Ressourcen hingegen ist die Änderungshäufigkeit höher, ebenso wie die Toleranz gegenüber Störungen.
Das ist schließlich einer der Vorteile einer anwendungsspezifischen Architektur: Die Isolierung des Datenpfads schützt andere Anwendungen vor Beeinträchtigungen, wenn etwas schiefläuft.
Entlang dieses Datenpfads befinden sich durchschnittlich sechzehn verschiedene Anwendungsdienste, die Unternehmen unseren Untersuchungen zufolge zur Bereitstellung und Absicherung ihrer Anwendungen nutzen. Einige davon – etwa eine Netzwerk-Firewall und DNS – sind gemeinsam genutzte Ressourcen. Andere sind es nicht oder müssen es zumindest nicht zwangsläufig sein. Sie werden heute vielleicht auf einer gemeinsam genutzten Plattform bereitgestellt, könnten aber bei Vorliegen eines guten Grundes mit einem eigenen Datenpfad konzipiert werden.
Und genau das werde ich Ihnen natürlich geben.
Der gute Grund ist, dass Sie effektiv ein MVD für eine Anwendung entwickeln können, wenn Sie für diejenigen Anwendungsdienste, die ohnehin eng mit der Anwendung gekoppelt sind, eine anwendungsspezifische Architektur einsetzen.
Wie unsere Definition eines MVP zeigt, muss das „Produkt“ (in unserem Fall die Bereitstellung einer App) nicht vollständig automatisiert sein. Wenn wir davon ausgehen, dass die risikoreichsten und am wenigsten fehlertoleranten Ressourcen weiterhin manuell konfiguriert (und überprüft) werden müssen, kommen wir dennoch voran. Firewalls und zentrale Dienste wie DNS ändern sich nur sehr selten. Daher können wir davon ausgehen, dass manuelle Verfahren den Zeitplan für die Bereitstellung nicht wesentlich beeinträchtigen werden. Das gilt umso mehr, wenn wir den Großteil der anwendungsspezifischen Dienste automatisieren, denn dadurch gewinnen Betreiber und Techniker Zeit, um bei Bedarf die manuellen Änderungen vorzunehmen.
Unter der Annahme, dass das Verhältnis von zentralen (gemeinsam genutzten) Diensten zu anwendungsspezifischen Diensten etwa eins zu drei* beträgt, muss eine durchschnittliche Organisation mindestens vier gemeinsam genutzte Ressourcen manuell verwalten und zwölf anwendungsspezifische Ressourcen automatisieren.
Wenn wir uns die umfangreiche Liste der Anwendungsdienste ansehen (derzeit erfassen wir dreißig verschiedene Dienste) stellen wir fest, dass einige davon notwendig sind, um eine Anwendung bereitzustellen oder abzusichern (DDoS, WAF, Lastverteilung zur Skalierung, Anwendungszugriff), während andere eher, sagen wir einmal, Optimierungen darstellen. Dazu gehören Anwendungsdienste wie Beschleunigungsoptionen zur Leistungssteigerung oder produktivitätssteigerndes Single Sign-on (SSO).
Wenn wir also die Implementierung eines MVD in Betracht ziehen, könnten wir einen agilen Ansatz verfolgen und uns auf die Anwendungsdienste konzentrieren, die vom ersten Tag an für die Bereitstellung und Sicherheit entscheidend sind. Das bedeutet nicht, dass wir die Optimierungen außer Acht lassen. Es bedeutet lediglich, dass wir uns zunächst auf die kritischen Dienste konzentrieren und diese zuerst automatisieren. Dienste, die die Produktivität oder Leistung verbessern, können wir weiterhin manuell verwalten. Bei einem MVD wollen wir uns jedoch auf die Dienste konzentrieren, die sich auf den Gewinn auswirken.
Ein MVD-Ansatz für das agile Netzwerk
Wenn wir die Automatisierung mit dem Ziel angehen, ein MVD zu definieren und bereitzustellen, kommen wir schneller voran (wir sind agiler) und haben die Möglichkeit, die Automatisierung iterativ zu verbessern und mit jedem Sprint (gemessen in Wochen, nicht in Quartalen) zu erweitern, bis wir über ein solides, nachhaltiges Produkt verfügen (automatisierte Bereitstellung).
Die Einführung einer MVD-basierten Automatisierungsstrategie erfordert nicht nur ein klares Bekenntnis zu einer bestimmten Architektur, sondern auch zu einem Ansatz und einer Haltung, bei denen die Anwendungen im Mittelpunkt stehen. Denn ein solcher Ansatz setzt voraus, dass man die Anwendung und ihre Anforderungen sowohl aus betrieblicher als auch aus geschäftlicher Sicht versteht. Das MVD für eine Anwendung muss nicht mit dem MVD für eine andere übereinstimmen. Dies ist einer der Gründe, warum eine anwendungsspezifische Architektur beim Übergang von einem statischen, manuellen Netzwerk zu einer agilen (automatisierten) Pipeline eine so entscheidende Rolle spielt.
Es zeigt sich also, dass es für NetOps eine minimal funktionsfähige Bereitstellung gibt. Das bedeutet, dass Sie bei der Netzwerkautomatisierung einen agilen Ansatz verfolgen können – einen Ansatz, der unendlich viel schneller (und sicherer) ist, wenn Sie im Rahmen Ihrer Initiativen für ein agiles Netzwerk auf eine anwendungsspezifische Architektur umstellen.
Automatisieren Sie (fast) alles im Netzwerk.
*Das ist lediglich eine grobe Schätzung, die auf der Liste, meiner Erfahrung und meiner (ausgeprägten) Meinung beruht. Ihre Erfahrungen und Ihre Definition können davon abweichen.
Über den Autor
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Ähnliche Blogbeiträge
F5 und Equinix bündeln ihre Kräfte, um die sichere Anwendungsbereitstellung in Multicloud-Umgebungen zu vereinfachen
F5 und Equinix ermöglichen es Unternehmen, sich weltweit sicher und zuverlässig mit ihren Partnern zu vernetzen.
API-Sicherheitsrisiken und -herausforderungen
Erfahren Sie, warum APIs für die moderne App-Entwicklung unverzichtbar sind und wie Sie sie vor den häufigsten Sicherheitslücken schützen. Profitieren Sie von Expertentipps und direkt umsetzbaren Strategien.
Ein Meilenstein für die Community Impact Grants von F5
F5 feiert das fünfjährige Bestehen seines innovativen Community Impact Grant-Programms, das gemeinnützige Organisationen, bei denen sich F5-Mitarbeitende ehrenamtlich engagieren, mit Fördermitteln in Höhe von 5.000 US-Dollar unterstützt.
Mit moderner, anpassungsfähiger und sicherer Gesundheits-IT Leben retten
Die IT-Investitionen im Gesundheitswesen tragen dazu bei, die schnellsten Wege zu einer besseren Versorgung zu finden, indem sie die medizinische Betreuung näher an die Patientinnen und Patienten bringen. Viele Gesundheitsunternehmen nutzen riesige Mengen an klinischen und anderen Gesundheitsdaten, um Entwicklungen zu verfolgen und übergreifende Trends in der gesamten Gesundheitslandschaft zu erkennen. Gleichzeitig nähern sie sich einer möglichst präzisen, individuell zugeschnittenen Versorgung an.
Verbesserung der Benutzer- und Administrationserfahrung durch sicheren hybriden Zugriff
Diese Kombination aus BIG-IP Access Policy Manager und Azure Active Directory ermöglicht Identitätsföderation, zentralisierten Benutzerzugriff (über Single Sign-on) und erhöhte Anwendungssicherheit (durch Multi-Faktor-Authentifizierung) für geschäftskritische Anwendungen sowie cloudbasierte und SaaS-Anwendungen. Dieser Ansatz vereinfacht die Einrichtung und Bereitstellung, reduziert den Verwaltungsaufwand und verbessert die gesamte Administration.
Das Internet der Sicherheitsdinge
Nein, das ist keine Tirade über die Sicherheit des IoT. Es ist eine Geschichte über Veränderung – genauer gesagt über Veränderung und ihre Auswirkungen auf die Sicherheit. Veränderung ist allgegenwärtig. Es gibt unzählige Axiome und Sprichwörter über Veränderung, also ist es ...