Ser­ver­less Computing: Das steckt hinter dem modernen Cloud-Modell

Ser­ver­less Computing ist ein Cloud-Modell, bei dem der Provider große Teile der In­fra­struk­tur­ver­wal­tung übernimmt. Ent­wick­le­rin­nen und Ent­wick­ler laden lediglich Code (FaaS) oder nutzen ver­wal­te­te Dienste (BaaS), ohne Server zu pro­vi­sio­nie­ren. Die Ab­rech­nung erfolgt meist präzise nach Verbrauch, wobei viele Ser­ver­less-Dienste Res­sour­cen bei Nicht­be­nut­zung bis auf null skalieren (Scale-to-Zero).

Was verbirgt sich hinter dem Ser­ver­less-Konzept?

Nicht nur im privaten Sektor, sondern auch im ge­schäft­li­chen Bereich verlagert sich das digitale Arbeiten zunehmend in die Cloud. Neben klas­si­schen Cloud-Modellen wie In­fra­struc­tu­re-as-a-Service (IaaS) und Platform-as-a-Service (PaaS) hat sich Ser­ver­less Computing als besonders stark abs­tra­hier­tes Be­triebs­mo­dell etabliert.

Als Ser­ver­less Computing oder Ser­ver­less Ar­chi­tec­tu­re be­zeich­net man Cloud-Modelle, bei denen An­wen­dun­gen, Prozesse und Backend-Funk­tio­nen aus­ge­führt werden, ohne dass Un­ter­neh­men die zugrunde liegenden Server selbst be­reit­stel­len, kon­fi­gu­rie­ren oder skalieren müssen. Der Provider übernimmt Aufgaben wie Res­sour­cen­be­reit­stel­lung, Last­ver­tei­lung, au­to­ma­ti­sche Ska­lie­rung, Ver­füg­bar­keit und große Teile des Betriebs.

Ser­ver­less bedeutet also nicht, dass keine Server exis­tie­ren, sondern dass diese vom je­wei­li­gen Cloud-Anbieter verwaltet und für Nut­ze­rin­nen und Nutzer weit­ge­hend un­sicht­bar gemacht werden. Der Ser­ver­less-Ansatz geht damit weiter als viele PaaS-Angebote, bei denen In­fra­struk­tur zwar abs­tra­hiert wird, aber häufig noch laufende Instanzen, Ka­pa­zi­tä­ten oder Lauf­zeit­um­ge­bun­gen kon­fi­gu­riert werden müssen.

Shared Re­spon­si­bi­li­ty

Ser­ver­less reduziert viele In­fra­struk­tur­auf­ga­ben, hebt die ge­mein­sa­me Ver­ant­wor­tung zwischen Cloud-Anbieter und Un­ter­neh­men aber nicht auf: Der Provider verwaltet die zugrunde liegende In­fra­struk­tur, die Ska­lie­rung und viele Be­triebs­aspek­te. Doch unter anderem An­wen­dungs­si­cher­heit, Rollen und Be­rech­ti­gun­gen, Mo­ni­to­ring und sichere Ab­hän­gig­kei­ten müssen vom Ent­wick­lungs­team selbst gestaltet werden.

Das ist besonders wichtig, weil Ser­ver­less-An­wen­dun­gen häufig aus vielen kleinen Diensten, Events und Schnitt­stel­len bestehen. Eine saubere Rech­te­ver­ga­be, nach­voll­zieh­ba­re Logs und sichere Kon­fi­gu­ra­tio­nen sind daher ent­schei­dend, um Fehler, unnötige Kosten und Si­cher­heits­ri­si­ken zu vermeiden.

FaaS, BaaS und das Ser­ver­less-Ökosystem

Ser­ver­less Computing wird häufig noch mit einzelnen Funk­tio­nen gleich­ge­setzt. Dieses Ver­ständ­nis greift heute jedoch zu kurz. Moderne Ser­ver­less-An­wen­dun­gen kom­bi­nie­ren ver­schie­de­ne ver­wal­te­te Cloud-Dienste zu einer Ar­chi­tek­tur. Zwei Bereiche sind dabei besonders wichtig:

