Der Cloud-Stack hat inzwischen sieben Ebenen, nicht nur IaaS, PaaS, SaaS
Jeder Kurs lehrt immer noch drei Kästchen: IaaS, PaaS, SaaS. Der Markt hat vor etwa anderthalb Jahren aufgehört, zu diesem Bild zu passen.
Das alte Diagramm war gut. Es beantwortete eine Frage sauber: Wie viel vom Server ist mein Problem? Mieten Sie eine Maschine, gehört Ihnen alles davon. Schieben Sie Code auf eine Plattform, gehört das meiste davon dem Anbieter. Kaufen Sie fertige Software, gehört Ihnen nichts davon.
Dann passierten drei Dinge. Die Mitte des Stacks fiel in sich zusammen. Die Datenbank wurde zu einem eigenen Markt, durch den Milliarden fließen. Und eine neue Ebene kam dazu, die es nur gibt, weil KI-Agenten heute Code schreiben, der irgendwo laufen muss.
So würde ich das Bild stattdessen zeichnen. Zwei Stacks statt einem, und SaaS in keinem von beiden.
Beachten Sie, dass SaaS in keinem der beiden Stacks steht. Es war immer der Fremdkörper. SaaS ist Software, die Sie kaufen. Der Rest sind Orte, an denen Sie Software laufen lassen, die Sie geschrieben haben. Beides in ein Diagramm zu packen, hat eine Generation von Studierenden verwirrt.
Änderung eins: PaaS und Functions sind ineinander gefallen
Die alte Regel war einfach, und jahrelang stimmte sie.
Eine PaaS-App ist ein Programm, das durchläuft. Es sitzt da und wartet. Sie zahlen pro Stunde, den ganzen Tag, auch um 3 Uhr nachts, wenn niemand wach ist. Denken Sie an ein Geschäft, das das Licht anlässt.
Eine Function ist kein Programm, das durchläuft. Sie wacht auf, wenn eine Anfrage kommt, erledigt die Arbeit und legt sich wieder schlafen. Sie zahlen pro Anfrage. Denken Sie an einen Automaten.
Also: warm heißt Abrechnung pro Stunde, kalt heißt Abrechnung pro Anfrage. Zwei saubere Optionen.
Beide haben sich inzwischen bewegt, und zwar aus entgegengesetzten Richtungen.
Vercels Fluid compute lässt eine Instanz viele Anfragen gleichzeitig bedienen und rechnet CPU nur ab, solange Ihr Code tatsächlich rechnet. Wartet Ihr Code auf eine Datenbank oder ein KI-Modell, pausiert der CPU-Zähler. Zwischen zwei Anfragen kostet gar nichts. Die Sätze liegen bei $0.128 pro CPU-Stunde und $0.0106 pro GB-Stunde Arbeitsspeicher. Das ist ein warmer, langlebiger Prozess, abgerechnet wie eine Function.
Aus der anderen Richtung nimmt Google Cloud Run einen gewöhnlichen Docker-Container, gibt ihm ein vollständiges Linux, jede Sprache, die Sie wollen, bis zu 32 GB Arbeitsspeicher und 60 Minuten Timeout, und skaliert ihn trotzdem auf null. Das ist eine Rechnung in Function-Form, gelegt um einen echten Server.
Dieselben drei Anfragen, dreimal anders abgerechnet. "Läuft es warm?" und "wie werde ich abgerechnet?" waren früher eine Frage. Heute sind es zwei, und Sie bekommen jede Kombination davon.
Änderung zwei: "serverless" bedeutet inzwischen vier verschiedene Dinge
Hier laufen die meisten Gespräche schief. Jemand sagt, das Team gehe auf serverless, alle nicken, und drei Monate später stellt sich heraus, dass das Gewählte keinen Cronjob ausführen kann.
- Läuft
- Ein kurzer Request-Handler nach dem anderen
- Skaliert auf null
- Ja, vollständig
- Der Haken
- Laufzeitlimits variieren; warme Instanzen können Speicher und temporäre Dateien behalten, aber ohne Persistenzgarantie
- Läuft
- Kompatible Container-Images. Cloud-Run-Dienste: bis zu 32 GiB und 60 Minuten Request-Timeout. Fargate hat andere Limits und unterstützt dauerhaft laufende Tasks.
- Skaliert auf null
- Cloud-Run-Dienste können das automatisch. Fargate-Dienste brauchen eine ausdrückliche Skalierungsrichtlinie und einen Mechanismus zum erneuten Starten der Tasks.
- Der Haken
- Weiterhin eine Region, wenn Sie nicht selbst mehr einrichten
- Läuft
- JavaScript oder WebAssembly, in jeder Stadt gleichzeitig
- Skaliert auf null
- Ja, und startet in unter einer Millisekunde
- Der Haken
- Keine vollständige Node-Laufzeit, und ein knappes Budget an CPU-Zeit
- Läuft
- Postgres, Rechenleistung getrennt vom Speicher
- Skaliert auf null
- Die Rechenleistung ja, der Speicher nie
- Der Haken
- Das Aufwachen dauert, und die Bytes werden auch im Schlaf berechnet
Die vier sind keine nahen Verwandten. Function-Limits hängen vom Anbieter ab. Die Stundengrenze von Cloud Run gilt für Service-Anfragen, nicht für jeden Serverless-Container oder Hintergrundjob. Ein Edge-Isolate startet in unter einer Millisekunde, kann aber keinen normalen Node-Code ausführen. Eine Serverless-Datenbank schickt ihre Rechenleistung schlafen und berechnet Ihnen weiter die Bytes auf der Platte.
Wenn das nächste Mal jemand serverless sagt, fragen Sie, welches der vier gemeint ist. Mit den Grenzen leben Sie danach.
Änderung drei: Das Geld ist zur Datenbank gewandert
Während das Internet über Kubernetes stritt, ging das eigentliche Kapital woanders hin.
Databricks zahlte rund 1 Milliarde Dollar für Neon, eine Firma, die serverless Postgres verkauft, bei etwa 25 Millionen Dollar Jahresumsatz. Snowflake holte sich Crunchy Data für berichtete 250 Millionen Dollar. Supabase ging in vier Monaten von 2 Milliarden Dollar Bewertung auf 5 Milliarden. Postgres kam in Stack Overflows Umfrage 2025 auf 55,6% Nutzung, das zweite Jahr in Folge die meistgenutzte Datenbank.
Danach fielen die Preise hart. Neons Speicher ging von $1.75 auf $0.35 pro GB-Monat herunter, eine Kürzung um 80%, und die Rechenleistung wurde ebenfalls billiger.
Der Grund steckt in der letzten Zahl. Über 80% der neuen Datenbanken bei Neon wurden von KI-Agenten angelegt, nicht von Menschen, nach 30% ein Jahr zuvor. Ein Agent, der pro Aufgabe eine Wegwerf-Datenbank hochzieht, ist ein völlig anderer Kunde als ein Mensch, der sich einmal im Quartal durch eine Konsole klickt. Postgres, das auf null skaliert, gibt es, weil es diesen Kunden gibt.
Und das ist ein zweiter Stack, keine Ebene im ersten. Wo Ihr Code läuft und wo Ihre Daten liegen, sind zwei getrennte Einkäufe. Im alten Diagramm gab es kein Feld für eine Datenbank, also hat es niemand so gelernt.
Die Falle beim Mischen der beiden Stacks
Nehmen Sie serverless Compute und eine gewöhnliche verwaltete Datenbank, und Sie begegnen ihr am ersten vollen Tag.
Postgres steht ab Werk auf 100 Verbindungen, und es gibt keinen cleveren Code, der diese Rechnung rettet. Sie setzen einen Pooler dazwischen, oder Sie nehmen einen Ausfall in Kauf.
Zwei Dinge sollten Sie außerdem wissen, bevor Sie einer Datenbank glauben, sie skaliere auf null. Der Speicher schläft nie: Nur die Rechenleistung tut das, und eine pausierte Datenbank kostet weiter für jedes Byte, das sie hält. Das Aufwachen dauert: Eine schlafende Datenbank braucht einen Moment, und dieser Moment kommt obendrauf auf den Kaltstart, den Ihre Function ohnehin schon hatte.
Dann gibt es noch die Asymmetrie, die entscheidet, wie misstrauisch Sie sein sollten. Die Hosting-Plattform zu verlassen, kostet ungefähr eine Arbeitswoche. Die Datenbank zu verlassen, heißt Terabytes bewegen, für den Abtransport zahlen und Abfragen für eine andere Engine umschreiben. Beim Lock-in der Rechenleistung dürfen Sie entspannt sein. Beim Lock-in der Daten nicht.
Die neue Ebene: Agenten-Sandboxes für Code, den die KI geschrieben hat
Das ist die wirklich neue Kategorie, und es gab sie nicht, als irgendjemand das ursprüngliche Diagramm gezeichnet hat.
Ein KI-Agent schreibt Code. Dieser Code muss laufen. Auf Ihrem eigenen Server können Sie ihn nicht laufen lassen, denn Sie haben ihn nicht geschrieben und wissen nicht, was er tut. Sie brauchen einen Wegwerf-Computer: eine Aufgabe, vollständig abgeriegelt, danach weggeworfen.
Daraus ist eine Produktkategorie mit echtem Wettbewerb geworden. Im April 2026 kam Unterstützung für Sandboxes ins OpenAI Agents SDK, mit sieben eingebauten Anbietern: Blaxel, Cloudflare, Daytona, E2B, Modal, Runloop und Vercel. Docker brachte ein eigenes experimentelles Sandbox-Feature.
| Anbieter | Wie isoliert wird | Längste Sitzung | GPU | Kaltstart |
|---|---|---|---|---|
| E2B | Firecracker microVM | bis zu 24 Stunden | nein | etwa 90 bis 200 ms |
| Modal | gVisor-Container | kein festes Limit | ja, T4 bis B200 | nicht veröffentlicht |
| Daytona | Sysbox-Container | kein festes Limit | ja | etwa 90 ms |
| Vercel Sandbox | Firecracker microVM | 45 Min. gratis, 24 Std. bezahlt | nein | nicht veröffentlicht |
| Cloudflare Sandboxes | Container an der Edge | 30 Minuten | nein | nicht veröffentlicht |
| Blaxel | microVM | kein festes Limit | nein | etwa 25 ms |
Angaben der Hersteller, und sie ändern sich schnell.
Die Unterschiede sind nicht kosmetisch. Die Grenzen für eine Sitzung reichen von 30 Minuten bis zu gar keiner. Kaltstarts reichen von etwa 25 Millisekunden bis zu ein paar hundert. Manche geben Ihnen eine GPU, die meisten nicht. Auch das Modell der Isolation unterscheidet sich: microVMs auf Hardware-Ebene wie Firecracker am einen Ende, Isolation über Container am anderen. Wenn Sie Code ausführen, dem Sie wirklich nicht trauen, lesen Sie diese Spalte zuerst.
Warum Sie das interessieren sollte, wenn Sie keine Agenten bauen? Wegen der 80% von Neon. Der am schnellsten wachsende Verbraucher von Cloud-Infrastruktur ist gerade kein Mensch. Jeder Anbieter baut seine Produkte um einen Kunden herum, der in Schüben auftaucht, neunzig Sekunden arbeitet und wieder verschwindet. Das verändert, was man Ihnen anbietet, wer immer Sie sind.
Wie Sie wählen: die Form der Arbeit zur Ebene passen lassen
Zwei Fragen statt einer. Erstens: Welche Form hat die Arbeit? Zweitens, und davon getrennt: Wo liegen die Daten?
Die meisten Teams treffen die erste Frage aus dem Bauch heraus ungefähr richtig und die zweite von Haus aus falsch, weil ihnen das alte Diagramm nie gesagt hat, dass es eine zweite Frage gibt.
Was sich überhaupt nicht geändert hat
Zwei Dinge bleiben auf jeder Ebene vollständig Ihre Sache, vom Bare Metal bis zur neuesten Sandbox.
Ihr Schema und Ihre Abfragen. Kein Anbieter in einem der beiden Stacks repariert Ihnen einen fehlenden Index. Eine verwaltete Datenbank, die vierzig Millionen Zeilen der Reihe nach durchgeht, ist eine langsame Datenbank. Hinter den meisten Tickets nach dem Muster "unsere verwaltete Datenbank ist langsam" steckt eine Abfrage, die sich nie jemand angesehen hat.
Ihre Rechnung. Jedes Modell hier hat seine eigene Art, Sie zu überraschen. Dauerhaft laufende Server kosten Geld, während Sie schlafen. Functions kosten pro Anfrage, und die Anfragen summieren sich schneller, als irgendwer erwartet. Kubernetes kostet $73 im Monat pro EKS-Cluster, bevor ein einziger Container startet, und springt auf rund $438, wenn Sie den Cluster bei den Versionen zurückfallen lassen. Serverless-Datenbanken kosten für Bytes im Ruhezustand. Eine Warnung per E-Mail schickt Ihnen niemand.
Das Diagramm in Ihrem Foliensatz ist nicht falsch. Es stammt nur aus einem kleineren Markt. Zeichnen Sie es mit zwei Stacks und sieben Ebenen neu, und die Diskussionen in Ihrem Team werden deutlich kürzer.
Die richtige Ebene zu wählen und von der falschen wegzukommen, ist das meiste von dem, was ich tue: AWS-Migrationen, Umzüge von Lambda auf Container und Kostenprüfungen für Teams, die früh geraten haben und jetzt dafür zahlen. Wenn Sie vor dieser Entscheidung stehen, melden Sie sich.
Die verlinkten Preisseiten und Übernahmeberichte belegen die genannten Zahlen. Prüfen Sie Container-Limits getrennt in der Dokumentation von Cloud Run und Fargate. Aktuelle Sandbox-Limits finden Sie bei E2B, Modal, Daytona, Vercel Sandbox, Cloudflare Sandboxes und Blaxel. Die Tabelle ist eine Momentaufnahme, kein von mir durchgeführter Benchmark und keine Garantie für Startzeiten. Geprüft im September 2026, und dieser Markt bewegt sich schnell, prüfen Sie also nach, bevor Sie sich festlegen.