Die Anziehungskraft von Apps führt zu einer Aufspaltung des Netzwerks
Das Netzwerk verzweigt sich. Aufzweigung. Zerstreuen. Sie können gerne jeden beliebigen Begriff verwenden, um das Phänomen der Verlagerung von Netzwerkdiensten aus dem ruhigen Vorort, dem Unternehmensnetzwerk, in hektische und laute Stadtviertel auf der Anwendungsseite des Rechenzentrumsnetzwerks zu beschreiben. Es geht in der heutigen Diskussion nicht um die Terminologie, sondern wir werden heute über die Gründe nachdenken, warum dies geschieht.
Manche sagen vielleicht: „Also, Lori, es ist offensichtlich, dass das Unternehmensnetzwerk sehr stark auf Hardware basiert und Hardware einfach nicht die Flexibilität und Agilität bietet, die erforderlich ist, um in die angesagtere, agilere Umgebung in Entwicklung und Betrieb zu passen.“
Nein, nein. Es geht nicht so sehr um Hardware oder Software , denn eigentlich brauchen Sie Hardware, egal was Sie tun (Ressourcen wie RAM, Rechenleistung und Netzwerkzugriff fallen ja nicht einfach vom Himmel). Es geht eher um die Betriebskultur und die Realitäten, die in den beiden Netzwerken herrschen und die dafür sorgen, dass einige Dienste von einer Seite auf die andere verlagert werden.
Ich würde sogar sagen, dass es tatsächlich so ist, dass die Anwendungen mittlerweile im Mittelpunkt stehen und alle anwendungsaffinen Dienste anziehen, ähnlich wie die Erde den Mond anzieht.
Der Punkt ist, dass anwendungsaffine Dienste – wie Lastausgleich, Caching, Beschleunigung und Web-App-Sicherheit – alle sehr spezifisch für eine bestimmte Anwendung sind. Dabei handelt es sich nicht um Dienste, die für alle gleich sind. Im Gegenteil, es handelt sich hierbei um hochgradig fokussierte, anwendungszentrierte Dienste, deren Richtlinien darauf ausgerichtet sind, EINE Anwendung bereitzustellen, zu sichern und zu optimieren.
Nicht alle. Nicht einmal alle von der gleichen Art. Nur eine. Das da drüben.
Dies unterscheidet sich deutlich von beispielsweise einer Netzwerk-Firewall oder einem IPS/IDS, deren Funktionsweise nicht wirklich anwendungsspezifisch ist. Web-Apps laufen über Port 80, öffnen Sie diesen also und erlauben Sie den Zugriff durch die Firewall. Es gibt kaum „anwendungsspezifische“ Aspekte, außer dass sie dasselbe Protokoll (HTTP) verwenden und auf demselben Port ausgeführt werden.
Umgekehrt ist es wichtig, eine Sicherheitsrichtlinie festzulegen, die vorschreibt, welche Art von Daten (Zeichenfolge? Ganzzahl? Alphanumerisch?) und wie viele Daten (15 Zeichen?) 12? 100?) mit einem einzelnen Eingabefeld (Benutzername? E-Mail? Kommentar?) verknüpft werden kann, das mit einer einzelnen URI (/login.x) verknüpft ist, ist verdammt anwendungsspezifisch. Dies gilt auch für Richtlinien, die die Minimierung und Verkettung von Stylesheets sowie die Integritätsüberwachung einer Anwendung im Lastausgleichsdienst regeln.
Warum Affinität wichtig ist
Mittlerweile verwaltet ein durchschnittliches Unternehmen etwa 508 Anwendungen. Laut unserer Untersuchung verfügen 31 % der Organisationen tatsächlich über 500 oder mehr, aber darum geht es auch nicht, sondern es handelt sich lediglich um einen Basiswert. Und es ist eine Grundlage, da eine ganze Reihe von Organisationen planen, noch viel mehr Anwendungen zu entwickeln. Und dann gibt es noch die Organisationen, die eine Microservices-Architektur einführen, wodurch sich nicht unbedingt die Anzahl der Anwendungen ändert, sondern die Anzahl der „Systeme“, die die oben genannten anwendungsaffinen Dienste benötigen.
Also. Stellen Sie sich vor, eine Organisation möchte die Anzahl der verwalteten Anwendungen verdoppeln. Nehmen wir an, sie haben mit 500 angefangen und jetzt werden es plötzlich 1.000 sein. Sie müssen jede einzelne Richtlinie bereitstellen, konfigurieren und verwalten. Nehmen wir an, jede App benötigt nur zwei – einen für die Skalierung und einen für die Sicherheit –, um die Rechnung schön und einfach zu machen. Das sind 2.000 Policen, mit denen Sie sich befassen müssen. Bereit? Gehen.
Ja. Das Problem ist nicht, dass die „Hardware“ im Unternehmensnetzwerk das nicht bewältigen kann. Im Gegenteil, dies ist möglich, weil es sich um speziell entwickelte Hardware handelt und diese somit über Kapazitäten verfügt, die weit über die eines Allzweckservers hinausgehen. Das Problem sind die Prozesse und der Personalaufwand, die zur Erledigung all dieser Aufgaben erforderlich sind. Es geht nicht nur um die Anzahl der benötigten Geräte, sondern auch um die Anzahl der einzigartigen (anwendungsaffinen) Richtlinien, die bereitgestellt werden müssen.
Und nicht nur bereitgestellt, sondern aktualisiert. Da anwendungsaffine Richtlinien speziell für eine Anwendung konfiguriert werden, besteht eine größere Wahrscheinlichkeit, dass beim Upgrade einer App oder der Einführung eines Fixes auch die zugehörigen App-Dienstrichtlinien aktualisiert werden müssen. Und da die Organisationen immer häufiger Bereitstellungen durchführen möchten, können Sie sich vorstellen, dass die Leute im Unternehmensnetzwerk völlig überfordert wären.
Auf der anderen Seite des Zauns, im App-Netzwerk, sind Entwicklung und Betrieb hungrig. Begierig darauf, Apps auszuliefern und bereitzustellen. Sie sind bereit, ihre neuen Fähigkeiten in der Automatisierung und Orchestrierung einzusetzen, um diesen Prozess zu beschleunigen.
Und das tun sie, indem sie die Verantwortung für immer mehr anwendungsaffine Dienste übernehmen und diese in ihre Bereitstellungsarchitekturen und -prozesse integrieren. Mit zunehmendem Bewusstsein für DevOps und einer gewissen Förderung durch die Branche durch SDN werden Netzwerkdienste fast alle durch APIs unterstützt. Viele andere werden mit Vorlagen ausgestattet, die wie angegossen in die Hände von Betreibern passen, die einen „Infrastruktur als Code“-Ansatz zur Verwaltung und Bereitstellung der zur Unterstützung der Anwendungen erforderlichen Infrastruktur verwenden.
Aus diesem Grund tauchen im Anwendungsnetzwerk immer mehr „Anwendungsdienste“ auf und verschieben den Schwerpunkt der Unternehmens-IT in Richtung der Anwendung.
Es handelt sich um eine geschäftliche und betriebliche Skalierungsstrategie. Auf diese Weise kann man mit dem schnellen Wachstum des Anwendungsportfolios umgehen, ohne gegen Brooks' Gesetz zu verstoßen und das Problem durch den Einsatz von mehr Netzwerk- oder Anwendungspersonal zu lösen. Auf diese Weise kann die IT Anwendungen schneller und häufiger auf den Markt bringen, ohne dass es zu Störungen kommt, die dadurch entstehen, dass Netzwerkbetreiber plötzlich zwei-, dreimal oder sogar noch mehr Richtlinien verwalten müssen als jetzt.