Immutable Infrastruktur ist ohne eine anwendungsspezifische Architektur nicht möglich

F5

Im Jahr 2013 wurde uns das Konzept eines unveränderlichen Servers vorgestellt. Ein unveränderlicher Server ist, wie der Begriff „unveränderlich“ bereits andeutet, statisch. Seine Konfiguration ist festgelegt und kann (oder sollte zumindest) nicht geändert werden. Sind Änderungen erforderlich, wird der laufende Server durch einen neuen Server mit der neuen Konfiguration ersetzt. Dies ist insbesondere bei Cloud- und hochautomatisierten On-Premises-Umgebungen wünschenswert, da es die Konfiguration vereinfacht und die Zuverlässigkeit der Automatisierungssysteme erhöht, die die Bereitstellungen steuern.

Dieses Konzept funktioniert in Cloud- und containerisierten Umgebungen selbst für Netzwerk- und Anwendungsdienste gut, eignet sich jedoch weniger für herkömmliche Architekturen mit gemeinsam genutzter Infrastruktur.

Das liegt daran, dass eine gemeinsam genutzte Infrastruktur per Definition mehrere gleichzeitig ausgeführte Dienste umfasst. Laut den Daten von F5 iHealth kann dies durchschnittlich 123 einzelne Konfigurationen (virtuelle Server) bedeuten. Es ist weder praktikabel noch empfehlenswert, 122 dieser virtuellen Server anzuhalten und erneut bereitzustellen, nur um eine einzige Änderung an einem virtuellen Server vorzunehmen.

Das macht das Konzept jedoch weder unpraktikabel noch unerwünscht. Der Schlüssel zur Einführung einer unveränderlichen Infrastruktur in Verbindung mit Ihren Automatisierungs- und Infrastructure-as-Code-Systemen (IaC) liegt im Umstieg auf eine anwendungsspezifische Architektur.

Warum unveränderliche Infrastruktur?

Warum sollten Sie einen so grundlegenden Wandel in der Architektur Ihres Unternehmensnetzwerks vornehmen? Lassen Sie mich mich selbst zitieren, denn mir fällt auch heute keine bessere Formulierung ein:

Wegen der Entropie.

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

Der zweite Hauptsatz der Thermodynamik besagt grundsätzlich, dass die Unordnung eines geschlossenen Systems nicht verringert werden kann; sie kann nur unverändert bleiben oder zunehmen. Ein Maß für diese Unordnung ist die Entropie. Dieses Gesetz scheint auch auf Softwaresysteme zuzutreffen: Wenn ein System verändert wird, nimmt seine Unordnung beziehungsweise Entropie stets zu. Dies wird als Softwareentropie bezeichnet.

Dieses Gesetz gilt auch für Systeme, bei denen Firmware- oder systemnahe Updates eingespielt werden müssen. Bei denen Hotfixes und Patches bereitgestellt werden. Bei denen in Notfällen Konfigurationsanpassungen vorgenommen werden, obwohl diese in einer perfekten Welt ausschließlich im Rahmen eines strikt eingehaltenen Änderungsmanagementprozesses erfolgen sollten. Das Problem, das eine unveränderliche (austauschbare) Infrastruktur zu lösen versucht, besteht darin, dass Systeme mit jeder vorgenommenen Änderung zunehmend mit Altlasten behaftet und instabil zu werden scheinen. Unordnung. Chaos. Entropie.

Es geht nicht nur um Konfigurationsänderungen für eine App oder um die Bereitstellung virtueller Notfall-Patches für eine kürzlich entdeckte Schwachstelle. Das 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 Konfigurationen ändern müssen, die auf einer gemeinsam genutzten Infrastruktur ausgeführt werden.

Durch den Wechsel zu einer anwendungsspezifischen Architektur verhindern Sie, dass eine, zwei oder sogar zehn dieser Instanzen die übrigen hundert Instanzen beeinträchtigen, die auf einer gemeinsam genutzten Infrastruktur ausgeführt werden. Indem jede Anwendung im Wesentlichen einen eigenen Datenpfad erhält, schaffen Sie die Voraussetzungen für einen Ansatz mit unveränderlicher Infrastruktur, der den Übergang zu einer automatisierten, auf Infrastructure as Code basierenden Bereitstellungspraxis besser unterstützt.

Dies bedeutet eine vollständig softwarebasierte Pipeline für Anwendungsdienste, bei der die Anwendungsdienste in einer Architektur bereitgestellt werden, die sich durchaus als „Mikro-Anwendungsdienst“-Architektur bezeichnen lässt – ähnlich der Bereitstellung von Microservices in Containern.

Julian Dunn von Chef brachte es in seinem Blog gut auf den Punkt: Unveränderliche Infrastruktur: praktikabel oder nicht?

Unveränderliche Infrastruktur wird im Allgemeinen als ein Stack definiert, den man einmal erstellt (sei es als Image einer virtuellen Maschine, als Container-Image oder in einer anderen Form), von dem man eine oder mehrere Instanzen ausführt und den man danach nie wieder verändert. Das Bereitstellungsmodell sieht vor, die Instanz bzw. den Container zu beenden und wieder bei Schritt eins anzufangen: ein neues Image zu erstellen und die alten Instanzen zu verwerfen.

Wenn wir dies also auf die Anwendungsdienste übertragen, die am engsten mit einer bestimmten Anwendung gekoppelt (affin) sind, erhalten wir eine zweistufige Netzwerkarchitektur. Diese umfasst zentrale, gemeinsam genutzte Dienste (wie DDoS-Schutz auf Netzwerkebene und Zugriff über herkömmliche portbasierte Firewalls), die in einen anwendungsspezifischen „Stack“ einfließen, der als unveränderlich behandelt und nach Infrastructure-as-Code-Konzepten bereitgestellt und verwaltet wird.

Doch ohne eine anwendungsspezifische Infrastruktur lässt sich ein unveränderliches Modell nicht wirklich umsetzen, denn dafür müssen die relevanten Anwendungsdienste zunächst von ihren gemeinsam genutzten Plattformen entkoppelt werden. Wenn Sie dieselbe Plattform lediglich in Form von Software nutzen können, wird dieser Prozess noch einfacher, da ein Großteil des erforderlichen Wissens und der benötigten Toolsets bereits vorhanden ist, um mit voller Kraft auf ein anwendungsspezifisches, unveränderliches Modell hinzuarbeiten.

Selbst wenn Sie keine echte unveränderliche Infrastruktur in Betracht ziehen, erleichtert die Möglichkeit, sie bei Bedarf einzusetzen – etwa bei einer neuen Infrastrukturversion, Hotfixes oder Patches – sowohl Ihnen als auch den DevOps-Verantwortlichen der von dieser Infrastruktur unterstützten Anwendung die Arbeit.

Über den Autor

F5

Weitere Blogbeiträge von F5