Die Anziehungskraft von Apps spaltet das Netzwerk

Lori Mac VittieDistinguished Engineer und Chief Evangelist | F5

Das Netzwerk verzweigt sich. Teilt sich auf. Verteilt sich. Sie können jeden beliebigen Begriff verwenden, um das Phänomen zu beschreiben, dass Netzwerkdienste aus dem ruhigen Vorort des Unternehmensnetzwerks in die geschäftigen und lauten Stadtviertel auf der Anwendungsseite des Rechenzentrumsnetzwerks umziehen. Die Terminologie steht heute jedoch nicht im Mittelpunkt; vielmehr wollen wir darüber nachdenken, warum dies geschieht.

Manche mögen sagen: „Nun, Lori, es ist doch offensichtlich, dass das Unternehmensnetzwerk sehr stark auf Hardware basiert, und Hardware bietet einfach nicht die Flexibilität und Agilität, die nötig sind, um in die modernere, agile Umgebung von Entwicklung und Betrieb zu passen.“

Nun, nein. Es geht weniger um Hardware oder Software denn letztlich braucht man immer Hardware, ganz gleich, was man tut (Ressourcen wie RAM, Rechenleistung und Netzwerkzugang entstehen schließlich nicht aus dem Nichts). Vielmehr geht es um die Betriebskultur und die Gegebenheiten, die in den beiden Netzwerken herrschen und dazu führen, dass einige Dienste von der einen auf die andere Seite verlagert werden.

Tatsächlich würde ich sagen, dass Anwendungen inzwischen den Schwerpunkt bilden und alle anwendungsnahen Dienste anziehen – ähnlich wie der Mond von der Erde angezogen wird.

Tatsache ist, dass anwendungsnahe Dienste – wie Lastverteilung, Caching, Beschleunigung und Webanwendungssicherheit – jeweils sehr spezifisch auf eine bestimmte Anwendung zugeschnitten sind. Bei diesen Diensten gibt es keine Universallösung. Im Gegenteil: Es handelt sich um hochgradig spezialisierte, anwendungszentrierte Dienste, deren Richtlinien darauf ausgelegt sind, EINE Anwendung bereitzustellen, abzusichern und zu optimieren.

Nicht alle. Nicht einmal alle derselben Art. Nur eine. Die eine dort drüben.

Das unterscheidet sich deutlich von beispielsweise einer Netzwerk-Firewall oder einem IPS/IDS, deren Funktionsweise nicht wirklich auf eine bestimmte Anwendung zugeschnitten ist. Webanwendungen laufen über Port 80, also öffnet man diesen und erlaubt den Zugriff durch die Firewall. Abgesehen davon, dass sie dasselbe Protokoll (HTTP) verwenden und über denselben Port laufen, gibt es dabei kaum eine anwendungsspezifische Ausrichtung.

Umgekehrt ist die Festlegung einer Sicherheitsrichtlinie, die vorgibt, welche Art von Daten (Zeichenfolge? Ganzzahl? alphanumerisch?) und welche Datenmenge (15 Zeichen? 12? 100?) einem einzelnen Eingabefeld (Benutzername? E-Mail-Adresse? Kommentar?) zugeordnet werden darf, das wiederum mit einem bestimmten URI (/login.x) verknüpft ist, ausgesprochen anwendungsspezifisch. Gleiches gilt für Richtlinien zur Minimierung und Zusammenführung von Stylesheets sowie für die Überwachung des Zustands einer Anwendung im Load-Balancing-Dienst.

Warum Affinität wichtig ist

Ein durchschnittliches Unternehmen verwaltet heute Schätzungen zufolge etwa 508 Anwendungen. Unseren Untersuchungen zufolge verfügen 31 % der Unternehmen tatsächlich über 500 oder mehr Anwendungen. Doch auch darum geht es nicht – diese Zahl dient lediglich als Ausgangswert. Und zwar deshalb, weil sehr viele Unternehmen planen, noch wesentlich mehr Anwendungen zu entwickeln. Hinzu kommen Unternehmen, die eine Microservices-Architektur einführen. Bei ihnen ändert sich nicht unbedingt die Anzahl der Anwendungen, wohl aber die Anzahl der „Systeme“, wenn man so will, die die zuvor erwähnten anwendungsspezifischen Dienste benötigen werden.