• Function-as-a-Service (FaaS): Einzelne Funk­tio­nen oder kleinere Services werden durch Er­eig­nis­se, HTTP-Anfragen, Zeitpläne oder Nach­rich­ten ausgelöst. Sie eignen sich für kurz­le­bi­ge, zu­stands­ar­me Aufgaben. Beispiele sind Bild­ver­ar­bei­tung nach einem Upload, Webhooks oder API-Endpunkte.
• Backend-as-a-Service (BaaS): Fertige Backend-Bausteine werden als ver­wal­te­te Dienste genutzt, etwa ser­ver­lo­se Da­ten­ban­ken, Object Storage, Au­then­ti­fi­zie­rung, Event-Busse, Queues oder Messaging-Dienste.

FaaS ist derzeit zwar das do­mi­nie­ren­de Segment im Ser­ver­less-Markt, doch der Trend geht immer mehr zu Ser­ver­less-An­wen­dun­gen, die FaaS und BaaS mit­ein­an­der kom­bi­nie­ren: Wird eine Datei in einem ver­wal­te­ten Cloud-Speicher abgelegt, löst dieses Ereignis eine ser­ver­lo­se Funktion aus. Diese Funktion steht für den FaaS-Teil der Ar­chi­tek­tur. Sie ver­ar­bei­tet die Datei, speichert Metadaten in einer ser­ver­lo­sen Datenbank und sendet an­schlie­ßend ein Ereignis über einen Event-Bus oder eine Queue an einen weiteren Dienst. Dies sind BaaS- bzw. Managed-Service-Bausteine.

Durch die Kom­bi­na­ti­on von FaaS und BaaS entsteht kein einzelner Funk­ti­ons­auf­ruf, sondern eine lose ge­kop­pel­te Ar­chi­tek­tur aus mehreren ver­wal­te­ten Cloud-Diensten. Die Bausteine dieser Ar­chi­tek­tur lassen sich funk­tio­nal in Re­chen­lo­gik, Da­ten­hal­tung, Er­eig­nis­ver­mitt­lung und Schnitt­stel­len gliedern. In der Praxis bleiben diese Bereiche eng mit­ein­an­der verbunden und skalieren je nach Dienst un­ab­hän­gig von­ein­an­der.

Wie funk­tio­niert Ser­ver­less Computing?

We­sent­lich für eine Ser­ver­less Ar­chi­tec­tu­re ist die au­to­ma­ti­sche Be­reit­stel­lung von Res­sour­cen durch den Cloud-Anbieter. Nut­ze­rin­nen und Nutzer laden ihren An­wen­dungs­code als Funktion, Service oder Container-Image in die Ser­ver­less-Plattform hoch oder kon­fi­gu­rie­ren Dienste wie Da­ten­ban­ken, Storage und Event-Broker. Die Plattform ent­schei­det an­schlie­ßend, wann eine Aus­füh­rung gestartet wird und wie viele Res­sour­cen dafür benötigt werden. Ein typischer Ablauf sieht so aus:

1. Ein Ereignis, zum Beispiel ein HTTP-Request oder ein Datei-Upload, tritt ein.
2. Die Ser­ver­less-Plattform erkennt das Ereignis und startet au­to­ma­tisch die dafür vor­ge­se­he­ne Funktion oder den passenden ver­wal­te­ten Dienst.
3. Die Funktion ver­ar­bei­tet die Anfrage, etwa indem sie Daten prüft, ein Bild umwandelt, eine Datenbank ak­tua­li­siert oder eine Antwort an den Client zu­rück­sen­det.
4. Treffen viele Er­eig­nis­se gleich­zei­tig ein, stellt die Plattform au­to­ma­tisch mehr Re­chen­res­sour­cen bereit.
5. Sinkt die Aus­las­tung wieder, reduziert die Plattform die Res­sour­cen. Bei voll­stän­di­ger In­ak­ti­vi­tät kann sie diese oft bis auf null zu­rück­fah­ren.

Die Ak­ti­vie­rung von Ser­ver­less-Funk­tio­nen passiert grund­sätz­lich auf zwei Arten:

