Reparieren statt wegwerfen — warum self-hosted die ehrlichere Cloud ist

Wenn ich am Samstag die Motorhaube vom T3 öffne, sehe ich genau, was passiert. Da liegt die Einspritzpumpe. Da gehen die Leitungen zu den Düsen. Da ist der Vorfilter, da der Hauptfilter, da der Tank. Vier oder fünf Bauteile, alle zugänglich, alle benannt, alle mit einem Werkstatthandbuch versehen, das ich in der Garage stehen habe. Wenn ein Lieferant pleitegeht, kaufe ich das Teil bei einem anderen. Wenn ein Werkstatthandbuch ausgeht, gibt es zwei weitere Verlage, die es nachgedruckt haben.

Wenn ich am Samstag in das Admin-Panel einer großen Cloud-Plattform schaue, sehe ich Tabs, Dropdowns und Status-Lämpchen. Was tatsächlich auf welcher Maschine in welchem Rechenzentrum läuft, ist eine Black Box. Welcher Code wo entscheidet, was passieren darf, weiß ich nicht. Wenn der Anbieter morgen die Preise verdoppelt, ist das mein Problem. Wenn er das Feature einstellt, das mein Workflow braucht, ist das auch mein Problem. Wenn er aus regulatorischen Gründen die Region wechseln muss, dasselbe.

Das ist kein Cloud-Bashing. Cloud ist großartig — für viele Dinge die richtige Wahl. Aber sie wird gerne so verkauft, als wäre sie die verantwortungsvollere Lösung. „Lass es die Profis machen." „Du willst dich doch nicht um Server kümmern." „Wir nehmen dir die Komplexität ab." Das stimmt manchmal. Manchmal heißt es einfach: Du verlierst die Übersicht, dafür darfst du dir vorkommen, als hättest du sie nie gehabt.

Was self-hosted tatsächlich heißt

Bevor ich Self-Hosting verteidige, eine Klarstellung. Self-hosted heißt nicht: „Server unter dem Schreibtisch im Wartungsraum, gepflegt von der Person, die im Urlaub ist." Self-hosted heißt: Du betreibst die Software auf Infrastruktur, die du kontrollierst, mit Werkzeugen, die du verstehst, in einer Form, die du reparieren kannst. Das kann ein eigenes Rechenzentrum sein. Es kann eine NAS im Serverschrank sein. Es kann ein gemieteter Bare-Metal-Server sein. Wichtig sind nicht die Steckdosen, sondern die Kontrolle.

Ich betreibe eine ganze Reihe von Diensten selbst — Webseiten, Monitoring, Krypto-Bots, Datenarchive, ein paar interne Tools — auf einer einzigen Synology mit Docker und nginx. Nicht weil ich kein Geld für AWS habe. Sondern weil ich für jeden dieser Dienste exakt weiß: welcher Container, welcher Port, welches Volume, welches Logfile, welcher Restart-Mechanismus. Wenn etwas klemmt, klemmt es an einer der zehn Stellen, die ich im Kopf habe. Das ist Reparierbarkeit. Das ist der T3-Diesel der Infrastruktur.

Drei Stellen, an denen self-hosted in der Industrie die einfachere Wahl ist

1. Wenn die Daten Heimspiel sind.

In der Industrie reden wir oft über Daten, die nicht ohne weiteres das Werksgelände verlassen dürfen. Rezepturen. Anlagenparameter. Wartungshistorien, aus denen man Produktionsmengen rückrechnen kann. Geometrie- und Fertigungsdaten. In jedem dieser Fälle ist self-hosted nicht die komplizierte, sondern die einfache Antwort: Die Daten bleiben physisch dort, wo sie ohnehin sind. Kein Datentransfer-Vertrag, kein Schrems-II-Drama, keine ständige Diskussion mit der Compliance-Abteilung über die nächste Risiko-Bewertung des Anbieters.

2. Wenn das System lange leben soll.

Industrielle Software lebt nicht zwei Jahre. Eine COMOS-Datenbank, eine Plant-Asset-Management-Lösung, ein Wartungsplaner — die laufen 10, 15, 20 Jahre. Cloud-Verträge dagegen ändern sich alle 24 Monate. Preise, Lizenzmodelle, Featurelisten, regionale Verfügbarkeit. Wer einen 15-Jahre-Plan auf einer Plattform baut, die alle zwei Jahre ihre Grundlagen neu sortiert, hat einen ganzen Stack zukünftiger Migrationsprojekte gebucht, ohne es zu wissen. Self-hosted heißt hier: Du entscheidest, wann migriert wird — nicht der Quartalsbericht eines Anbieters.

3. Wenn die Lastspitze planbar ist.

Cloud rechnet sich, wenn Last unvorhersehbar ist. In der Industrie ist sie das selten. Eine Schicht beginnt um sechs, endet um vierzehn. Ein Wartungsmodul wird am Monatsende geöffnet. Eine Engineering-Plattform wird in den Auslegungsphasen genutzt. Das alles lässt sich auf vorhersehbarer Hardware betreiben, ohne den „on-demand"-Aufschlag, den Cloud-Anbieter für Flexibilität verlangen, die hier niemand braucht.

Was self-hosted nicht ist

Self-hosted ist nicht „kostenlos". Ein Server braucht Strom, Hardware altert, Backups müssen geprüft werden, Sicherheits-Patches müssen eingespielt werden. Wer das ignoriert, bekommt früher oder später die Quittung — meistens an einem ungünstigen Donnerstagvormittag. Aber: das sind bekannte Kosten. Sie stehen in keinem Lizenzpapier, das alle zwei Jahre neu verhandelt wird. Sie sind planbar wie der TÜV-Termin und die Bremsbeläge.

Self-hosted ist auch nicht „besser als Cloud". Manche Workloads sind so dynamisch, so global, so sporadisch, dass Cloud schlicht die richtige Antwort ist. Aber in der Industrie sind das deutlich weniger Workloads, als die Anbieterpräsentationen suggerieren. Die Frage, die ich Kunden stelle, ist nie „Cloud oder self-hosted?" — sondern: „Wer soll am Ende den Stecker ziehen dürfen?" Wenn die Antwort lauten muss „wir", dann gibt es einen Default — und der heißt: selbst betreiben, was selbst betrieben werden kann.

Der T3 noch einmal

Mein Bulli läuft seit 35 Jahren. Nicht weil er besonders gut wäre, sondern weil drei Bedingungen erfüllt sind: Es gibt Teile, es gibt Wissen, und es gibt jemanden, der ihn anfasst. Diese drei Bedingungen sind übertragbar. Self-hosted heißt: Es gibt offene Standards (= Teile), es gibt Dokumentation (= Wissen), es gibt jemanden im Team, der es versteht (= Hände). Cloud kann all das auch leisten — aber sie kann es jederzeit auch nicht mehr, ohne dich zu fragen.

In meiner Beratung sage ich daher selten „nimm self-hosted" und nie „nimm Cloud". Ich sage: Schau dir an, in welcher Beziehung du zum System stehen willst. Und wenn diese Beziehung in fünf Jahren noch trägt, dann ist sie wahrscheinlich näher am Schraubenschlüssel als am Browser-Tab.