Glossar
Lift and Shift
Auch: Rehosting
Ein System wird nahezu unverändert in die Cloud umgezogen, ohne Anpassung an Cloud-Eigenschaften.
Der Weg ist schnell und risikoarm, weil sich an der Anwendung nichts ändert. Er ist die richtige Wahl, wenn ein Rechenzentrumsvertrag ausläuft oder Hardware am Ende ist und der Termin nicht verhandelbar.
Was er nicht liefert, sind die Vorteile der Cloud. Eine feste Maschine, die vorher stand, steht danach in AWS und kostet dort oft mehr.
Der Grund für die höheren Kosten ist strukturell. Im eigenen Rechenzentrum ist der Server bezahlt, die Auslastung interessiert niemanden, und nachts läuft er eben leer. In AWS wird jede Stunde berechnet, auch die leeren, und man bezahlt zusätzlich eine Flexibilität, von der eine unveränderte Anwendung nichts hat. Dazu kommt Datenverkehr, der vorher im eigenen Netz kostenlos war und jetzt als Ausgangsverkehr auf der Rechnung steht.
Genau deshalb ist Lift and Shift kein Ziel, sondern eine Etappe. Der Nutzen entsteht in der zweiten Stufe: die Maschinen an den tatsächlichen Bedarf anpassen, Nicht-Produktion nachts abschalten, verwaltete Dienste statt selbstbetriebener Datenbanken, Objektspeicher statt großer Blockspeicher, und danach erst Commitments auf den dann stabilen Grundverbrauch.
Die Reihenfolge ist wichtig. Wer direkt nach dem Umzug Reserved Instances oder Savings Plans kauft, bindet sich für ein bis drei Jahre an die Maschinengrößen, die aus dem Rechenzentrum stammen, und nimmt sich damit den größten Hebel. Erst optimieren, dann festlegen.
Ein zweiter Punkt, der bei der Planung häufig fehlt: Der Umzug ist der einzige Moment, in dem ohnehin alles angefasst wird. Wenn dabei kein Fundament entsteht, also Kontostruktur, Protokollierung, Rechte und Schlagworte für die Kostenzuordnung, dann wird die neue Umgebung genauso ungeordnet wie die alte, nur teurer.
Es gibt auch den Fall, in dem Lift and Shift dauerhaft die richtige Antwort ist: ein System, das noch drei Jahre laufen muss, danach abgeschaltet wird und dazwischen keine Änderungen bekommt. Dann ist jede Optimierung eine Investition ohne Rückfluss. Diese Einschätzung sollte allerdings aufgeschrieben sein, denn Systeme mit Abschaltdatum haben die Angewohnheit, es zu überleben.
Woran Sie es erkennen
- Ein Rechenzentrumsvertrag läuft aus.
- Die Hardware ist am Ende ihrer Lebensdauer.
- Für einen Umbau fehlt die Zeit, für einen Stillstand das Geld.
- Die Anwendung bekommt keine nennenswerten Änderungen mehr.
Nicht zu verwechseln mit
- Replatforming
- Umzug mit gezielten Anpassungen, ohne die Anwendung neu zu bauen: verwaltete Datenbank statt eigener, Objektspeicher statt Dateiserver. Der übliche zweite Schritt.
- Refactoring / Rearchitecting
- Die Anwendung wird umgebaut, um Cloud-Eigenschaften zu nutzen. Teuerster Weg, größter Hebel, sinnvoll für die wenigen Systeme, an denen aktiv weiterentwickelt wird.
- Repurchase
- Das System wird durch ein fertiges Produkt ersetzt. Oft die günstigste Antwort für Standardfunktionen wie Mail, Ticketing oder Zeiterfassung.
- Retire
- Nicht migrieren, sondern abschalten. In fast jeder Bestandsaufnahme finden sich Systeme ohne Nutzer, und sie sind der billigste Posten der Migration.
Wann es trägt
- Ein Rechenzentrumsvertrag oder Wartungszeitraum endet zu einem festen Datum.
- Für einen Umbau fehlt die Zeit, für einen Stillstand das Geld.
- Die Anwendung wird nicht mehr aktiv weiterentwickelt.
- Als bewusst geplante erste Etappe mit Termin für Stufe zwei.
Wann nicht
- Wenn das System aktiv weiterentwickelt wird und Cloud-Eigenschaften nutzen könnte.
- Wenn die Migration allein mit Kostensenkung begründet wird: unverändert wird es teurer.
- Wenn kein Fundament entsteht und die Unordnung mitumzieht.
- Für Systeme, die ohne Nutzer laufen: die gehören abgeschaltet, nicht umgezogen.
Wie man rangeht
- Bestand aufnehmen und aussortierenWas läuft, wer nutzt es, was hängt daran. Jedes System, das nicht umzieht, ist der billigste Teil des Projekts.
- Fundament vor dem ersten ServerKonten, Netz, Rechte, Protokollierung, Schlagworte. Der Umzug ist der einzige Moment, in dem das ohne Zusatzaufwand mitgeht.
- Auf Bedarf umziehen, nicht auf BestandDie tatsächliche Auslastung über mehrere Wochen messen und danach die Maschinengröße wählen. Eins zu eins zu übernehmen zementiert die Überdimensionierung.
- In Wellen umziehenErst ein unkritisches System vollständig, inklusive Rückweg und Nachlauf. Die erste Welle baut das Verfahren, nicht den Umsatz.
- Stufe zwei terminieren, bevor Stufe eins beginntMit Datum und Verantwortlichem in derselben Entscheidungsvorlage. Ohne Termin findet sie nicht statt.
- Commitments zuletztErst wenn Größen und Verbrauch nach der Optimierung stabil sind. Vorher gekaufte Laufzeiten binden die alten Maschinengrößen.
Häufig gefragt
Wird es nach Lift and Shift teurer?
Meist ja, zunächst. Eine feste Maschine kostet in AWS mehr als im eigenen Rechenzentrum, weil man Flexibilität mitbezahlt, die man nicht nutzt. Dazu kommt Ausgangsverkehr, der vorher im eigenen Netz kostenlos war. Deshalb gehört die zweite Stufe geplant, bevor die erste beginnt.
Was gehört in die zweite Stufe?
In dieser Reihenfolge: Maschinen an den gemessenen Bedarf anpassen, Nicht-Produktion außerhalb der Arbeitszeit abschalten, selbstbetriebene Datenbanken durch verwaltete ersetzen, Daten in die passende Speicherklasse legen, Datenverkehr über Endpunkte statt über NAT führen. Commitments kommen zum Schluss, wenn der Verbrauch stabil ist.
Sollte man während des Umzugs gleich optimieren?
Nur bei der Maschinengröße, und die ist eher eine Messung als ein Umbau. Alles andere vergrößert das Zeitfenster und vermischt zwei Fehlerquellen: Wenn nach dem Umzug etwas nicht funktioniert, will man wissen, ob es am Umzug oder an der Änderung lag.
Wie lange darf die Zwischenstufe dauern?
Sechs Monate sind eine brauchbare Obergrenze. Danach hat sich die Umgebung gesetzt, es sind neue Abhängigkeiten entstanden, und jede Änderung wird wieder zum Projekt. Wer länger wartet, optimiert nicht mehr eine Zwischenstufe, sondern ein neues Altsystem.