Vernetzung im Zeitalter der Container

In den letzten Jahren hat sich durch Virtualisierung und nun auch Containerisierung die App-Dichte auf jeder beliebigen Hardware erhöht. Daher sind wir besessen davon, den Ost-West-Verkehr statt den Nord-Süd-Verkehr zu verwalten.

Für diejenigen, die sich noch nicht so gut mit den Datenverkehrsmustern in ihren Rechenzentren auskennen, fassen wir zusammen: Nord-Süd bedeutet Benutzer-zu-App, Client-zu-Server oder innerhalb und außerhalb des Rechenzentrums. Ost-West ist Server-zu-Server, App-zu-App, Service-zu-Service oder einfach innerhalb des Rechenzentrums.

Die Nord-Süd-Verkehrsmuster werden durch die zunehmende Anzahl an Benutzern, Apps und Dingen beeinflusst. Je mehr Benutzer-App-Verbindungen erforderlich sind, desto mehr Nord-Süd-Verkehr werden Sie feststellen. Der Ost-West-Verkehr wird durch Anwendungsarchitekturen und Infrastrukturtechnologie beeinflusst. Wenn Sie Technologien wie Virtualisierung und Container mit neuen Architekturen wie Microservices kombinieren, kommt es zu einem exponentiellen Anstieg der Anzahl von „Apps“ oder „Diensten“, die im gesamten Rechenzentrum miteinander kommunizieren müssen.

Grundsätzlich gilt : Je verteilter eine Anwendungsarchitektur und ihre Infrastruktur werden, desto mehr Ost-West-Verkehr wird es geben.

Dieser Anstieg wird durch den Trend zu „richtig dimensionierten“ Apps noch verstärkt. Anstatt auf Wachstumsprognosen zu basieren, basiert die Kapazitätsplanung auf dem aktuellen Bedarf plus etwas mehr. Dank ausgereifter Technologien wie der automatischen Skalierung können wir Ressourcen effizienter nutzen, so dass weniger Rechen- und Netzwerkressourcen ungenutzt bleiben und das Budget aufbrauchen, ohne einen entsprechenden Mehrwert zu schaffen . Dies ist übrigens einer der Vorteile der privaten Cloud: die Fähigkeit, Ressourcen, die sonst ungenutzt bleiben würden, besser zu nutzen, indem eine serviceorientierte Bereitstellung und Verwaltung bereitgestellt wird, die eine Echtzeitnutzung der Ressourcen ermöglicht.

Aber ich schweife ab. Der Punkt war, dass der Ost-West-Verkehr dank Architekturen und Technologien schneller zunimmt als der Nord-Süd-Verkehr.

Mittlerweile hat jede bedeutende Veränderung der Anwendungsarchitektur und -technologie in den letzten zwanzig Jahren zu einer entsprechenden Reaktion im „Netzwerk“ geführt. Der Grund hierfür ist, dass das Netzwerk für die Verwaltung des Datenverkehrs verantwortlich ist, unabhängig davon, in welche Richtung er fließt. Ost-West, Nord-Süd, spielt keine Rolle. Ob virtuell oder physisch: Durch Vernetzung wird sichergestellt, dass der Datenverkehr von seinem Ausgangspunkt dorthin gelangt, wo er hin soll.

Angesichts der noch stärkeren Zunahme des Ost-West-Verkehrs aufgrund der Zerlegung von Anwendungen durch Mikroservices stellt sich nun die Frage: Wie soll das Netzwerk reagieren? Genauer gesagt: Wie sollten die Dienste im Netzwerk reagieren, um die kritischen Funktionen (Verfügbarkeit, Sicherheit, Optimierung) bereitzustellen, die für die Bereitstellung von Apps für Benutzer oder zunehmend auch für andere Apps erforderlich sind?

AUSWIRKUNG EINS: WECHSEL ZUR APP 

