„Lift-and-Shift" ist in vielen Runden ein halbes Schimpfwort. Es klingt nach Faulheit: die alte Anwendung nehmen, auf eine Maschine bei einem Anbieter stellen, fertig, und die Cloud sei ja gar nicht schuld, wenn danach nichts besser ist.
Der Ruf ist unverdient, und die Alternative hat ihren eigenen Weg zu scheitern. Wer jede Anwendung beim Umzug gleich umbaut, verbindet zwei Vorhaben, die getrennt schon schwierig genug sind, und weiß beim ersten Fehler nicht mehr, ob der Umzug oder der Umbau ihn verursacht hat.
Dieser Artikel sortiert die beiden Wege: was Lift-and-Shift wirklich bedeutet, was sich auch dort zwingend ändert, wann sich Replatforming rechnet, und warum die Rechnung nach einem reinen Umzug regelmäßig höher ist als vorher.
Die Entscheidung fällt meistens zu früh
In den meisten Projekten steht die Antwort fest, bevor jemand die Anwendung angesehen hat. Sie hängt davon ab, wer im Raum sitzt: Kommt der Anstoß aus dem Betrieb, wird umgezogen; kommt er aus der Entwicklung, wird umgebaut.
Beide Antworten können richtig sein, und beide sind es nicht pauschal. Die Entscheidung ist nämlich keine für das ganze System, sondern eine je Baustein. Eine Anwendung, die aus einem Webserver, einer Datenbank, einem Suchindex, einem Dateispeicher und zwölf Cronjobs besteht, hat fünf Entscheidungen, nicht eine, und in der Praxis fallen sie unterschiedlich aus.
Die einzige Frage, die die Entscheidung wirklich treibt, ist diese: Welchen Termin gibt es, und was passiert, wenn er reißt? Wer ein Rechenzentrum zum Jahresende verlässt, hat eine andere Entscheidung zu treffen als jemand, der die Cloud nur für sinnvoll hält.
Was Lift-and-Shift wirklich ist
Lift-and-Shift heißt: Die Anwendung läuft nach dem Umzug auf derselben Art von Maschine, mit demselben Betriebssystem, derselben Laufzeitumgebung und derselben Architektur wie vorher. Was sich ändert, ist der Ort und die Art, wie die Maschine entsteht.
Was es nicht heißt: dass nichts angefasst wird. Genau dieses Missverständnis erzeugt die Projekte, die nach dem Umzug im Dauerbetrieb feststecken. Drei Dinge ändern sich immer, und wer sie nicht einplant, plant den Umzug falsch.
Netzwerk und Zugriffsrechte. Im eigenen Rechenzentrum ist das Netz flach und alles erreicht alles. In der Cloud gibt es ein VPC, Subnetze, Sicherheitsgruppen und einen Rechtemechanismus, der jede Maschine und jeden Dienst einzeln berechtigt. Das ist kein Umbau der Anwendung und es ist ein eigenes Arbeitspaket.
Ausfall einzelner Maschinen. Eine virtuelle Maschine in der Cloud kann ohne Vorwarnung verschwinden, und das ist normal. Jede Anwendung, die Zustand auf ihrer eigenen Platte hält, muss an dieser Stelle etwas ändern: Sitzungen, hochgeladene Dateien, lokale Zwischenspeicher.
Wie die Maschine entsteht. Ein Server, den jemand über die Konsole geklickt hat, ist in der Cloud dasselbe Problem wie im Rechenzentrum, nur teurer. Der Umzug ist der eine Moment, in dem sich das ohne zusätzlichen Aufwand ändern lässt, weil die Maschine ohnehin neu entsteht.
Diese drei Punkte sind der Grund, warum ein ehrliches Lift-and-Shift kein Wochenende ist. Es ist trotzdem deutlich weniger als ein Umbau.
Wann Replatforming sich rechnet
Replatforming heißt, einen Baustein gegen einen verwalteten Dienst zu tauschen, ohne die Anwendung neu zu schreiben. Es rechnet sich, wenn der Baustein Betriebsaufwand erzeugt, den niemand gern trägt, und die Schnittstelle dieselbe bleibt.
Drei Fälle lohnen fast immer, und alle drei haben gemeinsam, dass sich für den Anwendungscode nur eine Verbindungszeichenfolge ändert.
Die Datenbank auf einen verwalteten Dienst. Sicherungen, Wiederanlauf, Nebenversionen, Überwachung: Das ist der Betriebsaufwand, der im Rechenzentrum an einer Person hängt und in der Cloud im Preis steckt. Der Anwendungscode merkt davon nichts, solange die Hauptversion dieselbe bleibt. Hier liegt gleichzeitig die häufigste Überraschung des ganzen Umzugs, weil eine ältere Version oft gar nicht mehr angeboten wird und der Sprung damit erzwungen ist.
Dateien in einen Objektspeicher. Ein Verzeichnis mit hochgeladenen Dateien ist der Grund, warum viele Anwendungen nicht auf zwei Maschinen laufen. Die Umstellung ist überschaubar, weil sie an einer Stelle im Code sitzt, und sie löst gleichzeitig das Problem mit dem Zustand von oben.
Die Warteschlange und die Hintergrundverarbeitung. Wo bisher ein Cronjob alle fünf Minuten nachsieht, ob etwas zu tun ist, steht danach eine Warteschlange. Das ist der Baustein mit dem größten Unterschied im Betrieb, weil er Lastspitzen abfängt und Wiederholungen ermöglicht.
Was nicht in diese Liste gehört: das Zerlegen der Anwendung in Dienste, der Wechsel auf Serverless und der Wechsel des Frameworks. Das sind Umbauten, nicht Replatforming, und sie gehören nicht in denselben Zeitraum wie ein Umzug.
Der Schritt, der aus einem gehobenen Server eine Anwendung macht, die sich vermehren lässt, steht in Sessions, Uploads, Konfiguration.
Die Kostenfalle: eins zu eins ist teurer
Der Satz, den niemand hören will und der fast immer zutrifft: Eine Anwendung, die unverändert in die Cloud umzieht, kostet dort mehr als vorher.
Der Grund ist keine Preispolitik, sondern eine Verwechslung von Auslastung und Kapazität. Im eigenen Rechenzentrum ist ein Server gekauft. Ob er zu zehn oder zu achtzig Prozent ausgelastet ist, ändert an den Kosten nichts, und deshalb hat ihn niemand je klein dimensioniert. In der Cloud wird genau diese Dimensionierung jeden Monat bezahlt.
Zwei Posten kommen dazu, die es vorher gar nicht gab. Datenverkehr aus der Cloud heraus kostet Geld, im Rechenzentrum war er Teil der Leitung. Und Speicher mit hoher Geschwindigkeit kostet ein Vielfaches von Speicher ohne, während im eigenen Rack beides dieselbe Platte war.
Praktisch heißt das: Die erste Rechnung nach dem Umzug ist kein Fehler, sondern die ehrliche Abbildung dessen, was vorher niemand gemessen hat. Sie sinkt danach, und zwar genau in dem Maß, in dem die Dimensionierung an die tatsächliche Last angepasst wird. Wie ein solcher Verlauf über zwölf Monate aussieht, habe ich an anderer Stelle aufgeschrieben.
Was daraus für die Planung folgt, ist unbequem und wichtig: Wer den Umzug mit Einsparungen begründet, begründet ihn mit einem Ergebnis, das erst nach dem Umzug entsteht, und muss das auch so sagen.
Die Reihenfolge, die ich empfehle
Aus alldem folgt eine Reihenfolge, die langsamer aussieht und schneller ist, weil sie die Fehlersuche kurz hält.
- Umziehen, so gleich wie möglich. Gleiche Versionen, gleiche Architektur, nur die drei unvermeidlichen Änderungen von oben. Ziel ist ein Zustand, in dem die Anwendung an zwei Orten läuft und man umschalten kann.
- Beobachtung einschalten, bevor umgeschaltet wird. Ohne Messwerte aus dem neuen Betrieb ist der nächste Schritt ein Ratespiel.
- Umschalten, mit einem Rückweg, und ihn eine Woche offen halten. Der Rückweg ist der Unterschied zwischen einer Umstellung und einem Abenteuer.
- Erst dann die Dimensionierung angehen. Jetzt gibt es echte Lastwerte, und jetzt sinkt die Rechnung.
- Danach Replatforming, ein Baustein nach dem anderen. Datenbank, Dateien, Warteschlange. Jeder Schritt einzeln ausrollbar und einzeln zurückdrehbar.
Der Schritt, den alle überspringen wollen, ist der vierte. Er hat den geringsten technischen Reiz und den höchsten Ertrag pro Aufwand von allen fünf.
Woran Sie merken, dass Sie zu viel auf einmal wollen
Drei Sätze aus Projektbesprechungen, die zuverlässig anzeigen, dass Umzug und Umbau vermischt wurden.
„Wenn wir schon dabei sind." Der Satz eröffnet jede Erweiterung eines Umzugsvorhabens und wirkt jedes Mal vernünftig. Er ist der Grund, warum aus sechs Wochen neun Monate werden. Die Antwort darauf ist kein Nein, sondern ein Datum: danach, als eigener Schritt.
„Das können wir nicht zurückdrehen." Sobald ein Schritt keinen Rückweg hat, ist er kein Umzugsschritt mehr. Er gehört dann hinter die Umstellung, nicht davor.
„Wir wissen nicht, ob das an der Cloud liegt." Das ist die Rechnung für vermischte Vorhaben. Wer gleichzeitig umzieht und umbaut, hat bei jedem Fehler zwei Verdächtige und keine Möglichkeit, sie zu trennen.
Wie das Ziel dieses Wegs konkret aussieht, steht in Ein PHP-Monolith auf ECS Fargate.
Der Termin, der die Entscheidung erzwingt
Zum Schluss der Fall, der in der Praxis am häufigsten vorkommt: Der Vertrag für das Rechenzentrum läuft aus, der Termin steht, und er ist nicht verhandelbar.
Dann ist die Entscheidung bereits gefallen, und zwar für Lift-and-Shift. Nicht weil es besser wäre, sondern weil ein Umbau unter Termindruck die Sorte Entscheidung erzeugt, die man zwei Jahre später bereut. Was in dieser Lage hilft, ist ein klarer Schnitt: Bis zum Termin zieht um, was umziehen muss, und alles andere bekommt ein Datum danach.
Und wenn kein Termin existiert, ist die ehrlichste Frage die, ob der Umzug überhaupt jetzt sein muss. Eine Anwendung, die auf eigener Hardware stabil läuft und deren Betrieb niemanden nachts weckt, hat keinen dringenden Grund für einen Ortswechsel. Wie eine AWS-Migration abläuft, wenn sie ansteht, steht auf einer eigenen Seite, samt der Frage, wann sie nicht ansteht.
Dieser Artikel gehört zu einer Reihe über Systeme, die es schon gibt. Der Rückblick ordnet alle Artikel der Reihe nach Anlass.
