Wie sich das Netzwerk an veränderte App-Architekturen anpasst

Um Microservices gibt es derzeit eine Menge Aufregung. Sie sind der letzte Schrei in der Anwendungsarchitektur und werden oft im Zusammenhang mit ihrem besten Freund, den Containern, erwähnt. Eine kürzlich von InfoQ durchgeführte Umfrage ergab, dass beide Services weit oben auf der Liste derjenigen stehen, die sie verwenden oder deren Verwendung sie planen. Container (71,79 % der Befragten) schlugen dabei knapp Microservices (70,4 %). Interessanterweise ergab die gleiche Untersuchung, dass heute häufiger Microservices (32,21 %) als Container (29,44 %) verwendet werden.

Ungeachtet dessen scheint es unbestreitbar, dass Microservices und Container Technologien sind, die die meisten Organisationen auf dem Radar haben.

Wie bei jeder bedeutenden Änderung der Anwendungsarchitektur kommt es jedoch auch zu einer vergleichbaren Änderung im Netzwerk, da die App-Dienste und Netzwerkfunktionen angepasst werden, um die Anforderungen dieser neuen Anwendungsarchitekturen zu erfüllen. Dies liegt teilweise an der Tatsache, dass Änderungen – insbesondere radikale – in Anwendungsarchitekturen die Netzwerkmuster verändern und oft von neuen Sprachen, Webplattformen und den daraus resultierenden Herausforderungen im Bereich der Sicherheit begleitet werden.

So brachte beispielsweise die Umstellung von der Client-Server-Architektur auf die (heute) traditionelle dreischichtige Webanwendung nicht nur eine weitere Schicht in der Anwendungsarchitektur mit sich, sondern auch eine ergänzende Infrastrukturschicht, die die Skalierbarkeit und Leistung bieten soll, die von Apps im aufkeimenden Internetzeitalter benötigt werden. Sie erinnern sich vielleicht an das plötzliche Wachstum von XML-Gateways, XML-Sicherheits-Gateways, XML-Firewalls und anderen verwandten „Netzwerk“-Geräten, die sich ausschließlich auf die Bewältigung der Herausforderungen konzentrierten, die sich aus der (damals) neuen App-Architektur SOA ergaben.

Als sich dann die Bedeutung von Cloud und Mobilgeräten bemerkbar machte, rückte die Sicherheit in den Vordergrund und es entstand eine Flut neuer Netzwerksicherheitslösungen. Der Schwerpunkt lag dabei auf der Verwaltung und Sicherung mobiler Geräte, einschließlich der Netzwerke, in denen diese Geräte agierten, sowie auf Sicherheitsbrokern für den Cloud-Zugriff. Hier kam es zu einer subtilen Verschiebung des „Netzwerks“, die noch immer spürbar ist: die Ausweitung des „Netzwerks“, das praktisch auch das Internet einschließt. Auf die zunehmende Verbreitung von Anwendungen auf mehrere Umgebungen wird das Netzwerk zweifellos mit einer weiteren Migration traditionell LAN-gebundener Dienste (vor allem im Bereich Sicherheit) in das Internet „als Dienst“ reagieren.

Heute erleben wir in Anwendungsarchitekturen den Aufstieg von Microservices und APIs, vor allem RESTful-APIs. Gleichzeitig erfordern das Internet der Dinge und das explosionsartige Wachstum von Anwendungen und menschlichen Benutzern weiterhin Skalierungsmaßnahmen. Allerdings liegt der Schwerpunkt dieser Skalierung heute auf dem Betrieb.

Das Ergebnis ist, dass das Netzwerk darauf reagieren muss (und dies in vielen Fällen auch tut), indem es versucht, eine architektonische Kompatibilität mit den Anwendungen (Diensten) zu erreichen, deren Skalierung, Sicherung und Optimierung es vorsieht. Das bedeutet, dass wir virtuelle und containerisierte Formfaktoren übernehmen müssen – einschließlich der Cloud – und den Schwerpunkt auf Orchestrierung und Automatisierung legen. Das Ziel besteht heute in Vorlagen, APIs und der Fähigkeit zur Integration mit Frameworks und Tool-Sets, die letztendlich die Bereitstellung von Anwendungen für die Produktion vorantreiben.

Das „Netzwerk“ reagiert. APIs gibt es in Hülle und Fülle. Vorlagen und Unterstützung für andere Vorlagensysteme (kennt jemand OpenStack Heat und AWS Cloud Formation-Vorlagen?) werden alltäglich, ebenso wie die Unterstützung für die Behandlung der App-Bereitstellungsinfrastruktur „als Code“.

Diese Anpassung unterscheidet sich von herkömmlichen Anpassungen im Netzwerk, bei denen es vor allem auf die Geschwindigkeit und Paketzustellung ankommt. Bei dieser neuesten Anpassung geht es um die Bereitstellungsgeschwindigkeit und die Fähigkeiten von APIs als Feeds im Netzwerk. Der Schwerpunkt liegt auf der Realisierung der Architekturkompatibilität mit der Anwendungsarchitektur, unabhängig davon, ob diese in einer öffentlichen oder privaten (lokalen) Cloud, als einzelne, monolithische Anwendung oder als entkoppelter Satz von Hunderten von Mikroservices bereitgestellt wird.

Machen Sie sich nichts vor: Die Vernetzung wird durch Änderungen in der Anwendungsarchitektur beeinflusst – und sogar vorangetrieben. Zwischen beiden besteht eine symbiotische Beziehung, die nicht ignoriert werden kann, insbesondere da wir uns in einem Zeitalter befinden, in dem der Fokus auf dem operativen Betrieb liegt und Koordination und Kooperation für Unternehmen von entscheidender Bedeutung sind, um die Anwendungen bereitzustellen, auf die sie sich heute verlassen, um erfolgreich zu sein und zu wachsen.