Die erste Antwort auf diese Frage ist ganz klar, dass anwendungsaffine Dienste näher an die App heranrücken müssen . Sie können nicht dort draußen am Rand des Nord-Süd-Musters bleiben und Dienste für Apps bereitstellen, die sie hauptsächlich in einem Ost-West-Muster nutzen. Dies ist eine ineffiziente Nutzung der Netzwerkressourcen und die Auswirkung der Routing-Muster, die zu Latenzen bei der Anwendungskommunikation führen. An dieser Stelle hören wir erstmals Begriffe wie „Tromboning“ und „Haarnadelkurve“ in Bezug auf Verkehrsmuster, die eine Route durch das Netzwerk beschreiben, bei der man eine Maschine verlässt, das Netzwerk Richtung Norden durchquert und dann zu derselben Maschine zurückkehrt. Diese Latenz führt zu echten Geschäftskosten in Form von Produktivitätsverlusten („Haben Sie Geduld, mein Computer ist heute langsam“) und einer höheren Zahl von Kunden, die Einkaufswagen und Web-Apps verlassen. Das ist es, was wir vermeiden möchten. Wenn der Datenverkehr in Ost-West-Richtung verläuft, sollten sich die Dienste in diesem Datenpfad befinden.

AUSWIRKUNG ZWEI: BETRIEBSKOMPATIBILITÄT 

Die zweite Antwort ist, dass diese Dienste wie Lastausgleich und Web-App-Sicherheit in betriebskompatiblen Formaten bereitgestellt werden müssen. Mit anderen Worten: Wir werden nicht jeder App (oder jedem Mikrodienst), die auftaucht, Netzwerkhardware vor die Füße werfen. Daher müssen die Plattformen, auf denen diese Dienste bereitgestellt werden, virtualisiert oder in Containern gespeichert werden, um mit neuen Architekturen und Technologien betriebskompatibel zu sein. Sie müssen außerdem programmgesteuert sein und APIs und Vorlagen bereitstellen, die einen DevOps-orientierten Ansatz für Bereitstellung und Verwaltung ermöglichen. Dienste, ob Anwendung oder Netzwerk, müssen orchestrierbar sein. Wenn sich SDN in die Tools und Frameworks integrieren lässt, die die Infrastruktur- und Anwendungsbetriebsumgebungen dominieren, kann es auch diesen Bedarf decken. 

AUSWIRKUNG DREI: ARCHITEKTUR IST ENTSCHEIDEND

Die dritte Antwort ist, dass Architektur wichtiger wird als je zuvor. Nur weil man einen Netzwerkdienst auf demselben Host wie seine Anwendung bereitstellen kann, heißt das nicht unbedingt, dass er dort bereitgestellt werden sollte. Je nachdem, um was für einen Dienst es sich handelt und wie die Interaktion mit anderen Diensten (und Dienstinstanzen) aussehen wird, wird die Platzierung zu einem ernsthaften, zu berücksichtigenden Thema. Eine schlecht konzipierte Lastverteilung kann beispielsweise zu beunruhigenden Datenverkehrsmustern führen, die unnötige Latenzen verursachen. Diese Latenzzeiten wirken sich unmittelbar auf den Geschäftsgewinn – oder -verlust – aus. Jeder Fehler (Hardware, Software, Netzwerk, Speicher) in diesem Szenario auf dem Host, auf dem die Dienste bereitgestellt werden, führt zu Ausfallzeiten (und zwar zu hässlichen Ausfallzeiten), weil die Dienste, die für die Verfügbarkeit der Apps verantwortlich sind, ebenfalls ausfallen. In einer stark zerlegten Anwendungsarchitektur (Microservices) könnte dies verheerende Folgen haben, wenn die Abhängigkeiten von diesen Apps hoch sind.

Es bedarf sorgfältiger Überlegungen (Architektur), um sicherzustellen, dass Best Practices hinsichtlich Leistung und Verfügbarkeit nicht aus der Versuchung heraus, die naheliegendste (und einfachste) Antwort zu finden, ignoriert werden.

NETZWERKE BLEIBEN EINE ARCHITEKTURÜBUNG

Die Vernetzung ist und bleibt eine architektonische Aufgabe. Dabei geht es nicht nur um Formfaktoren, sondern lediglich um eine Möglichkeit, Netzwerkressourcen schneller und effizienter dorthin zu bringen, wo Sie sie benötigen. Es geht um die Platzierung dieser Ressourcen und darum, wie sie sich auf alles weiter oben im Stack auswirkt: die Netzwerkdienste, die App-Dienste, die App-Leistung und letztlich den Geschäftserfolg – oder Misserfolg.

Im Zeitalter von Containern, Virtualisierung und Clouds geht es bei der Vernetzung sowohl um Architektur als auch um Betrieb.