• asynchron über Events, Nach­rich­ten oder Event-Broker
• synchron über klas­si­sche Anfragen, zum Beispiel per HTTP oder API-Gateway

Wenn bei­spiels­wei­se ein Bild in einem Cloud-Speicher abgelegt wird, aktiviert der Upload als asyn­chro­nes Ereignis au­to­ma­tisch eine passende Funktion. Die einzelnen Kom­po­nen­ten müssen dafür nicht dauerhaft laufen. Sie werden nur aktiv, wenn tat­säch­lich Arbeit anfällt.

EDA: Er­eig­nis­se als Ver­bin­dung zwischen Ser­ver­less-Diensten

Ser­ver­less Computing funk­tio­niert besonders gut in einer Event-Driven Ar­chi­tec­tu­re (EDA). Hier reagieren Dienste auf Er­eig­nis­se, anstatt direkt von­ein­an­der abhängig zu sein. In solchen Ar­chi­tek­tu­ren über­neh­men Event-Broker, Message Queues und Event-Busse die Rolle eines Ner­ven­sys­tems: Sie nehmen Signale aus der Anwendung auf, ordnen sie ein und leiten sie anhand de­fi­nier­ter Regeln an die zu­stän­di­gen Dienste weiter. Beispiele sind Kafka-basierte bzw. ver­wal­te­te Kafka-Dienste, Pub/Sub, Event­Bridge oder ver­gleich­ba­re Messaging- und Eventing-Dienste.

Der Vorteil: Pro­du­zen­ten und Kon­su­men­ten von Er­eig­nis­sen bleiben lose gekoppelt. Eine Anwendung, die eine Be­stel­lung erzeugt, muss nicht wissen, welche Dienste an­schlie­ßend Rech­nun­gen erstellen, La­ger­be­stän­de ak­tua­li­sie­ren oder Be­nach­rich­ti­gun­gen ver­schi­cken. Neue Funk­tio­nen lassen sich ergänzen, ohne be­stehen­de Kom­po­nen­ten umfassend umzubauen.

Ser­ver­less Ar­chi­tec­tu­re: Vorteile und Nachteile

Ser­ver­less Computing entlastet Ent­wick­lungs­teams von vielen In­fra­struk­tur­auf­ga­ben und eignet sich besonders für dy­na­mi­sche, er­eig­nis­ge­steu­er­te Workloads. Der Ansatz bringt jedoch auch Ein­schrän­kun­gen mit sich, etwa bei Kontrolle, Trans­pa­renz und Kos­ten­pla­nung. Die wich­tigs­ten Vorteile und Nachteile zeigt die folgende Tabelle:

Cold Starts: Nachteil mit tech­ni­schen Ge­gen­maß­nah­men

Die oben­ste­hen­de Über­sichts­ta­bel­le nennt Cold Starts als möglichen Nachteil von Ser­ver­less Computing. Gemeint ist die Ver­zö­ge­rung, die entstehen kann, wenn eine Funktion oder ein Service nach längerer In­ak­ti­vi­tät neu gestartet werden muss. Die erste Anfrage dauert dann unter Umständen länger als spätere Anfragen an eine bereits aktive Instanz.

Seit dem 1. August 2025 berechnet AWS die In­itia­li­sie­rungs­pha­se von Lambda-Funk­tio­nen nach Laufzeit und Speicher analog zur ei­gent­li­chen Aus­füh­rungs­zeit. Cold Starts können damit zumindest bei AWS Lambda nicht nur die Latenz erhöhen, sondern auch kos­ten­re­le­vant werden.

Für Cold Starts stehen je nach Plattform und Runtime ver­schie­de­ne Ge­gen­maß­nah­men zur Verfügung:

• Pro­vi­sio­ned Con­cur­ren­cy hält vor­be­rei­te­te Instanzen bereit.
• Snapshot-Verfahren wie AWS Lambda SnapStart können Start­zei­ten je nach Runtime und Kon­fi­gu­ra­ti­on deutlich re­du­zie­ren.
• Isolates und Wasm-Runtimes er­mög­li­chen schnelle Starts in vielen Edge-Szenarien.
• MicroVMs (Micro-Virtual Machines) wie Fire­cra­cker können bei be­stimm­ten Platt­for­men den Iso­la­ti­ons-Overhead gegenüber klas­si­schen VMs re­du­zie­ren.

