Es hält sich die Wunschvorstellung, man könne einen Monolithen einfach in einen Container packen und voilà: Schon profitiert man von den Skalierungs- und Geschwindigkeitsvorteilen moderner Architekturen.
Tatsächlich deutete eine KubeKon-Umfrage aus dem Jahr 2018 darauf hin, dass genau dies bei etwa 55 % der Befragten der Fall ist, die angaben, Container „als VM-Ersatz für bestehende Anwendungen“ zu nutzen. Andere Umfragen zeigen, dass eine beträchtliche Anzahl unternehmenskritischer Java-Anwendungen in Containern ausgeführt wird. Eine Diamanti-Umfrage aus dem Jahr 2018 ergab, dass die Mehrheit (54 %) Container zwar für Cloud-native-Anwendungen nutzte, aber fast ein Drittel (31 %) damit Legacy-Anwendungen modernisierte.
Als Gründe werden im Allgemeinen betriebliche Aspekte genannt: Container gelten als einfacher zu verwalten, obwohl die Zahl der zu verwaltenden Komponenten geradezu explodiert. Auch Leistung und Lizenzgebühren spielen bei der Entscheidung für den Einsatz von Containern häufig eine Rolle.
Doch dieser Umstieg ist nicht so einfach, wie eine Legacy-Anwendung zu verpacken und in einem Container bereitzustellen.
Tatsächlich weisen Monolithen – traditionelle Client-Server- und Webanwendungen – bestimmte Merkmale auf, die es erschweren, sie unverändert in einen Container zu verlagern und von den betrieblichen Vorteilen zu profitieren. Container und Microservices bedingen einander zwar nicht, orientieren sich jedoch beide am Prinzip „Built to Fail“, auf dem die Verfügbarkeit moderner Anwendungen beruht. Falls Ihnen dieses Prinzip nicht geläufig ist: Fällt ein Container aus, wird einfach ein anderer gestartet, der seinen Platz einnimmt. Container werden wie Nutzvieh behandelt – einer ist so gut wie der andere.
Bei bewusst modern konzipierten zustandslosen Anwendungsarchitekturen trifft das zu. Bei traditionellen zustandsbehafteten Anwendungsarchitekturen eher nicht.
Client-Server-Anwendungen und ihr Nachfolger, die dreischichtige Webanwendung, sind in der Regel zustandsbehaftet. Sie speichern bestimmte Informationen über die Interaktion zwischen einem Client und der Anwendung in einer Sitzung. Diese Sitzung kann im Arbeitsspeicher des Anwendungs- oder Webservers oder in einer separaten Datenbank gespeichert werden. Unabhängig davon, wo diese Daten gespeichert sind, machen sie die Anwendung zustandsbehaftet. Sie sind für den Betrieb der Anwendung relevant und wichtig. Sie enthalten Ihren Warenkorb, die zuletzt von Ihnen besuchte Seite und weitere anwendungsspezifische Informationen.
Sie können sich vorstellen, dass es das Kundenerlebnis erheblich beeinträchtigt, wenn der Web-/App-Server, auf dem diese Informationen gespeichert sind, plötzlich ausfällt. Mein Warenkorb ist weg. Ich muss zurück zu der Stelle navigieren, an der ich war. Im Grunde muss ich von vorne anfangen.
Dieses Verhalten steht in diametralem Gegensatz zu modernen Architekturprinzipien, die den zustandsbehafteten Betrieb einer Anwendung vermeiden. Erst die Zustandslosigkeit moderner Anwendungen und Dienste ermöglicht es, bei einem Fehler eine Instanz nahtlos durch eine andere zu ersetzen. Sie bildet die Grundlage für das Prinzip „Built to Fail“. Wird der Zustand wieder in diese Gleichung eingebracht, bricht plötzlich alles zusammen.
Die App funktioniert zwar weiterhin, doch der Nutzer bleibt im Ungewissen. Sein Ablauf wird unterbrochen, seine Transaktionen verschwinden im Nirgendwo und tauchen nie wieder auf.
Dieses Problem führte dazu, dass Anwendungsdienste den Sitzungsstatus berücksichtigen mussten. Sobald sich ein Client mit einem bestimmten Anwendungs- bzw. Webserver verbunden hatte, musste er für die gesamte Dauer der Sitzung mit demselben Server verbunden bleiben. Cookie-Persistenz und andere Mechanismen wurden entwickelt, um sicherzustellen, dass Anfragen jedes Mal an denselben Server weitergeleitet wurden – damit der Sitzungsstatus erhalten blieb.
Tatsache ist: Wenn Sie kein Start-up auf der grünen Wiese sind, betreiben Sie derzeit sowohl traditionelle als auch moderne Anwendungen. Zwar kommen Studien zu diesem Thema zu unterschiedlichen Ergebnissen, doch das Verhältnis von „63 % Legacy-Anwendungen zu 37 % neuen Anwendungen“ bleibt im Zeitverlauf weitgehend konstant. Das bedeutet, dass Sie sowohl Legacy- als auch moderne Architekturen gleichzeitig unterstützen müssen.
Den Monolithen einfach in einen Container zu verschieben, hilft nicht weiter, wenn Sie sich nicht mit der Trennung zwischen zustandsbehafteten und zustandslosen Anwendungen auseinandergesetzt haben.
ARCHITEKTUR-SCHICHTUNG
Der beste – oder zumindest einfachste – Weg, die Migration von Monolithen in eine containerisierte Umgebung zu bewältigen, besteht darin, sicherzustellen, dass der Zustand selbst in der zustandslosen Anarchie eines Container-Clusters weiterhin berücksichtigt werden kann. Dafür ist am Rand des Clusters, am Ingress, wo Nord-Süd- auf Ost-West-Verkehr trifft, eine gewisse Intelligenz erforderlich.
Ein zweistufiger Ansatz unterstützt sowohl traditionelle als auch moderne Betriebsmodelle sowie die Migration herkömmlicher, zustandsbehafteter Anwendungen in eine containerisierte Umgebung. Durch den Einsatz von F5 Container Ingress Services (CIS) kann NetOps weiterhin die Anforderungen zustandsbehafteter Anwendungen erfüllen, die in containerisierte Umgebungen migriert werden. Die Konnektivität stellt sicher, dass herkömmliche Load-Balancing-Methoden mit Persistenz weiterhin funktionieren und Anfragen an den richtigen Container oder direkt an eine traditionelle Umgebung weiterleiten können.
Gleichzeitig kann BIG-IP Anfragen für moderne Anwendungen und APIs an einen Ingress-Controller innerhalb des Container-Clusters weiterleiten, der sie auf so viele zustandslose Container wie nötig verteilt.
Übergänge brauchen Zeit
Tatsächlich unterstützen die meisten Unternehmen bis zu fünf grundlegend unterschiedliche Anwendungsarchitekturen – von monolithischen Anwendungen über mobile Apps bis hin zu Microservices. Die gleichzeitige Unterstützung einer ebenso großen, aber eigenständigen Anzahl von Netzwerk- und Betriebsmodellen überfordert mit Sicherheit den IT-Betrieb und macht die Vorteile des Umstiegs auf moderne Architekturen und Umgebungen zunichte. Ein strategischer, zweistufiger Ansatz ermöglicht es Unternehmen, während des Übergangs zu einer überwiegend containerisierten Umgebung die betrieblichen und geschäftlichen Vorteile beider Modelle auszuschöpfen.
REFAKTORISIERUNGSOPTION
Eine Möglichkeit, diesen Übergang zu erleichtern, besteht darin, Legacy-Anwendungen so umzugestalten, dass sie gemeinsam genutzte Sitzungen verwenden können. Diese Sitzungen werden an einem vom Web-/Anwendungsserver getrennten Ort gespeichert – in der Regel in einer Datenbank – und können von jedem Web-/Anwendungsserver mit der richtigen Sitzungs-ID abgerufen werden. Die Sitzungs-ID muss zwar weiterhin nachverfolgt werden, dies lässt sich jedoch im Allgemeinen über ein Cookie bewerkstelligen, das unabhängig vom Zustand des Web-/Anwendungsservers bestehen bleibt. Wenn Legacy-Anwendungen noch kein Modell mit gemeinsam genutzten Sitzungen verwenden, ist die entsprechende Umgestaltung im Vergleich zur Migration der gesamten Anwendung auf eine neue Plattform relativ unkompliziert.
Da solche Übergänge Zeit benötigen – schließlich arbeiten wir heute noch fast alle mit einem Multi-Cloud-Modell –, ist es wichtig, Architekturvarianten zu finden und zu nutzen, die den Nutzen maximieren, ohne zentrale Kundenanforderungen wie Verfügbarkeit und Sicherheit zu beeinträchtigen. Ein zweistufiger Architekturansatz erfüllt beide Anforderungen, ohne die Containerisierungsbemühungen einzuschränken.
Über den Autor
Lori MacVittie ist Distinguished Engineer und Chief Evangelist im Office of the CTO von F5 und verfügt über umfassende Expertise in den Bereichen Anwendungsbereitstellung, Automatisierungsstrategie und Infrastruktur. Sie ist dafür bekannt, Komplexität verständlich zu machen – ob sie Leitplanken für KI-Agenten definiert, fragile Multicloud-Architekturen analysiert oder die Grenzen skalierbarer Systeme auslotet. Sie verfügt über mehr als dreißig Jahre Branchenerfahrung in der Anwendungsentwicklung, IT-Architektur sowie im Netzwerk- und Systembetrieb. Bevor sie zu F5 kam, war sie als mehrfach ausgezeichnete Technologie-Redakteurin tätig. MacVittie hat einen Masterabschluss in Informatik und ist eine produktive Autorin, deren Veröffentlichungen die Bereiche Sicherheit, Cloud und Unternehmensarchitektur abdecken. Außerdem spielt sie leidenschaftlich gern Brett- und Videospiele und vertritt mit voller Überzeugung klare Ansichten zum Thema Käse.
Weitere Blogbeiträge von Lori Mac VittieÄhnliche Blogbeiträge
F5 und Equinix bündeln ihre Kräfte, um die sichere Anwendungsbereitstellung in Multicloud-Umgebungen zu vereinfachen
F5 und Equinix ermöglichen es Unternehmen, sich weltweit sicher und zuverlässig mit ihren Partnern zu vernetzen.
API-Sicherheitsrisiken und -herausforderungen
Erfahren Sie, warum APIs für die moderne App-Entwicklung unverzichtbar sind und wie Sie sie vor den häufigsten Sicherheitslücken schützen. Profitieren Sie von Expertentipps und direkt umsetzbaren Strategien.
Ein Meilenstein für die Community Impact Grants von F5
F5 feiert das fünfjährige Bestehen seines innovativen Community Impact Grant-Programms, das gemeinnützige Organisationen, bei denen sich F5-Mitarbeitende ehrenamtlich engagieren, mit Fördermitteln in Höhe von 5.000 US-Dollar unterstützt.
Mit moderner, anpassungsfähiger und sicherer Gesundheits-IT Leben retten
Die IT-Investitionen im Gesundheitswesen tragen dazu bei, die schnellsten Wege zu einer besseren Versorgung zu finden, indem sie die medizinische Betreuung näher an die Patientinnen und Patienten bringen. Viele Gesundheitsunternehmen nutzen riesige Mengen an klinischen und anderen Gesundheitsdaten, um Entwicklungen zu verfolgen und übergreifende Trends in der gesamten Gesundheitslandschaft zu erkennen. Gleichzeitig nähern sie sich einer möglichst präzisen, individuell zugeschnittenen Versorgung an.
Verbesserung der Benutzer- und Administrationserfahrung durch sicheren hybriden Zugriff
Diese Kombination aus BIG-IP Access Policy Manager und Azure Active Directory ermöglicht Identitätsföderation, zentralisierten Benutzerzugriff (über Single Sign-on) und erhöhte Anwendungssicherheit (durch Multi-Faktor-Authentifizierung) für geschäftskritische Anwendungen sowie cloudbasierte und SaaS-Anwendungen. Dieser Ansatz vereinfacht die Einrichtung und Bereitstellung, reduziert den Verwaltungsaufwand und verbessert die gesamte Administration.
Das Internet der Sicherheitsdinge
Nein, das ist keine Tirade über die Sicherheit des IoT. Es ist eine Geschichte über Veränderung – genauer gesagt über Veränderung und ihre Auswirkungen auf die Sicherheit. Veränderung ist allgegenwärtig. Es gibt unzählige Axiome und Sprichwörter über Veränderung, also ist es ...