PaaS-Komfort, Hyperscaler-Risiko: Was der Railway-Outage gestern Nacht gezeigt hat
Acht Stunden Outage gestern Nacht. Mein Go-Stack auf Railway war nicht erreichbar - das Frontend lief, das Backend war tot. Ursache: Google Cloud hat Railways Produktions-Account fälschlich in einen Suspend-Status verschoben. Automatisierte Aktion, keine Vorwarnung, und eine Reihe weiterer Kunden traf es im selben Schwung mit.
Was PaaS verspricht - und was nicht
Railway, Render, Fly.io und Konsorten verkaufen Developer Experience. Push-to-deploy, automatische Build-Pipelines, fertige Datenbanken. Das ist real und gut. Was sie nicht abstrahieren: die Infrastruktur unter der Plattform. Railway läuft auf GCP. Wenn dort ein Compliance-Filter falsch konfiguriert ist, geht Railway offline. Ohne Vorwarnung, ohne Eskalationspfad für den einzelnen Kunden.
Die Lieferketten-Frage
Vor fünf Jahren war „auf welchem Cloud-Provider seid ihr" eine sinnvolle Frage. Heute braucht es zwei: Auf welchem Provider seid ihr direkt - und auf welchem Provider sitzt eure PaaS? Bei vielen Java-Stacks ist die Antwort eindeutig. Bei einem Go-Service auf Railway sitzt man zwei Ebenen abstrahiert auf GCP. Die Abhängigkeit ist nicht weg. Sie ist nur weniger sichtbar.
Was praktisch hilft
Failover-Region ist Mindestpflicht. Selbst wenn das aktive Failover nicht automatisch greift - ein dokumentierter Plan B mit gepflegter Konfiguration spart in der Krise Stunden. Backup-Provider mit minimaler Bereitschaft. Health-Check der Plattform extern, nicht intern. Und nicht zuletzt: Status-Pages der Provider abonnieren - direkt und beim darunterliegenden Hyperscaler.
Fazit
Railway hat den Incident sauber und transparent kommuniziert. Das ist wertvoll. Die Lehre ist nicht „Railway ist unsicher" - sie ist: PaaS ist nicht das Ende der Cloud-Lieferkette. Plan B steht jetzt bei mir auf der Liste.
Kommentare
Kommentar veröffentlichen