Eine unveränderliche Infrastruktur ist ohne eine Architektur pro App nicht möglich

Bereits 2013 wurde uns das Konzept eines unveränderlichen Servers vorgestellt . Ein unveränderlicher Server ist, wie der Begriff unveränderlich schon sagt, statisch. Seine Konfiguration ist fest und kann (oder sollte zumindest) nicht geändert werden. Wenn Änderungen erforderlich sind, ersetzt ein neuer Server mit der neuen Konfiguration den laufenden Server. Dies ist insbesondere bei Cloud- und hochautomatisierten lokalen Umgebungen wünschenswert, da es die Konfiguration vereinfacht und die Zuverlässigkeit der Automatisierungssysteme verbessert, die die Bereitstellungen steuern.

Dieses Konzept funktioniert in Cloud- und Containerumgebungen sogar für Netzwerk- und Anwendungsdienste gut, in herkömmlichen, gemeinsam genutzten Infrastrukturarchitekturen jedoch nicht so gut.

Der Grund hierfür ist, dass die Definition einer gemeinsam genutzten Infrastruktur mehrere laufende Dienste voraussetzt. Basierend auf den Daten von F5 iHealth kann „mehrere“ durchschnittlich 123 einzelne Konfigurationen (virtuelle Server) bedeuten. Es ist weder praktikabel noch empfehlenswert, dass Sie versuchen, 122 dieser virtuellen Server zu stoppen und erneut bereitzustellen, um eine einzelne Änderung an einem virtuellen Server vorzunehmen.

Dies bedeutet jedoch nicht, dass das Konzept unpraktisch oder unerwünscht ist. Der Schlüssel zur Einführung einer unveränderlichen Infrastruktur zusammen mit Ihren Automatisierungs- und Infrastruktur-als-Code-Systemen (IaC) besteht in der Umstellung auf eine Pro-App-Architektur.

Warum unveränderliche Infrastruktur?

Warum würden Sie eine derart umfassende Änderung der Netzwerkarchitektur Ihres Unternehmens vornehmen? Ich möchte mich selbst zitieren , da mir heute keine bessere Formulierung einfällt:

Wegen der Entropie.

Das Gesetz der Software-Entropie wird von Ivar Jacobson et al. in „ Objektorientierte Softwareentwicklung“ beschrieben: Ein anwendungsfallorientierter Ansatz “:

Der zweite Hauptsatz der Thermodynamik besagt grundsätzlich, dass die Unordnung in einem geschlossenen System nicht verringert, sondern nur unverändert bleiben oder verstärkt werden kann. Ein Maß für diese Unordnung ist die Entropie . Dieses Gesetz scheint auch für Softwaresysteme plausibel; wenn ein System verändert wird, nimmt seine Unordnung oder Entropie stets zu. Dies wird als Software-Entropie bezeichnet.

Dieses Gesetz gilt auch für Systeme, bei denen Firmware- oder Systemupdates durchgeführt werden müssen. Für die Hotfixes und Patches bereitgestellt werden. Für diese dringenden Konfigurationsänderungen sollten im Idealfall nur im Rahmen eines strikt eingehaltenen Änderungsmanagementprozesses Änderungen vorgenommen werden. Das Problem, das unveränderliche (wegwerfbare) Infrastrukturen zu lösen versuchen, besteht darin, dass Systeme umso verfallener und instabiler zu werden scheinen, je mehr Änderungen man in sie einführt. Störung. Chaos. Entropie.

Dabei geht es nicht nur um Konfigurationsänderungen im Dienst einer App oder die Bereitstellung virtueller Notfall-Patches für kürzlich entdeckte Sicherheitslücken. Dies sind gute Gründe, die Konfiguration eines Anwendungsdienstes zu ändern, aber nicht die einzigen. Hotfixes, Patches und Versionsabhängigkeiten sind ebenfalls gute Gründe dafür, dass Sie möglicherweise eine der 123 auf einer gemeinsam genutzten Infrastruktur ausgeführten Konfigurationen ändern müssen.

Durch die Umstellung auf eine Architektur pro App eliminieren Sie das Störungspotenzial einer oder zwei oder sogar zehn dieser Instanzen für die anderen Hundert, die auf einer gemeinsam genutzten Infrastruktur ausgeführt werden. Indem jeder App ein eigener Datenpfad zugewiesen wird, wird im Wesentlichen die Grundlage für die Unterstützung eines unveränderlichen Infrastrukturansatzes geschaffen, der den Übergang zu einer automatisierten Bereitstellungspraxis auf der Basis von Infrastruktur als Code besser unterstützt.

Dies bedeutet eine vollständig softwarebasierte Anwendungsservice-Pipeline – mit Anwendungsservices, die in einer „Mikro-Anwendungsservice“-Architektur bereitgestellt werden, ähnlich der Bereitstellung von Mikroservices in Containern. 

Julian Dunn von Chef hat es in seinem Blog – Immutable Infrastructure – gut ausgedrückt: Praktisch oder nicht?

Unveränderliche Infrastruktur wird im Allgemeinen als ein Stapel definiert, den Sie einmal erstellen (sei es ein virtuelles Maschinenimage, ein Containerimage oder etwas anderes), von dem Sie eine oder mehrere Instanzen ausführen und den Sie nie wieder ändern. Das Bereitstellungsmodell besteht darin, die Instanz/den Container zu beenden und erneut bei Schritt eins zu beginnen: ein neues Image zu erstellen und alte Instanzen zu verwerfen.

Wenn wir das also auf die Anwendungsdienste anwenden, die am engsten mit einer bestimmten Anwendung gekoppelt (affin) sind, erhalten wir eine zweistufige Netzwerkarchitektur, die aus zentralen, gemeinsam genutzten Diensten besteht (wie Netzwerk-DDoS und Zugriff über herkömmliche portbasierte Firewalls), die in einen „Stack“ pro Anwendung einspeisen, der als unveränderlich behandelt und mithilfe von Infrastruktur-als-Code-Konzepten bereitgestellt/verwaltet wird.

Ohne eine Infrastruktur pro App ist Unveränderlichkeit jedoch nicht wirklich möglich, da Sie zunächst die entsprechenden Anwendungsdienste von ihren gemeinsam genutzten Plattformen entkoppeln müssen. Wenn Sie dieselbe Plattform verwenden können – nur in einem Software-Formfaktor – wird dieser Prozess sogar noch einfacher, weil Sie bereits über einen Großteil des Wissens und der erforderlichen Toolsets verfügen, um mit Volldampf auf ein unveränderliches Modell pro App hinzuarbeiten.

Auch wenn Sie eine wirklich unveränderliche Infrastruktur nicht in Betracht ziehen, wird die Möglichkeit, sie zu nutzen, wenn es am sinnvollsten ist (neue Infrastrukturversion, Hotfixes, Patches usw.), sowohl Ihnen als auch den DevOps-Eigentümern der App, die die Infrastruktur unterstützt, das Leben erleichtern.