Cloud wird oft so verkauft, als wäre sie automatisch die bessere, modernere und vor allem hochverfügbare Lösung. Und klar: Wenn du dir die Werbeversprechen anschaust, klingt das wie ein No-Brainer. Ein bisschen Managed hier, ein bisschen Object Storage da, irgendwo noch ein Kubernetes-Cluster – und schon soll alles schnell, robust, wartungsarm und praktisch unkaputtbar sein. In der Praxis ist das für private Projekte und viele kleine Firmen aber häufig genau das Gegenteil: mehr Komplexität, mehr Abhängigkeiten, mehr Rechnungspositionen und am Ende trotzdem keine echte Hochverfügbarkeit, wenn du sie nicht gezielt planst.
Das Kernproblem ist, dass „Cloud“ nicht bedeutet, dass du plötzlich ein hochverfügbares System geschenkt bekommst. Cloud heißt erstmal nur: Du mietest dir Bausteine. Eine VM ist ein Baustein. Eine Managed Datenbank ist ein Baustein. Ein Object Storage ist ein Baustein. Ein Load Balancer ist ein Baustein. Und Kubernetes ist nochmal ein eigener Werkzeugkasten, in dem du dir diese Bausteine zu einer Architektur zusammenstecken kannst. Was viele unterschätzen: Aus Bausteinen entsteht nicht automatisch ein solides Haus. Du kannst dir zehn verschiedene Cloud-Dienste zusammenkaufen und trotzdem an einem einzigen falsch gesetzten Detail hängen, das dir im Zweifel alles umlegt.
Bei kleinen Setups ist der Cloud-Vorteil außerdem oft eher theoretisch. Viele Firmen oder Privatleute brauchen keine horizontale Skalierung im großen Stil, keine Multi-Region-Strategie und keine ausgefeilten SLA-Konstrukte. Sie brauchen etwas, das stabil läuft, bezahlbar ist, und im Problemfall schnell wieder online ist. Genau da ist „ein guter Server, sauber aufgesetzt“ oft die deutlich bessere Lösung. Du bekommst viel Leistung für wenig Geld, du hast keine zig Abrechnungsmodelle für Traffic, Storage, IOPS und sonstwas, und du hast die volle Kontrolle darüber, was auf der Maschine passiert. Vor allem: Du reduzierst die Anzahl beweglicher Teile. Weniger Teile heißt fast immer weniger Fehlerquellen.
Natürlich kommt dann sofort der Einwand: „Ja, aber wenn alles auf einer Maschine läuft und die fällt aus, ist alles tot.“ Das stimmt – aber auch nur, wenn du keinerlei Vorsorge triffst. Und das ist ein wichtiger Punkt: Hochverfügbarkeit ist keine Cloud-Eigenschaft, Hochverfügbarkeit ist eine Designentscheidung. Auch wenn du auf einer einzigen Maschine hostest, kannst du dir ein Setup bauen, das für viele reale Anforderungen „hochverfügbar genug“ ist. Nicht im Marketing-Sinn von „fünf Neunen“, sondern im praktischen Sinn: Ausfall wird selten, Recovery wird schnell und Datenverlust wird unwahrscheinlich.
Das erreichst du nicht durch das Kaufen von mehr Services, sondern durch saubere Grundlagen. Erstens: Backups, und zwar nicht „irgendwann mal“, sondern automatisiert, versioniert und mit einem getesteten Restore. Zweitens: Monitoring, das dir nicht nur sagt „Server lebt“, sondern auch „Platte läuft voll“, „RAM läuft voll“, „DB hat Probleme“, „Traffic ist komisch“. Drittens: ein klarer Recovery-Plan. Wenn du weißt, wie du innerhalb von 15–60 Minuten wieder online bist, ist das für extrem viele kleine Anwendungen bereits mehr als ausreichend. Der große Unterschied zur Cloud-Erzählung ist: Du verlässt dich nicht auf vage Versprechen, sondern du weißt konkret, wie dein System sich im Fehlerfall verhält.
Cloud kann dir diese Dinge bequemer machen, ja. Managed Datenbanken nehmen dir Patches und Backups ab. Object Storage ist robust und skaliert ohne Nachdenken. Load Balancer und Multi-Zone-Setups können Ausfälle auffangen. Aber das ist kein kostenloser Gewinn. Du bezahlst dafür mit Geld und Komplexität. Und genau da liegt die Sache: Für kleine Firmen und privat bringt das „Cloud-Gefühl“ oft kaum Vorteile, weil du den größten Nutzen (skalieren, Teams, Compliance, automatisierte HA) entweder gar nicht brauchst oder nicht konsequent durchziehst. Was oft passiert: Man baut eine halbgare Cloud-Architektur – und die ist dann teurer als ein dedizierter Server und trotzdem nicht wirklich ausfallsicher.
Ein weiteres Missverständnis ist die Idee, dass verteilte Systeme automatisch stabiler seien. In Wahrheit sind verteilte Systeme oft fragiler, weil sie mehr Abhängigkeiten haben. Wenn deine App mit einer externen Datenbank spricht, hängt deine Verfügbarkeit plötzlich vom Netzwerk dazwischen ab. Wenn deine Medien in einem Object Storage liegen, hast du eine weitere Abhängigkeit. Wenn du dann noch ein CDN davor klemmst, kommt wieder ein Layer dazu. Das kann hervorragend funktionieren – aber es ist eben nicht automatisch robust. Und genau das hast du selbst schon richtig erkannt: Du kannst zehn Sachen dazukaufen, und wenn eine davon nicht mehr tut oder falsch konfiguriert ist, stehst du trotzdem da.
Heißt das, Cloud ist immer Unsinn? Nein. Cloud ist vor allem dann sinnvoll, wenn du organisatorische Probleme lösen willst: mehrere Leute deployen, du willst klare Verantwortlichkeiten, du brauchst SLAs, du willst standardisierte Prozesse, du musst Audit-Anforderungen erfüllen oder du hast wirklich Lastspitzen, die sich wirtschaftlich nur über elastische Skalierung abfangen lassen. In solchen Fällen ist Cloud nicht „cool“, sondern praktisch. Aber das ist nicht der Normalfall für ein privates Projekt oder eine kleine Firma, die eine Webapp betreibt.
Die ehrliche Frage, die du dir stellen musst, lautet am Ende nicht „Cloud oder nicht Cloud“, sondern: Wie viel Downtime ist für dich akzeptabel – und wie viel bist du bereit zu zahlen, um diese Downtime zu reduzieren? Wenn du sagst: „Eine Stunde Ausfall alle paar Monate wäre zwar nervig, aber nicht existenzbedrohend“, dann ist ein sauberer Einzelserver mit Backups und Monitoring extrem attraktiv. Du bekommst maximale Einfachheit und minimierst Kosten. Wenn du sagst: „Wir dürfen praktisch nie ausfallen, weil sonst Umsatz wegbricht oder Kunden abspringen“, dann musst du über echte Hochverfügbarkeit nachdenken – und die kostet. Egal ob on-prem, bei Hetzner oder in einer großen Cloud. Hochverfügbarkeit bedeutet mehrere unabhängige Komponenten, Replikation, Failover-Logik, Tests, Monitoring, Incident-Prozesse. Das ist kein Feature, das du im Shop anklickst.
Und genau da ist auch die große Entlastung: Du musst nicht sofort die „perfekte“ Architektur bauen. Du kannst bewusst mit einem günstigen, einfachen Setup starten. Ein guter Server, eine solide Datenbank, saubere Backups (zur Not in Object Storage), ein paar sinnvolle Metriken und Alerts. Das ist für die meisten ein besserer Start als sich in Kubernetes plus Managed DB plus Object Storage plus CDN plus allem möglichen zu verheddern, ohne dass du überhaupt weißt, welche Ausfallzeit du realistisch akzeptieren kannst. Wenn du später merkst, dass das Projekt wächst und Ausfälle teurer werden, kannst du schrittweise entkoppeln: Datenbank auf einen zweiten Server, Medien in Object Storage, Replikation, Load Balancer, Multi-Node. Dann macht die zusätzliche Komplexität Sinn, weil sie ein echtes Problem löst.
Unterm Strich ist das Ganze also viel weniger religiös, als es oft dargestellt wird. Cloud ist nicht automatisch besser. Ein einzelner Server ist nicht automatisch schlecht. Es hängt davon ab, was du brauchst, wie kritisch dein Dienst ist, wie viel du bereit bist zu zahlen und wie viel Downtime du akzeptierst. Wenn du das ehrlich beantwortest, ergibt sich die Architektur fast von allein. Und das ist eigentlich die angenehmste Erkenntnis: Du musst nicht jedem Trend hinterherlaufen. Du musst nur ein Setup bauen, das zu deinem Risiko, deinem Budget und deiner Realität passt.
Kommentare