Lift-and-Shift: Warum die Cloud-Rechnung nach dem Umzug explodiert

Ein Fertigungsbetrieb will seine IT-Betriebskosten senken und entscheidet sich für den schnellen Weg: Zwanzig Jahre gewachsene Datenbankserver aus dem eigenen Keller werden per „Lift-and-Shift" unverändert in virtuelle Maschinen bei einem großen Cloud-Anbieter geschoben. Ein halbes Jahr später hat sich die monatliche Rechnung für die Infrastruktur vervielfacht. Das Ziel war Sparen, das Ergebnis ist das Gegenteil.

Das Muster

Der Grund liegt in zwei grundverschiedenen Kostenlogiken. Eigene Hardware im Haus ist eine einmalige Investition. Ihr kauft einmal eine großzügig dimensionierte Maschine, betreibt sie über ein Jahrzehnt bei vielleicht einem Zehntel ihrer Kapazität — und das fällt nicht auf, weil Strom und Hardware feste, längst bezahlte Größen sind. Verschwendung im eigenen Rechenzentrum ist unsichtbar.

Die Cloud rechnet genau umgekehrt. Sie ist reiner laufender Verbrauch, minutengenau nach Nutzung abgerechnet. Nehmt ihr eine alte, nie optimierte Anwendung, die massive, schlecht indizierte Datenbankabfragen fährt, und lasst sie unverändert in der Cloud laufen, dann belegt sie rund um die Uhr teure, rechenstarke Instanzen. Was im eigenen Keller nur ungenutzte Kapazität war, wird in der Cloud zur sofortigen finanziellen Strafe. Die Ineffizienz war immer da — die Cloud macht sie nur zum ersten Mal sichtbar und teuer.

Ein Lift-and-Shift verschiebt also nicht nur die Anwendung, sondern auch ihre gesamte angesammelte Verschwendung — und stellt sie an einem Ort auf, an dem jede Verschwendung Geld kostet.

Aus unserer Praxis

Wir haben gelernt, keiner einfachen „Cloud-Readiness-Bewertung" zu trauen, wie sie große Anbieter gern kostenlos mitliefern. Sie bestätigt fast immer, dass ein Umzug problemlos möglich ist — was technisch stimmt und wirtschaftlich in die Irre führt.

In unseren Cloud-Projekten arbeiten wir stattdessen nach einem strengen, schlanken Brückenprinzip. Bevor irgendetwas in die Cloud wandert, setzen wir vor Ort an: Wir überarbeiten die Datenzugriffsschichten lokal oder schieben eine leichtgewichtige Zwischenschicht dazwischen — etwa einen Cache —, um die Datenströme zu bündeln und zu drosseln. Erst wenn eine Anwendung nicht mehr blindlings die Datenbank hämmert, ist sie ein sinnvoller Kandidat für den Umzug.

Der Leitsatz dahinter ist einfach: Jede Cloud-Migration gehört einer schlanken architektonischen Entkopplung nachgeschaltet — sonst lagert ihr eure Verschwendung nur zum Aufpreis aus. Ein Nachmittag, der die schlimmsten Abfragen bändigt, spart über die Laufzeit spürbar mehr, als der schnelle Umzug je versprochen hat.

Der schlanke Zwischenschritt

Wenn bei euch ein Cloud-Umzug ansteht, lohnt sich vorher eine kurze, ehrliche Bestandsaufnahme:

1. Welche Anwendung verursacht die meiste Dauerlast? Genau die wird nach dem Umzug am teuersten — und verdient die erste Optimierung.
2. Wo laufen Abfragen ohne Not rund um die Uhr? Was nachts und am Wochenende niemand braucht, muss auch keine Instanz beschäftigen.
3. Lässt sich der Datenzugriff entkoppeln? Eine Zwischenschicht, die Anfragen bündelt und Ergebnisse zwischenspeichert, senkt die Last, bevor sie zur Rechnung wird.
4. Migriert erst danach — und Stück für Stück. Ein optimierter Teil in der Cloud sagt mehr über die echten Kosten aus als jede Prognose vorab.

Fazit

Lift-and-Shift ist schnell und genau deshalb trügerisch: Er verschiebt Anwendung samt Verschwendung an einen Ort, der Verschwendung sofort in Geld übersetzt. Wer vorher schlank aufräumt und entkoppelt, bekommt die Flexibilität der Cloud, ohne die Rechnung explodieren zu lassen. Wenn ihr vor einem Umzug steht oder euch die Rechnung nach einem schon überrascht hat, schauen wir gern gemeinsam darauf, wo der schlanke Zwischenschritt am meisten bringt.