Klassische Infrastruktur wird für den Spitzentag dimensioniert und kostet dann jeden Tag so viel wie am Spitzentag. Serverless dreht dieses Modell um: bezahlt wird, was läuft, und was nicht läuft, kostet nichts. Cloud Run auf Google Cloud macht dieses Prinzip für normale Anwendungen nutzbar, ohne dass Teams ihre Arbeitsweise neu erfinden müssen. Wie das Kostenmodell funktioniert, wo seine Grenzen liegen und warum wir aus eigener Erfahrung darüber schreiben.
Die stille Rechnung im Serverraum
Es gibt eine Frage, die in Infrastruktur-Diskussionen selten gestellt wird, obwohl sie die wichtigste ist: Was kostet Ihre Infrastruktur, wenn niemand sie nutzt? Bei klassischen Servern lautet die Antwort: genauso viel wie sonst. Die Maschinen laufen nachts, am Wochenende und in den Ferien. Sie wurden für den stärksten Tag des Jahres dimensioniert, für den Black Friday, den Katalogversand, den Monatsabschluss. An allen anderen Tagen bezahlen Sie diese Reserve, ohne sie zu nutzen.
Diese Rechnung galt jahrzehntelang als Naturgesetz. Kapazität musste vorgehalten werden, weil Nachrüsten Wochen dauerte. Wer zu knapp plante, riskierte Ausfälle im entscheidenden Moment. Wer großzügig plante, verbrannte still Geld. Die meisten planten großzügig, aus nachvollziehbaren Gründen, und die Auslastungsstatistiken vieler Rechenzentren erzählen bis heute davon.
Was Serverless anders macht
Serverless kehrt das Prinzip um. Anwendungen laufen nicht auf fest zugeteilten Maschinen, sondern werden von der Plattform gestartet, wenn Anfragen kommen, und wieder beendet, wenn keine mehr kommen. Cloud Run, der Serverless-Dienst von Google Cloud, skaliert Anwendungen automatisch mit der Last, bei Bedarf bis auf null. Null heißt wörtlich null: Eine Anwendung, die gerade niemand aufruft, belegt keine Ressourcen und erzeugt keine Kosten.
Für die Kostenstruktur bedeutet das einen Wechsel von Fixkosten zu variablen Kosten. Sie bezahlen Rechenzeit, die tatsächlich stattfindet. Die Reserve für den Spitzentag müssen Sie nicht mehr kaufen, denn die Plattform stellt sie im Moment der Spitze bereit und räumt sie danach wieder weg. Der Black Friday kostet mehr als ein Dienstag im Februar, und genau so soll es sein, denn am Black Friday verdienen Sie auch mehr.
Der zweite Effekt ist betrieblicher Natur und wird oft unterschätzt. Es gibt keine Server mehr, die gepatcht, überwacht und ersetzt werden müssen. Das Betriebssystem, die Skalierung und die Ausfallsicherheit liegen bei der Plattform. Das Team, das bisher Maschinen pflegte, arbeitet an Anwendungen. Für kleine IT-Abteilungen ist dieser Effekt häufig wertvoller als die Kostenersparnis selbst, denn Fachkräfte sind knapper als Budget.
Wichtig für die Einordnung: Cloud Run ist kein Exot
Serverless hatte lange den Ruf, eine Spezialtechnik für kleine Funktionen zu sein, die eine besondere Programmierweise erzwingt. Für Cloud Run gilt das nicht. Die Plattform führt gewöhnliche Container aus. Eine Anwendung, die heute in einem Container läuft, läuft mit überschaubarem Aufwand auch auf Cloud Run, egal ob sie in Java, PHP, Python oder Node geschrieben ist. Das Team muss keine neue Architekturphilosophie lernen, um anzufangen.
Das macht Cloud Run zum pragmatischen Einstieg in die Cloud überhaupt. Statt einer großen Migration nimmt man einen einzelnen Dienst, der wehtut, verpackt ihn in einen Container und betreibt ihn serverless. Der alte Server bleibt, bis der neue Weg bewiesen hat, dass er trägt. Aus einem Grundsatzstreit über Cloud-Strategie wird ein überschaubares Experiment mit messbarem Ergebnis.
An dieser Stelle gehört Transparenz dazu: Wir schreiben hier nicht aus der Broschüre, sondern aus dem Betrieb. Unsere eigenen Systeme laufen auf Cloud Run, vom Content-Backend unserer Website bis zu den Werkzeugen unseres Alltags, genauso wie Systemlandschaften mehrerer unserer Kunden. Die Erfahrung daraus ist unspektakulär im besten Sinn: Die Dienste skalieren, wenn etwas los ist, kosten fast nichts, wenn nichts los ist, und niemand von uns hat seit Monaten über ein Betriebssystem-Update nachgedacht.
Wo das Modell an Grenzen stößt
Ein ehrlicher Artikel nennt auch die Fälle, in denen Serverless nicht die richtige Antwort ist. Anwendungen mit konstant hoher Dauerlast profitieren wenig vom variablen Modell, denn wer rund um die Uhr unter Volllast läuft, bezahlt variabel am Ende ähnlich viel wie fest. Für solche Workloads gibt es passendere Betriebsformen, auch innerhalb von Google Cloud.
Die zweite Grenze sind sehr latenzkritische Systeme mit seltenen Aufrufen. Wenn eine Anwendung auf null skaliert war und die erste Anfrage kommt, braucht der Start einen Moment. Für die allermeisten Web- und API-Anwendungen ist das irrelevant oder konfigurierbar lösbar, etwa indem eine Mindestinstanz warm gehalten wird. Aber man sollte es wissen, bevor man ein Handelssystem mit Millisekunden-Anforderungen plant.
Die dritte Grenze ist keine technische, sondern eine architektonische. Serverless belohnt kleine, klar geschnittene Dienste und bestraft Monolithen, die alles auf einmal tun. Wer eine große Altanwendung eins zu eins in einen Container packt, bekommt zwar den Betriebsvorteil, aber nur einen Teil des Kostenvorteils. Der volle Effekt entsteht, wenn die Landschaft schrittweise in Bausteine zerlegt wird, die unabhängig skalieren. Das ist Arbeit, aber sie ist planbar, und sie zahlt auf mehr ein als nur auf die Cloud-Rechnung.
Warum das Thema durch KI neues Gewicht bekommt
Das Lastprofil von KI-Anwendungen ist wie gemacht für dieses Modell. KI-Workloads sind stoßweise: Ein Batch-Job veredelt nachts Produktdaten, eine Anfragewelle trifft den Chatbot nach dem Newsletter-Versand, ein Modell wird einmal pro Woche neu trainiert. Für solche Muster feste Kapazität vorzuhalten, ist die teuerste aller Optionen. Sie serverless zu betreiben, ist die natürlichste.
Dazu kommt die Experimentierfrage. Unternehmen, die KI-Anwendungsfälle testen wollen, brauchen eine Umgebung, in der ein Experiment ein paar Euro kostet und nicht eine Beschaffungsrunde. Genau diese Umgebung ist Serverless: Der Prototyp läuft, wird gemessen und kostet nur, was er tatsächlich rechnet. Scheitert er, wird er gelöscht, und es bleibt keine Hardware übrig, die jemand abschreiben muss. Wie aus solchen Prototypen produktive Systeme werden, beschreibt unser Artikel über KI-Piloten in Produktion.
Ein Rechenbeispiel, bewusst vereinfacht
Ein vereinfachtes Beispiel macht das Modell greifbar. Die Zahlen sind fiktiv, die Struktur ist typisch. Ein Unternehmen betreibt ein internes Bestellportal. Die Nutzung konzentriert sich auf Werktage zwischen acht und achtzehn Uhr, mit einer Spitze am Monatsende. Klassisch betrieben laufen dafür zwei Server rund um die Uhr, dimensioniert für die Monatsend-Spitze. Von den 730 Stunden eines Monats werden sie vielleicht 220 Stunden nennenswert genutzt, und selbst in diesen Stunden meist weit unter ihrer Kapazität.
Auf Cloud Run betrieben startet dieselbe Anwendung morgens mit den ersten Zugriffen, skaliert am Monatsende automatisch hoch und fährt abends auf null. Bezahlt werden die tatsächlich gerechneten Stunden. Die Ersparnis liegt in diesem Muster nicht bei zehn oder zwanzig Prozent, sondern in einer anderen Größenordnung, weil der Grundrauschen-Betrieb komplett entfällt. Dazu kommt der ungeplante Gewinn: Als das Portal ein Jahr später unternehmensweit ausgerollt wird und sich die Nutzerzahl verdreifacht, ändert sich an der Infrastruktur nichts. Sie skaliert einfach mit, ohne Beschaffung, ohne Projekt.
Noch einmal deutlich: Das ist ein Illustrationsbeispiel, keine Ergebniszusage. Anwendungen mit konstanter Volllast erreichen solche Effekte nicht. Deshalb steht am Anfang immer die Analyse des eigenen Lastprofils, nicht das Versprechen.
Wie sich Cloud Run in die restliche Landschaft fügt
Eine berechtigte Sorge bei jedem neuen Betriebsmodell ist die Integration. Niemand will eine weitere Insel. Hier hilft die Einordnung: Cloud Run ist kein Sondersystem, sondern ein Baustein im Baukasten von Google Cloud, und die Bausteine sind aufeinander abgestimmt. Ein Dienst auf Cloud Run spricht nativ mit BigQuery für Auswertungen, mit Cloud SQL für relationale Daten, mit Pub/Sub für Ereignisse und mit Vertex AI für Modelle. Berechtigungen, Protokollierung und Netzwerkregeln folgen denselben Mechanismen wie im Rest der Plattform.
Für gewachsene Landschaften heißt das: Der serverless betriebene Dienst ist kein Fremdkörper neben dem ERP und den Bestandssystemen, sondern der Integrationspunkt, über den sie schrittweise verbunden werden. Viele unserer Projekte beginnen genau so. Der erste Cloud-Run-Dienst ist eine API, die zwei Altsysteme verbindet, die vorher per Dateiaustausch kommunizierten. Von dort wächst die Landschaft Baustein für Baustein, in dem Tempo, das Budget und Team hergeben.
Was sich für Ihr Team im Alltag ändert
Neben Kosten und Skalierung gibt es einen dritten Effekt, der sich erst im Alltag zeigt. Deployments verlieren ihren Schrecken. Eine neue Version geht auf Cloud Run als neue Revision live, und wenn etwas schiefgeht, ist die alte Revision mit einem Handgriff zurück. Teams, die vorher einmal im Quartal unter Anspannung deployt haben, liefern plötzlich wöchentlich oder täglich, weil der einzelne Schritt klein und umkehrbar geworden ist.
Das verändert auch das Verhältnis zwischen Entwicklung und Betrieb. Wo früher zwei Gruppen mit Tickets kommunizierten, übernimmt ein Team den ganzen Weg, weil der Betriebsanteil klein genug geworden ist. Für ein mittelständisches Unternehmen heißt das konkret: mehr Veränderungen pro Jahr mit demselben Personal. Diese Schlagzahl ist am Ende der Effekt, der über Wettbewerbsfähigkeit entscheidet, nicht die eingesparte Serverrechnung.
Wie Sie herausfinden, was bei Ihnen drin ist
Der Einstieg in diese Rechnung ist einfacher, als viele denken. Nehmen Sie Ihre Infrastrukturkosten der letzten zwölf Monate und stellen Sie ihnen die tatsächliche Auslastung gegenüber. Die Lücke zwischen bezahlter und genutzter Kapazität ist Ihr Potenzial. Suchen Sie dann den einen Dienst, der als Pilot taugt: klar abgegrenzt, containerfähig, mit schwankender Last. Interne Werkzeuge, APIs, Batch-Verarbeitungen und Webanwendungen sind typische Kandidaten.
Diesen einen Dienst bringen wir mit Ihnen auf Cloud Run, messen drei Monate die echten Kosten und legen die Zahlen neben die alten. Danach entscheiden Sie auf Basis von Ergebnissen, nicht von Folien, wie es weitergeht. Nach unserer Erfahrung beantwortet sich die Frage dann von selbst. Den Einstieg finden Sie auf unserer Google-Cloud-Seite. Alle Analysen finden Sie in unseren Google Cloud Insights.