Für viele An­wen­dun­gen sind Cold Starts dadurch gut be­herrsch­bar. Relevant bleiben sie vor allem bei syn­chro­nen HTTP-Anfragen, sehr niedrigen La­tenz­an­for­de­run­gen oder großen KI-Modellen, die erst geladen werden müssen.

Kos­ten­mo­dell: Vorteil mit Ein­schrän­kun­gen

Auch beim Kos­ten­mo­dell zeigt sich, warum die Vor- und Nachteile dif­fe­ren­ziert be­trach­tet werden müssen. Ser­ver­less kann sehr wirt­schaft­lich sein, weil für Compute-Res­sour­cen häufig keine dauerhaft laufenden Instanzen bezahlt werden müssen. Statt­des­sen entstehen Kosten nut­zungs­ab­hän­gig nach dem Pay-per-Use-Modell, z. B. pro Anfrage, Laufzeit, Event, Spei­cher­zu­griff oder KI-Inferenz.

Besonders vor­teil­haft ist dieses Modell bei Workloads mit schwan­ken­der oder un­re­gel­mä­ßi­ger Nutzung, zum Beispiel:

• Webhooks und Event-Ver­ar­bei­tung
• selten genutzten internen Tools
• zeit­ge­steu­er­ten Jobs
• Pro­to­ty­pen und MVPs
• Batch-Jobs mit un­re­gel­mä­ßi­ger Aus­füh­rung
• KI-Inferenz mit schwer vor­her­seh­ba­rer Nachfrage

In diesen Fällen ist Scale-to-Zero ein klarer Vorteil: Wenn keine Anfragen eingehen, werden Res­sour­cen reduziert oder gar nicht erst berechnet. Bei dauerhaft hoher Aus­las­tung kann sich die Rechnung jedoch umkehren. Läuft ein Dienst rund um die Uhr unter kon­stan­ter Last, sind Container, Ku­ber­netes-Cluster oder virtuelle Maschinen oft günstiger und besser planbar.

Deshalb gehört zu Ser­ver­less auch eine FinOps-Per­spek­ti­ve: Kos­ten­li­mits, Budget-Alerts, Mo­ni­to­ring und Con­cur­ren­cy-Limits helfen, un­er­war­tet hohe Cloud-Rech­nun­gen durch un­kon­trol­lier­te Nutzung zu vermeiden.

Ser­ver­less Computing in der Praxis: Wo kommt das Ser­ver­less-Prinzip zum Einsatz?

Ser­ver­less Computing eignet sich besonders für An­wen­dun­gen, bei denen Aufgaben durch Er­eig­nis­se ausgelöst werden, die Last stark schwankt oder Ent­wick­lungs­teams möglichst wenig In­fra­struk­tur betreiben möchten. Anders als früher wird Ser­ver­less dabei nicht nur für einzelne kleine Funk­tio­nen genutzt. Auch voll­stän­di­ge Backends, Da­ten­pipe­lines, Edge-An­wen­dun­gen und KI-Dienste lassen sich als ser­ver­lo­se Ar­chi­tek­tur umsetzen.

Typische Ein­satz­sze­na­ri­en sind:

