Warum wir eine ganze Serverlandschaft umziehen können, ohne sie neu zu bauen

„Kein Lock-in“ steht auf jeder zweiten Anbieter-Seite. Meistens ist es ein Versprechen ohne Deckung. Bei uns ist es eine technische Eigenschaft, und der Beweis läuft gerade: Wir ziehen eine komplette Anwendungs-Landschaft von einem Hoster zum anderen um, ohne sie neu zu bauen. Das geht, weil sie nie zusammengeklickt wurde, sondern als Code beschrieben ist.

Die meisten Server-Umgebungen entstehen von Hand. Jemand loggt sich beim Anbieter ein, klickt einen Server zusammen, installiert, konfiguriert, öffnet Ports, richtet Zertifikate ein. Das funktioniert, aber es hat einen Haken, den man erst spürt, wenn man weg will: Diese Umgebung existiert nur an genau dieser Stelle. Niemand hat aufgeschrieben, wie sie zustande kam. Sie umzuziehen heißt dann, sie an einem anderen Ort mühsam noch einmal von Hand nachzubauen und zu hoffen, dass man nichts vergisst. Genau dieser Aufwand ist der Kitt, mit dem Anbieter ihre Kunden halten. Nicht durch einen Vertrag, sondern durch die schiere Mühe des Weggehens.

Umgebung als Code

Wir bauen Umgebungen nicht zusammen, wir beschreiben sie. Wie viele Server, welche Größe, welches Netz, welche Firewall-Regeln, welche Zertifikate, das steht bei uns in Textdateien, in unserem Fall mit Terraform. Diese Beschreibung ist die Wahrheit über die Umgebung, nicht der zufällige Zustand, der irgendwann irgendwo entstanden ist.

Der Unterschied klingt nach einem technischen Detail, ist aber der ganze Hebel. Wenn eine Umgebung als Code beschrieben ist, kann man sie lesen, versionieren, prüfen, und vor allem: an einer anderen Stelle wieder ausrollen. Die Beschreibung ist nicht an einen bestimmten Anbieter gekettet. Zeigt sie heute auf den einen Hoster, zeigt sie morgen auf einen anderen, und der baut dieselbe Umgebung auf, gleiche Struktur, gleiche Regeln, reproduzierbar. Kein Nachbauen aus dem Gedächtnis, kein Vergessen.

Der Beleg, der gerade läuft

Genau das machen wir zurzeit mit einer ganzen Landschaft, die wir betreiben: Umzug von einem Hoster (Hetzner) auf einen anderen (IONOS), beide in Deutschland. Nicht als Nacht-und-Nebel-Aktion mit viel Handarbeit und angehaltenem Atem, sondern als kontrollierter Vorgang: Die Umgebung wird beim neuen Anbieter aus derselben Beschreibung aufgebaut, die den alten Stand definiert. Die Wildcard-Zertifikate holt sich das System automatisch über die DNS-Prüfung, sodass die Verschlüsselung am neuen Ort ohne Handgriff steht. Am Ende wird der Verkehr per DNS umgeschwenkt. Der Umzug ist kein Kunststück mehr, sondern ein Ablauf.

Dass die Server dabei in Deutschland bleiben, ist keine Nebensache, sondern feste Vorgabe: Standard-Umgebungen stehen bei uns auf deutschen Servern, kein Umweg über eine US-Cloud.

Warum das dem Kunden gehört, nicht uns

Hier kommt der Teil, den die meisten Anbieter ungern laut sagen: Dieselbe Eigenschaft, die uns den Umzug leicht macht, macht auch dem Kunden den Abschied leicht. Wer eine Umgebung als Code beschreibt, kann sie überall wieder aufbauen, wir genauso wie ein Nachfolger. Wenn ein Kunde gehen will, bekommt er seine Daten, seine Domain und seine Zugänge geordnet übergeben. Nichts ist bei uns eingemauert, nichts liegt in einem Format, das nur wir lesen können.

Das ist Absicht. Ein Kunde, der nur bleibt, weil das Weggehen zu mühsam wäre, bleibt aus dem falschen Grund. Wer jederzeit gehen kann, bleibt freiwillig, und das ist die einzige Bindung, die uns interessiert. „Kein Lock-in“ ist deshalb bei uns kein Werbewort, sondern ein Nebenprodukt davon, wie wir bauen. Man kann es nicht behaupten und trotzdem heimlich einmauern. Entweder die Umgebung ist beschrieben und damit umziehbar, oder sie ist es nicht.

Wie wir Umgebungen als Code beschreiben und betreiben, steht auf koetting.io/de/betrieb/hoster-unabhaengig.