Stellen Sie sich also einmal vor, ein Unternehmen möchte die Anzahl der verwalteten Anwendungen verdoppeln. Nehmen wir an, es hat mit 500 angefangen und plötzlich sind es 1.000. Jede einzelne Richtlinie muss bereitgestellt, konfiguriert und verwaltet werden. Nehmen wir der Einfachheit halber an, jede Anwendung benötigt nur zwei Richtlinien – eine für die Skalierung und eine für die Sicherheit. Damit müssen Sie sich um 2.000 Richtlinien kümmern. Bereit? Los geht’s.

Ja. Das Problem besteht nicht darin, dass die „Hardware“ im Unternehmensnetzwerk das nicht bewältigen könnte. Im Gegenteil: Sie kann es gerade deshalb, weil sie speziell dafür entwickelte Hardware ist und somit über weitaus mehr Kapazität verfügt als ein Universalserver. Das Problem sind die Prozesse und der Personalaufwand, die für all das erforderlich sind. Es geht nicht nur um die Anzahl der benötigten Geräte, sondern auch um die Anzahl der individuellen, an die jeweilige Anwendung gebundenen Richtlinien, die bereitgestellt werden müssen.

Und nicht nur bereitgestellt, sondern auch aktualisiert. Da anwendungsspezifische Richtlinien eigens für eine bestimmte Anwendung konfiguriert werden, ist die Wahrscheinlichkeit höher, dass bei einem Upgrade der Anwendung oder der Einführung eines Fixes auch die zugehörigen Richtlinien für Anwendungsdienste aktualisiert werden müssen. Und da Unternehmen immer häufiger neue Versionen bereitstellen möchten, kann man sich gut vorstellen, dass die für das Unternehmensnetzwerk zuständigen Teams völlig überlastet wären.

Auf der anderen Seite, im Anwendungsnetzwerk, stehen Entwicklung und Betrieb in den Startlöchern. Sie wollen Anwendungen bereitstellen und in Betrieb nehmen. Und sie sind bereit, ihre neuen Kompetenzen in den Bereichen Automatisierung und Orchestrierung einzusetzen, um diesen Prozess zu beschleunigen.

Und genau das tun sie, indem sie die Verantwortung für immer mehr anwendungsnahe Dienste übernehmen und diese in ihre Bereitstellungsarchitekturen und -prozesse integrieren. Mit dem wachsenden Bewusstsein für DevOps und einigen Impulsen aus der Branche durch SDN sind nahezu alle Netzwerkdienste mit APIs ausgestattet. Viele weitere verfügen über Vorlagen, die perfekt auf die Anforderungen von Betreibern zugeschnitten sind, die bei der Verwaltung und Bereitstellung der zur Unterstützung von Anwendungen erforderlichen Infrastruktur einen „Infrastructure as Code“-Ansatz verfolgen.

Aus diesem Grund tauchen immer mehr „Anwendungsdienste“ im Anwendungsnetzwerk auf und verlagern den Schwerpunkt der Unternehmens-IT hin zur Anwendung.

Es ist eine Strategie zur geschäftlichen und operativen Skalierung. Sie bietet eine Möglichkeit, das rasante Wachstum des Anwendungsportfolios zu bewältigen, ohne gegen Brooks’ Gesetz zu verstoßen, indem man das Problem einfach mit mehr Personal für Netzwerk oder Anwendungen zu lösen versucht. So kann die IT Anwendungen schneller und häufiger auf den Markt bringen, ohne die Störungen, die entstehen würden, wenn Netzwerkadministratoren plötzlich zwei-, drei- oder noch mehrmal so viele Richtlinien wie bisher verwalten müssten.

Ü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