Monolithen mit Microservices einbinden
Es gibt die phantasievolle Vorstellung, man könne einen Monolithen nehmen, ihn in einen Behälter stecken und voilà! Moderne architektonische Vorteile hinsichtlich Größe und Geschwindigkeit.
Tatsächlich deutete eine Umfrage auf der KubeKon 2018 darauf hin, dass genau dies bei etwa 55 % der Befragten der Fall ist, die angaben, Container „als VM-Ersatz für vorhandene Apps“ zu nutzen. Andere Umfragen zeigen, dass eine beträchtliche Anzahl von Java-Anwendungen der Enterprise-Klasse in Containern ausgeführt wird. Eine Diamanti-Umfrage aus dem Jahr 2018 ergab, dass die Mehrheit (54 %) Container für Cloud-native Apps nutzte, fast ein Drittel (31 %) sie jedoch zur Modernisierung älterer Anwendungen einsetzte.
Die genannten Gründe sind im Allgemeinen betriebswirtschaftlicher Natur. Container gelten trotz der enormen Zahl beweglicher Teile, die verwaltet werden müssen, als einfacher zu verwalten. Auch Leistung und Lizenzgebühren sind oft Faktoren, die für die Entscheidung, auf Container umzusteigen, entscheidend sind.
Dieser Schritt ist jedoch nicht so einfach wie das Verpacken und Ablegen einer Legacy-App in einem Container.
Die Realität ist, dass Monolithen – herkömmliche Client-Server- und Web-Anwendungen – bestimmte Eigenschaften aufweisen, die es schwierig machen, sie in einen Container zu übertragen und so die betrieblichen Vorteile zu nutzen. Container und Microservices schließen sich nicht gegenseitig aus, aber beide tendieren zum „Built to Fail“-Prinzip, auf dem die Verfügbarkeit moderner Apps basiert. Falls Sie dieses Prinzip nicht kennen: Wenn ein Container ausfällt, starten Sie einfach einen anderen, der seinen Platz einnimmt. Alle Container sind Vieh und einer ist so gut wie der andere.
In bewusst modernen zustandslosen Anwendungsarchitekturen ist das wahr. In herkömmlichen zustandsbehafteten Anwendungsarchitekturen ist dies nicht so sehr der Fall.
Sie sehen, Client-Server und sein Nachfolger, die dreischichtige Web-App, sind im Allgemeinen zustandsbehaftet. Sie speichern bestimmte Informationen über die Interaktion zwischen einem Client und der App in einer Sitzung. Diese Sitzung kann im Speicher des App- oder Webservers oder in einer separaten Datenbank gespeichert werden. Unabhängig davon, wo die Daten gespeichert sind, sorgen sie dafür, dass die App einen Status aufweist. Diese Daten sind für den Betrieb der App relevant und wichtig. Sie enthalten Ihren Einkaufswagen, die zuletzt besuchte Seite und andere appspezifische Informationen.
Sie können sich vorstellen, dass das plötzliche Verschwinden des Web-/App-Servers, auf dem diese Informationen gespeichert sind, die Client-Erfahrung negativ beeinträchtigt. Mein Einkaufswagen ist weg. Ich muss dorthin zurück navigieren, wo ich war. Im Grunde muss ich von vorne anfangen.
Dieses Verhalten steht im diametralen Gegensatz zu modernen Architekturprinzipien, die den zustandsbehafteten Betrieb einer Anwendung ausschließen. Es ist die zustandslose Natur moderner Apps und Dienste, die es ermöglicht, eine Instanz nahtlos durch eine andere zu ersetzen, wenn etwas schief geht. Es ist die Grundlage, auf der „Built to Fail“ funktioniert. Wenn Sie den Staat wieder in diese Gleichung einführen, fällt plötzlich alles auseinander.
Die App funktioniert zwar weiterhin, der Benutzer befindet sich jedoch in der Schwebe. Ihr Fluss wird unterbrochen, ihre Transaktionen in die Unterwelt transportiert und werden nie wieder gesehen.
Aufgrund dieses Problems entstand die Notwendigkeit, dass Anwendungsdienste den Status respektieren müssen. Sobald ein Client eine Verbindung zu einer bestimmten App/einem bestimmten Webserver herstellte, musste er für die Dauer der Sitzung eine Verbindung zu derselben App/demselben Webserver herstellen. Es wurden Cookie-Persistenz und andere Mechanismen entwickelt, um sicherzustellen, dass Anfragen jedes Mal an denselben Server weitergeleitet werden. Um den Zustand zu bewahren.
Die Realität ist, dass Sie, sofern Sie nicht gerade ein Greenfield-Start-up sind, bereits sowohl traditionelle als auch moderne Anwendungen laufen haben. Auch wenn die Forschungsergebnisse zu diesem Thema variieren, bleibt die Aufteilung „63 % veraltete / 37 % neue Apps“ im Laufe der Zeit weitgehend konstant. Das bedeutet, dass Sie sowohl ältere als auch moderne Architekturen gleichzeitig unterstützen müssen.
Das einfache Verschieben des Monolithen in einen Container hilft nicht weiter, wenn Sie die Kluft zwischen zustandsbehaftet und zustandslos nicht überwunden haben.
ARCHITEKTURELLE STUFENEINTEILUNG
Der beste – oder zumindest einfachste – Weg, die Migration von Monolithen in eine Containerumgebung zu verwalten, besteht darin, sicherzustellen, dass Sie auch in der zustandslosen Anarchie eines Containerclusters den Status weiterhin berücksichtigen können. Dies erfordert einiges an Intelligenz am Rand des Clusters, am Eingang, wo N-S auf O-W trifft.
Ein zweistufiger Ansatz unterstützt sowohl traditionelle als auch moderne Betriebsansätze sowie die Migration herkömmlicher, zustandsbehafteter Apps in eine Containerumgebung. Durch die Nutzung der F5 Container Ingress Services (CIS) kann NetOps weiterhin die Anforderungen von Stateful-Anwendungen unterstützen, die in Containerumgebungen migriert werden. Durch die Konnektivität wird sichergestellt, dass herkömmliche Lastausgleichsmethoden mit Persistenz weiterhin funktionieren und Anforderungen an den richtigen Container oder direkt in eine herkömmliche Umgebung weiterleiten können.
Gleichzeitig kann BIG-IP Anforderungen für moderne Apps und APIs gleichzeitig an einen Ingress-Controller innerhalb des Container-Clusters weiterleiten und diese auf so viele zustandslose Container wie nötig verteilen.
Übergänge brauchen Zeit
Tatsächlich unterstützen die meisten Unternehmen jedoch bis zu fünf völlig unterschiedliche Anwendungsarchitekturen – von Monolithen über Mobilgeräte bis hin zu Mikrodiensten. Die gleichzeitige Unterstützung einer gleichen, aber unterschiedlichen Anzahl von Netzwerk- und Betriebsmodellen wird den Betrieb mit Sicherheit überfordern und die Vorteile der Umstellung auf moderne Architekturen und Umgebungen zunichte machen. Ein strategischer, zweistufiger Ansatz ermöglicht es Unternehmen, die betrieblichen und geschäftlichen Vorteile beider Modelle optimal auszuschöpfen und gleichzeitig auf eine überwiegend containerisierte Umgebung umzusteigen.
REFACTOR-OPTION
Sie können diesen Übergang unter anderem dadurch erleichtern, dass Sie ältere Apps umgestalten, um die Vorteile gemeinsamer Sitzungen zu nutzen. Diese Sitzungen werden an einem vom Web-/App-Server getrennten Ort gespeichert – normalerweise eine Art Datenbank – und können von jedem Web-/App-Server mit der richtigen Sitzungs-ID abgerufen werden. Sie müssen die Sitzungs-ID weiterhin im Auge behalten, dies lässt sich jedoch im Allgemeinen über ein Cookie erreichen, das unabhängig vom Status des Web-/App-Servers bestehen bleibt. Wenn ältere Apps noch kein gemeinsames Sitzungsmodell verwenden, ist die entsprechende Umgestaltung im Vergleich zur Neuplattformierung der gesamten App ein relativ einfacher Vorgang.
Da solche Übergänge Zeit brauchen – schließlich arbeiten wir heute immer noch fast alle in einem Multi-Cloud-Modell – ist es wichtig, Architekturoptionen zu finden und zu nutzen, die den Nutzen maximieren, ohne die zentralen Kundenbedürfnisse wie Verfügbarkeit und Sicherheit zu beeinträchtigen. Die Verwendung eines zweistufigen Architekturansatzes ermöglicht beides, ohne die Containerisierungsbemühungen einzuschränken.