• API-Backends, Webhooks und Mi­cro­ser­vices: Ser­ver­less-Funk­tio­nen oder Ser­ver­less-Container be­ant­wor­ten HTTP-Anfragen, ver­ar­bei­ten Formulare, in­te­grie­ren externe Dienste oder stellen einzelne Mi­cro­ser­vices bereit. So lassen sich bestimmte Fach­funk­tio­nen, etwa Au­then­ti­fi­zie­rung, Zah­lungs­ab­wick­lung oder Be­nach­rich­ti­gun­gen, un­ab­hän­gig ent­wi­ckeln und skalieren.
• Ser­ver­less Backend: An­wen­dun­gen kom­bi­nie­ren Funk­tio­nen, Au­then­ti­fi­zie­rung, Datenbank, Storage und Messaging zu einem Backend, ohne eigene Server dauerhaft zu betreiben (BaaS).
• Datei- und Me­di­en­ver­ar­bei­tung: Nach dem Upload einer Datei werden au­to­ma­tisch Vor­schau­bil­der erzeugt, Videos trans­ko­diert, Metadaten ex­tra­hiert oder Inhalte klas­si­fi­ziert.
• Daten- und Event-Pipelines: Er­eig­nis­se aus An­wen­dun­gen, Da­ten­ban­ken oder SaaS-Systemen werden in Echtzeit wei­ter­ge­lei­tet, trans­for­miert und ge­spei­chert.
• Aus­füh­rung von Aufgaben nach Zeitplan: Funk­tio­nen können re­gel­mä­ßig aus­ge­führt werden, etwa für Da­ten­be­rei­ni­gung, Reports, Backups oder Syn­chro­ni­sa­tio­nen.
• Sprach­as­sis­ten­ten und Chatbots: Ser­ver­less eignet sich für dia­log­ba­sier­te Systeme, da viele Anfragen kurzlebig, er­eig­nis­ge­trie­ben und stark schwan­kend sind.
• IoT- und Sen­sor­da­ten: Geräte senden Er­eig­nis­se, die serverlos ver­ar­bei­tet, an­ge­rei­chert und ge­spei­chert werden.
• SaaS-In­te­gra­tio­nen: Ser­ver­less-Dienste verbinden CRM-, Shop-, Zahlungs-, Analyse- oder Sup­port­sys­te­me über Events und APIs.

Diese Ein­satz­be­rei­che zeigen, wie breit und viel­fäl­tig das Ser­ver­less-Prinzip in­zwi­schen genutzt wird.

Trends und Ent­wick­lun­gen: Ser­ver­less Computing im Jahr 2026

Ser­ver­less Computing ent­wi­ckelt sich über klas­si­sche Cloud-Funk­tio­nen hinaus. Neben FaaS und BaaS gewinnen vor allem zwei Ansätze an Bedeutung: ser­ver­lo­se KI-Inferenz und die Aus­füh­rung von Funk­tio­nen am Edge. Beide Ent­wick­lun­gen folgen dem klas­si­schen Ser­ver­less-Computing-Grund­prin­zip: Re­chen­leis­tung wird nur dann be­reit­ge­stellt, wenn sie tat­säch­lich benötigt wird.

Ser­ver­less AI und Inference-as-a-Service

Ein wichtiger Ent­wick­lungs­schritt ist der Einsatz von Ser­ver­less Computing für KI-An­wen­dun­gen. Dabei geht es weniger um das Training großer Modelle, sondern vor allem um AI-Inference, also die Anwendung bereits trai­nier­ter Modelle auf neue Eingaben.

Bei Inference-as-a-Service wird ein KI-Modell nicht dauerhaft auf einem eigenen GPU-Server betrieben. Statt­des­sen stellt ein Anbieter die nötige In­fra­struk­tur bereit, lädt oder aktiviert das KI-Modell bei Bedarf und rechnet die Nutzung nach Anfragen, Tokens, Laufzeit oder GPU-Verbrauch ab. Dieses Modell passt gut zu An­wen­dun­gen, bei denen KI-Anfragen un­re­gel­mä­ßig auftreten.

Typische Ein­satz­be­rei­che sind:

• Zu­sam­men­fas­sung von Texten
• au­to­ma­ti­sche Klas­si­fi­ka­ti­on von Support-Tickets
• se­man­ti­sche Suche
• Bild­ana­ly­se
• Support-Chatbots und KI-As­sis­ten­ten
• Ge­ne­rie­rung von Pro­dukt­be­schrei­bun­gen
• Über­set­zung oder Um­for­mu­lie­rung von Inhalten

