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.

Zu diesem Anstieg kommt der Trend hinzu, Apps „richtig zu dimensionieren“. Anstatt die Kapazitätsplanung auf Wachstumsprognosen zu stützen, bemisst sie sich nach dem aktuellen Bedarf plus einem Sicherheitspuffer. Dank ausgereifter Technologien wie der automatischen Skalierung nutzen wir Ressourcen deutlich effizienter, sodass weniger Rechen- und Netzwerkressourcen ungenutzt bleiben und Budget verbrauchen, ohne entsprechenden Wert zu schaffen. Das ist übrigens einer der Vorteile der privaten Cloud: Sie erlaubt es, Ressourcen, die sonst brachliegen würden, besser zu nutzen, indem sie serviceorientierte Bereitstellung und Verwaltung bietet, die eine Nutzung der Ressourcen in Echtzeit 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 klare Antwort auf diese Frage lautet: Anwendungsnahe Dienste müssen näher an die Anwendung rücken. Sie dürfen nicht am Rand des Nord-Süd-Musters verbleiben und Dienste für Anwendungen bereitstellen, die diese vorwiegend im Ost-West-Muster nutzen. Das ist eine ineffiziente Nutzung der Netzwerkressourcen, und die daraus resultierenden Routing-Muster verursachen Verzögerungen in der Anwendungskommunikation. Hier tauchen Begriffe wie „Tromboning“ und „Hairpinning“ von Datenverkehrsmustern auf, die einen Weg im Netzwerk beschreiben, bei dem eine Maschine verlassen wird, der Datenverkehr nach Norden durch das Netzwerk läuft und dann zur gleichen Maschine zurückkehrt. Diese Verzögerungen führen zu realen Kosten, indem sie Ihre Produktivität verringern („Bitte haben Sie Geduld, mein Computer ist heute lahm“) und zu einem stärkeren Abbrechen von Einkäufen und Apps seitens der Nutzer führen. Das wollen wir vermeiden: Wenn der Verkehr Ost-West verläuft, sollten Sie Dienste auch in diesem Datenpfad platzieren.

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

Netzwerken erfordert und bleibt stets ein architektonischer Prozess. Es geht nicht nur um Formfaktoren, denn diese sorgen lediglich dafür, dass Serverressourcen schneller und effizienter dorthin gelangen, wo Sie sie brauchen. Entscheidend ist, wo Sie diese Ressourcen platzieren und welchen Einfluss dies auf alle Bereiche im Stapel hat: die Netzwerkdienste, die Anwendungssicherheit, die App-Leistung und letztlich auf Ihren Geschäftserfolg – oder Ihren Misserfolg.

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