Bei „Lift and Shift“ versteht man klassischerweise die Migration von Workloads von On-Premise Virtual Machines (VMs) zu VMs in der Cloud. Es gibt aber eine zweite Art des Begriffs, bei der nicht das Hosting, sondern die Virtualisierungsebene wechselt: von VM zu Container. Wie beim klassischen Lift and Shift gibt es auch bei diesem Ansatz Do’s and Don’ts, die einem den Weg erleichtern können. Wie diese aussehen beschreibe ich in diesem Blog-Beitrag.

Begriffsklärung

Die 6 R’s der Applikationsmodernisierung beschreiben, wie eine Applikation mittels verschiedenen Varianten modernisiert werden kann. Eine Applikation ohne Anpassungen im Code neu als Container zu betreiben, fällt dabei in die Variante “Rehosting”. Bei einem “Refactor” würde die Applikation so angepasst werden, dass diese die Vorteile der Zielplatform maximal ausnutzen könnte.

Der Haken

Man hat seine Applikation nun zwar in einem Container Image und kann diese beispielsweise in einem Azure Kubernetes Cluster (AKS) betreiben, die Vorteile davon spürt man aber nicht wirklich, und um Probleme, die vorher keine waren, muss man sich nun kümmern.

Eines der Hauptargumente für den containerisierten Betrieb ist die automatische Skalierung je nach Verbrauch (Usage). Hat man jedoch eine stateful Applikation, wie dies bei klassischen Anwendungen oft der Fall ist, kann dieser Vorteil nicht ausgenutzt werden. Laufen Jobs und Prozesse oder werden Benutzersessions direkt im Container gehalten, brechen Prozesse bei Runterskalierungen unsauber ab und Benutzer werden aus aktiven Sessions rausgeworfen.

Was bei Containern neu dazu kommt, ist die richtige Handhabung von Graceful Shutdown. Kubernetes beendet einen Container nicht abrupt, sondern sendet zunächst ein SIGTERM-Signal und ruft, falls konfiguriert, einen PreStop Hook auf, die Applikation hat dann ein definiertes Zeitfenster (terminationGracePeriodSeconds), um laufende Requests abzuschliessen und sich sauber zu beenden, bevor Kubernetes hart nachhilft (SIGKILL). Setzt die Applikation das nicht korrekt um, kann dies bei Node- oder Kubernetes-Version-Upgrades zu Unterbrüchen im Upgradeprozess führen oder diesen stark in die Länge ziehen, bis das Upgrade komplett abbricht.

Mit der Migration zu Containern verändern sich zudem die Anforderungen an Monitoring und Observability. VMs sind oft sehr langlebig und statisch, während die Anzahl an Containern stark variieren kann und diese eher kurzlebig sind. Mit diesen Veränderungen muss das Monitoring stark angepasst werden, und oft können die bereits eingesetzten Tools diese neuen Anforderungen nicht abdecken.

Fazit

Lift and Shift auf Container-Ebene ist ein legitimer erster Schritt, kein Endzustand. Um die Vorteile von Kubernetes/Containern wirklich auszunutzen, müssen grundlegende Funktionen und Prozesse in der Applikation angepasst werden. Workloads als Container zu betreiben bedeutet nicht automatisch, dass die Applikation auch modernisiert wurde.

Dieser Blogbeitrag wurde mit Unterstützung von KI erstellt.