Cloud Computing 2025 ist kaputt

Cloud-Plattformen wurden für eine Welt gebaut, in der Software groß und langsam war. Du hattest ein Frontend, ein Backend, eine Datenbank. Du hast ein Ding gebaut. Du hast für ein Ding bezahlt.

Diese Welt ist vorbei.

AI hat alles verändert.

Jetzt kann ein Solo-Dev locker zehn Tools pro Woche bauen, wahrscheinlich sogar zehn am Tag. Eines, um Dokumentationen zu scrapen. Eines, um deine Beziehungen zu automatisieren. Eines, das das Uptime-Monitoring übernimmt. Eines, das mit deinem CRM chattet. Keines davon ist eine „App“ im klassischen Sinn. Das sind Worker. Scripts. Bots. Agents. Nenn sie, wie du willst. Kurzlebige Services, die ein oder zwei Tage leben.

Die Kosten, Software zu schreiben, sind massiv gefallen und sinken immer noch weiter.

Aber Hosting? Immer noch teuer. Immer noch starr. Immer noch gebaut für eine Welt, die so nicht mehr existiert.

Die Cloud Economics sind stehen geblieben

Die meisten Plattformen berechnen dir immer noch pro App oder Dienst. Heroku, Render, DigitalOcean.

Das war okay, wenn du ein paar große Services hattest.

Aber wenn du 50 Tools deployen willst, explodieren die Kosten. Nicht, weil du mehr CPU nutzt. Sondern weil die Plattform dich behandelt, als wäre jedes einzelne Tool eine ganze Company.

Dieses Modell bremst Geschwindigkeit.

Dieses Modell bremst Experimente.

Und das passt einfach nicht zu der Art, wie AI-First-Developer (auch bekannt als Vibecoder) heute arbeiten.

Manche Plattformen haben’s versucht

Fly.io hat auf nutzungsbasiertes Billing und Auto-Shutdown gesetzt. Dadurch kam Serverless-ähnliches Pricing endlich auch für Container. Echt clever. Aber das Produkt musste schon oft pivoten und sucht immer noch seinen Platz (so zumindest mein Eindruck).

Railway ist eigentlich ganz gut darin, dir „scale to zero“ plus usage-based billing zu ermöglichen. Das hilft – aber wenn du viele Services auch nur ab und zu laufen lässt, summieren sich die Kosten schnell. Und wenn viele Services dauerhaft laufen, zahlst du trotzdem für Ressourcen, auch wenn sie idle sind.

Diese Plattformen haben die Veränderung erkannt. Sie haben reagiert. Aber die meisten stecken noch in alten Annahmen fest. Oder im VC-Druck. Oder beidem.

Warum Serverless auch nicht die Lösung ist

Auf dem Papier klingt Serverless wie die perfekte Lösung. Scale to zero. Bezahlen pro Request. Keine Leerlauf-Kosten. Yuhu!

In der Praxis? Viel schwerer, als es aussieht.

Eine gute Serverless-Architektur heißt, Code in viele kleine Stücke zu schneiden. AWS Lambda-Konfigurationschaos managen. APIs verknüpfen. Queues koordinieren. Irgendwie Observability in all den Functions behalten.

Wenn du ein großes Unternehmen mit Plattform-Team bist – alles okay. Wenn du aber nachts als Vibecoder mit AI-Tools experimentierst? Nur Overhead. Und die meisten Vibecoder würden eh nicht so tief einsteigen, auch nicht mit Mühe (und das kann man ihnen nicht mal wirklich übelnehmen).

Und LLMs denken nicht in Lambdas.

Sie denken: „Wie komme ich am schnellsten zu etwas, das einfach funktioniert?“

Das ist meistens ein Monolith und kein fancy „scale to infinity“-Infrastruktur-Konstrukt.

Das ist nicht einfach Microservices nochmal

Klingt das wie der Microservices-Hype der 2010er? Hier der Unterschied:

Microservices sollten organisatorische Komplexität lösen. Teams konnten unabhängig arbeiten. Dafür brauchte man viel Infrastruktur, Abstimmung, Verträge, DevOps.

Der Aufwand lohnte sich, wenn du 500 Engineer hattest. Nicht, wenn du alleine bist oder ein 3er-Team.

Das hier sind keine Microservices. Das ist nicht Serverless. Das ist eine ganz neue Art, Software zu bauen: schnell, billig, disposable – von Leuten, die sich nicht für Infra interessieren (und sie auch nicht immer verstehen müssen). Die Tools und auch die Pricing-Modelle müssen das abbilden.

Das echte Problem: Niemand will mehr Server betreiben

Klar, du kannst dir für 5 Dollar einen VM mieten. Das ist der Traum: volle Kontrolle, maximale Flexibilität.

Aber schnelle Builder (ja, die Vibecoder, die null Ahnung von Infra haben) wollen sich nicht mit Firewalls oder Logs oder SSL rumschlagen. Sie wollen nicht wissen, welche Ports offen sind. Sie wollen einfach nichts selbst managen müssen.

Sie wollen Code irgendwo reinkopieren, auf Deploy klicken, fertig.

Darum haben wir jetzt diese seltsame Lücke:

• Serverless ist zu zerstückelt
• PaaS ist zu teuer
• Self-Hosting ist zu viel Handarbeit

Diese neue Generation von Buildern braucht etwas dazwischen.

Besseres Modell: Bezahle die Kapazität, nicht die Einheiten

Statt pro App zu zahlen: Warum mietest du nicht einfach eine Kiste?

Ein Preis. So viele Services, wie in die Box passen. Keine Extra-Kosten für Kreativität.

Dieses Pricing-Modell ändert alles. Die Cloud wird damit zum Spielplatz. Du wirst nicht mehr bestraft, weil du kleine, disposable Tools baust – du wirst belohnt, denn je mehr Apps auf der Box laufen, desto kleiner der Preis pro Stück.

Ein paar Plattformen gehen langsam in diese Richtung. Wir bei Sliplane zum Beispiel. Aber das Thema ist größer als wir alleine.

(Ich glaube übrigens, dass Coolify genau deswegen gerade so durch die Decke geht.)

Das ist ein Change, wie Software gebaut wird.

Und der Großteil der Industrie ist noch nicht bereit dafür.

Weggabelung

VC-gepushte Plattformen brauchen hohen ARPU. Vorhersehbares, skalierbares Revenue. Bedeutet: Sie berechnen pro App. Pro Container, sogar wenn der schläft.

Aber Vibecoder? Die ist Shareholder Value völlig egal. Sie wollen einfach nur bauen.

AI macht Kreativität chaotisch und wild. Die besten Entwickler:innen nutzen genau das. Sie generieren. Basteln. Schmeißen weg. Bauen nochmal neu.

Die Cloud muss da einfach mal Platz machen.

Und das geht nur, wenn sich unser ganzes Denken und Prizing über Hosting ändert.

Schlussgedanke

Wir gehen in eine neue Ära. Die Einheit von Software ist nicht mehr „die App“, sondern ein ganzer Schwarm von disposable Vibecoder-Dingern.

Wenn dein Hosting das nicht abbildet, bist du nicht bereit für das, was kommt.

— Jonas
Co-Founder, Sliplane

PS: Ja, ich weiß wie biased ich bin – und dass ich davon profitieren würde, wenn genau das der Standard wird :)