Doch nicht für jeden KI-Workload ist Ser­ver­less AI au­to­ma­tisch die beste Wahl. Bei dauerhaft hoher GPU-Aus­las­tung, sehr großen Modellen oder besonders strengen La­tenz­an­for­de­run­gen können de­di­zier­te Inferenz-Cluster, Ku­ber­netes oder spe­zia­li­sier­te Model-Serving-Platt­for­men besser geeignet sein.

We­b­As­sem­bly und Edge Computing

Eine weitere wichtige Ent­wick­lung ist der Einsatz von We­b­As­sem­bly (Wasm) im Ser­ver­less- und Edge-Umfeld. Wasm ist ein kompaktes, portables Bi­när­for­mat, das Code aus ver­schie­de­nen Pro­gram­mier­spra­chen in einer iso­lier­ten Lauf­zeit­um­ge­bung ausführen kann. Für Ser­ver­less Ar­chi­tec­tu­re ist das besonders in­ter­es­sant, weil Wasm-Module häufig klein sind, schnell starten und sich gut in iso­lier­ten Lauf­zeit­um­ge­bun­gen ausführen lassen.

Im Edge Computing wird Code möglichst nah an Nut­ze­rin­nen, Nutzern oder Da­ten­quel­len aus­ge­führt. Statt eine Anfrage erst an ein zentrales Re­chen­zen­trum zu senden, kann eine Edge-Plattform Teile der Logik an vielen global ver­teil­ten Stand­or­ten ausführen. Das reduziert Latenzen und ver­bes­sert die Re­ak­ti­ons­zeit.

Typische Edge- und Wasm-Szenarien sind:

• Request-Routing
• Au­then­ti­fi­zie­rung und Zu­griffs­kon­trol­le
• A/B-Tests
• Per­so­na­li­sie­rung
• Bot-Schutz
• Bild- und Content-Trans­for­ma­ti­on
• API-Gateways mit geringer Latenz
• leichte KI- oder Vor­ver­ar­bei­tungs­lo­gik am Netz­werk­rand

Fastly Compute setzt produktiv auf Wasm/Wasmtime als primäre Lauf­zeit­um­ge­bung; Cloud­fla­re Workers un­ter­stützt Wasm ebenfalls. Mit WASI 0.2 (stabil seit 2024) und der geplanten Version 1.0 erhält Wasm eine zunehmend stan­dar­di­sier­te Schnitt­stel­le für Da­tei­sys­tem, Netzwerk und Sys­tem­res­sour­cen und wird damit auch für ser­ver­sei­ti­ge Workloads jenseits einfacher Edge-Funk­tio­nen in­ter­es­sant.

Wasm ersetzt Container dennoch nicht voll­stän­dig. Für komplexe An­wen­dun­gen, große Ab­hän­gig­kei­ten oder lang laufende Dienste bleiben Container weiterhin wichtig. Im Ser­ver­less-Edge-Bereich ist Wasm jedoch eine starke Lauf­zeit­op­ti­on, weil Funk­tio­nen sehr schnell starten und sicher isoliert aus­ge­führt werden können.

Ser­ver­less vs. Container vs. virtuelle Maschinen

Ser­ver­less Computing, Ku­ber­netes-basierter Con­tai­ner­be­trieb und virtuelle Maschinen lösen ähnliche Grund­pro­ble­me, setzen aber auf un­ter­schied­li­che Abs­trak­ti­ons­ebe­nen. Welche Lösung am besten passt, hängt von Workload, Team­struk­tur, Kos­ten­mo­dell und Kon­troll­be­darf ab.

Kurz gesagt: Ser­ver­less Ar­chi­tec­tu­re eignet sich besonders, wenn Ge­schwin­dig­keit, geringe Be­triebs­last und variable Nutzung im Vor­der­grund stehen. Container und Ku­ber­netes sind oft besser, wenn An­wen­dun­gen komplexer, lang­le­bi­ger oder platt­form­über­grei­fend stan­dar­di­siert betrieben werden sollen. Virtuelle Maschinen bleiben sinnvoll, wenn maximale Kontrolle, spezielle Be­triebs­sys­tem­an­for­de­run­gen oder Legacy-An­wen­dun­gen ent­schei­dend sind.