Serverless-Architektur verspricht drei Dinge: keine Server, die Sie verwalten müssen, Skalierung, die ohne Ihr Zutun passiert, und eine Rechnung, die sich an der tatsächlichen Nutzung orientiert statt an ungenutzter Kapazität. Für den richtigen Workload liefert sie alle drei. Probleme bekommen Teams dann, wenn sie das als Freibrief lesen, ein komplettes System auf diese Weise zu bauen.
Serverless Computing ist für Teile eines Stacks normal geworden und für den gesamten Stack selten. Die Jahresumfrage 2024 der Cloud Native Computing Foundation ergab, dass 44 % der Organisationen Serverless für einige Anwendungen im Produktivbetrieb einsetzen, sechs Punkte mehr als im Vorjahr, während nur 11 % es für die meisten oder alle Anwendungen nutzen, nach 14 % im Vorjahr. Im selben Zeitraum stieg der Anteil der Organisationen, die Serverless auf absehbare Zeit nicht einsetzen wollen, auf 23 %.
Der größte versteckte Kostenfaktor bei einer Serverless-Entscheidung ist der Aufwand für den Ausstieg. Sobald die Kernlogik auf den proprietären Services eines einzelnen Anbieters liegt, bedeutet ein Umzug, sie um APIs herum neu zu bauen, für die es anderswo kein direktes Äquivalent gibt, und das ist ein Rewrite-Budget, mit dem niemand gerechnet hat.
Redwerk baut beide Arten von Systemen. Unsere Services für Cloud-Anwendungsentwicklung decken die mandantenfähigen Setups, Analytics-Engines und Event-Prozessoren ab, mit denen Serverless gut umgeht, und wir wissen, welche Workloads aus diesem Modell den größten Nutzen ziehen und welche anders besser aufgehoben sind. In diesem Artikel gehen wir durch, wie Serverless funktioniert, wo es sich auszahlt, wo es mehr kostet als es spart, und welche fünf Fragen wir stellen, bevor wir es empfehlen.
Was Serverless-Architektur ist, und was sie nicht ist
Serverless-Architektur ist ein Cloud-Modell, bei dem der Anbieter Ihren Code in zustandslosen, durch Events ausgelösten Containern ausführt und Ihnen nur die Ausführungszeit in Rechnung stellt. Sie passt zu Event-getriebenen Aufgaben, stark schwankendem Traffic und Produkten in der Frühphase. Für Kernlogik, die einen vollständigen, unveränderlichen Audit-Trail braucht, ist sie schlecht geeignet, und für ein komplettes System ist sie selten die richtige Wahl.
Der Mechanismus dahinter ist Function-as-a-Service, kurz FaaS. Sie laden eine Funktion hoch, der Anbieter führt sie in einem kurzlebigen Container aus, wenn ein Event sie auslöst, und danach verschwindet der Container. Sie wählen keine Instanzgröße, patchen kein Betriebssystem und richten keine Autoscaling-Gruppe ein. Die meisten realen Serverless-Cloud-Architekturen kombinieren FaaS mit Backend-as-a-Service, kurz BaaS: Managed Databases, Authentifizierung, File Storage und Message Queues, die der Anbieter ebenfalls betreibt. Ein typischer Stack besteht aus einer Funktion für die Logik, einem Managed-NoSQL-Store für die Daten, einem gehosteten Auth-Service für Identitäten und einem Event-Bus, der alles verbindet.
Der Name verursacht das eine Missverständnis, das man ausräumen sollte. Server existieren weiterhin. Irgendjemand patcht sie, plant ihre Kapazität und weckt einen Engineer, wenn sie ausfallen. Dieser Irgendjemand ist der Cloud-Anbieter und nicht Ihr Team, was ändert, wer die operative Last trägt, aber nicht die Physik. Jeder große Cloud-Anbieter verkauft inzwischen eine solche Plattform, darunter Amazon Web Services mit Lambda, Microsoft Azure mit Azure Functions und IBM mit Cloud Code Engine, das Modell ist also überall dort verfügbar, wo Ihre Infrastruktur schon liegt.
Die echten Vorteile der Serverless-Architektur
Die Vorteile der Serverless-Architektur sind praktischer Natur, und sie wirken am stärksten bei Teams ohne eigenes Plattform- oder DevOps-Team. Jeder davon spart Ihnen entweder Geld oder Engineering-Stunden. Die wichtigsten Vorteile der Serverless-Architektur:
- Kein Infrastrukturmanagement. Kein Provisioning, kein Patchen von Betriebssystemen, keine Kapazitätsplanung für die zugrunde liegende Compute-Schicht. Engineering-Zeit verlagert sich vom Gesundhalten von Servern zum Schreiben von Business-Logik.
- Skalierung, die Sie nicht konfigurieren. Eine Funktion, die zehn Requests pro Minute verarbeitet, verarbeitet auch zehntausend, ohne dass Sie etwas umkonfigurieren. Bei Traffic, den Sie wirklich nicht vorhersagen können, fällt damit eine ganze Klasse von Incidents weg.
- Pay-per-Use-Abrechnung. Berechnet wird die Ausführungszeit, nicht die Kapazität, die nachts ungenutzt bereitsteht. Ein Batch-Job, der vier Minuten pro Tag läuft, kostet ungefähr vier Minuten pro Tag.
- Schnellere Time-to-Market für die passenden Workloads. Wer die Infrastrukturschicht überspringt, spart in einem frühen Build echte Wochen, und das ist am meisten wert, wenn Sie ein Launch-Datum, aber kein Plattform-Team haben.
Die Nutzungsdaten der drei großen Clouds zeigen, wie alltäglich das geworden ist. Die Telemetrie von Datadog über Cloud-Kunden hinweg zeigt: Lambda wird von 65 % der AWS-Kunden genutzt, Cloud Run von 70 % der Google-Cloud-Kunden und App Service von 56 % der Azure-Kunden.
Die Serverless-Trade-offs, die niemand auf die Folie schreibt
Jeder der oben genannten Vorteile ist real. Alles in diesem Abschnitt ist es ebenfalls, und die Präsentationen der Anbieter fallen bei dieser Hälfte meist dünner aus. Diese vier Trade-offs sind die, die in realen Projekten tatsächlich Budget- und Compliance-Probleme verursachen.
Vendor Lock-in. Sobald ein System Lambda für Compute, DynamoDB für Daten, EventBridge für Events und Cognito für Identitäten nutzt, ist der Abschied von AWS keine Migration. Für diese vier Services gibt es auf Azure oder Google Cloud keine direkten Entsprechungen, die Arbeit besteht also darin, Integrationsschicht, Datenmodell und Auth-Flow gleichzeitig neu zu bauen. Diese Entscheidung bewusst zu treffen ist vertretbar, sie zwei Jahre später zu entdecken, wenn eine Übernahme oder eine Beschaffungsentscheidung den Wechsel erzwingt, wird teuer.
Cold Starts, die inzwischen nicht nur Millisekunden, sondern auch Geld kosten. War eine Funktion längere Zeit inaktiv, muss der Anbieter erst eine frische Umgebung aufbauen, bevor Ihr Code laufen kann, und wer den Request gestellt hat, wartet. Diese Pause dauert meist den Bruchteil einer Sekunde, was in einem nächtlichen Report niemandem auffällt und auf einem Bildschirm, auf den jemand schaut, allen.
Seit dem 1. August 2025 taucht diese Wartezeit auch auf der Rechnung auf. AWS berechnet inzwischen die Startphase einer Funktion und bringt damit das häufigste Setup auf denselben Stand wie andere Konfigurationen, die schon vorher so abgerechnet wurden. AWS erklärt, die Auswirkungen seien für die meisten Kunden minimal, weil Starts nur auf einen kleinen Teil aller Requests entfallen. Die Teams, die es spüren, betreiben viele selten genutzte Funktionen, bei denen Starts einen großen Anteil ausmachen. Derselbe Trade-off zeigt sich in der AI-Infrastruktur: AWS Bedrock AgentCore betreibt Agenten auf einem Serverless-Lambda-Modell, das im Leerlauf auf null skaliert und das mit Startverzögerung bei allem bezahlt, worauf ein Mensch wartet.
Observability wird schwieriger. Einen Request zu debuggen, der einen einzigen klar abgegrenzten Service berührt hat, heißt: einen Log-Stream lesen. Einen Request zu debuggen, der sich über neun kurzlebige Funktionen verteilt hat, heißt: neun Log-Streams von Containern korrelieren, die es nicht mehr gibt, weshalb Distributed Tracing nicht länger optional ist. Das ist lösbar, und es ist Arbeit, die ein Monolith einfach nicht erzeugt.
Audit und Compliance sind das schwierigste Problem. Wenn ein Workload einen vollständigen, unveränderlichen Nachweis über jede Operation an regulierten oder sensiblen Daten braucht, macht die kurzlebige und verteilte Natur von Serverless-Funktionen diesen Nachweis schwerer durchgängig zu garantieren als eine einzelne, kontrollierte Logging-Pipeline.
Wann Serverless-Architektur die richtige Wahl ist
Zu wissen, wann Serverless-Architektur sinnvoll ist, ist vor allem eine Frage danach, wo der Workload im Verhältnis zu Ihrem Kernprodukt liegt. Das Muster, das funktioniert, ist Serverless an den Rändern des Systems, für Arbeit, die von Natur aus Event-förmig ist und ein wenig Latenz verträgt. Drei Fälle passen so gut, dass wir Serverless ohne Zögern empfehlen.
Event-getriebene Hintergrundaufgaben und Hilfsfunktionen passen am besten: Bildverarbeitung nach einem Upload, ein nächtlicher Report, ein Webhook-Handler, ein Fan-out von Benachrichtigungen. Keines davon ist der Kern der Anwendung, alle werden ausgelöst statt dauerhaft ausgeführt, und ein paar hundert Millisekunden Startverzögerung schaden niemandem.
Stark schwankender oder unvorhersehbarer Traffic ist der zweite Fall. Wenn Ihre Last eine flache Linie ist, ist reservierte Kapazität meist günstiger. Wenn Ihre Last ein Ticketverkauf, eine Steuerfrist oder ein Kampagnen-Peak ist, dann ist es Verschwendung, das ganze Jahr über für die Spitze zu zahlen, und genau die beseitigt Serverless.
Produkte in der Frühphase sind der dritte Fall. Ein Team, das noch keinen ersten Platform Engineer eingestellt hat, bekommt eine produktionsreife Betriebsschicht, ohne sie selbst bauen zu müssen, und gewinnt damit die Wochen zurück, die sonst vor dem ersten Release in Infrastruktur fließen würden.
Wann wir auf Serverless verzichten würden
Verzichten Sie bei zentraler Anwendungslogik auf Serverless, wenn der Workload einen vollständigen, unveränderlichen Audit-Trail erfordert. Die kurzlebige, verteilte Natur von Serverless-Funktionen macht diesen Trail schwerer zu garantieren als eine einzelne, kontrollierte Logging-Pipeline, und ein Compliance-Gespräch ist ein schlechter Ort für die Worte „schwerer zu garantieren“.
Das kommt in echten Projekten vor. Change & Innovation Agency ist ein zu 100 % nach dem Americans with Disabilities Act (ADA) konformes E-Government-SaaS, das von Sozialbehörden in den gesamten USA genutzt wird, mit Compliance-Anforderungen auf dem Niveau des Gesundheitswesens. Jede Operation, die Fallakten berührt, muss auf Anfrage rekonstruierbar sein, Jahre später, ohne Lücken. Für einen solchen Kern haben wir eine kontrollierte, konventionelle Architektur gewählt, und dieselbe Logik steht hinter dem SaaS-Tech-Stack, den wir wirklich wählen würden.
Dieselbe Logik gilt weit über regulierte Branchen hinaus. Immer wenn Sie genau nachweisen müssen, was mit einem bestimmten Datensatz passiert ist, ist eine Architektur, die Ihnen einen prüfbaren Pfad gibt, mehr wert als eine, die auf null skaliert.
Serverless-Architektur vs. Microservices vs. traditionelle Architektur
Serverless-Architektur vs. Microservices ist der Vergleich, der die meiste Verwirrung stiftet, weil die beiden Begriffe unterschiedliche Fragen beantworten. Bei Serverless geht es darum, wer die Ausführungsumgebung verwaltet. Bei Microservices geht es darum, wie Sie die Anwendung in deploybare Teile zerlegen. Das sind unabhängige Entscheidungen, und jede Kombination der beiden ist möglich, auch ein Serverless-Monolith und eine containerisierte Microservice-Flotte.
Die meisten Systeme, die es wert sind betrieben zu werden, kombinieren am Ende Elemente aller drei Spalten unten, und genau so gehen wir generell an skalierbare Architektur heran. Die gleichen Datadog-Daten stützen das: 66 % der Organisationen, die Serverless-Funktionen nutzen, betreiben auch mindestens einen Container-Orchestrierungsdienst, die realistische Frage lautet also, welche Teile wohin gehören.
Wer die Runtime verwaltet
Der Cloud-Anbieter
Ihr Team, über einen Orchestrator
Ihr Team, von Anfang bis Ende
Wie es skaliert
Automatisch, pro Request
Konfigurierte Regeln, pro Service
Manuell oder vertikal
Wofür Sie zahlen
Nur Ausführungszeit
Reservierte oder zugewiesene Kapazität
Bereitgestellte Kapazität
Cold-Start-Latenz
Ein echter Faktor
Minimal im laufenden Betrieb
Keine
Portabilität zwischen Clouds
Am niedrigsten
Hoch, besonders mit Kubernetes
Am höchsten
Aufwand für den Audit-Trail
Am höchsten
Mittel
Am niedrigsten
Beste Passung
Event-getriebene, stark schwankende, unterstützende Aufgaben
Kern-Services bei hoher Last
Stabile, eng gekoppelte, regulierte Kernsysteme
Best Practices für Serverless-Architektur, wenn Sie diesen Weg gehen
Die Best Practices für Serverless-Architektur, die wirklich zählen, sind die, die verhindern, dass aus den oben genannten Trade-offs Incidents werden. Alle vier sind am Projektstart günstig einzuführen und teuer, wenn man sie in ein bereits produktives System nachrüstet. Wir wenden sie auf jede Serverless-Komponente an, die wir ausliefern.
- Halten Sie Funktionen klein und auf einen Zweck beschränkt, und halten Sie das Deployment-Paket ebenso klein. Die Startzeit skaliert mit dem, was Sie laden, ein schlankes Paket ist also inzwischen sowohl eine Latenz- als auch eine Kostenoptimierung.
- Entwerfen Sie jede Funktion idempotent. Event-Quellen wiederholen Zustellungen, und Duplikate sind der Normalfall statt die Ausnahme, dasselbe Event zweimal zu verarbeiten muss also dasselbe Ergebnis liefern wie einmal.
- Zentralisieren Sie Logging und Distributed Tracing ab Tag eins. Correlation IDs, die durch jede Funktion laufen, und ein einziges Ziel für Logs kosten am Projektstart einen Nachmittag und nach einem Incident Wochen.
- Begrenzen Sie die Bindung an proprietäre Services, wo Portabilität einen geschäftlichen Wert hat. Business-Logik in schlichtem Code zu halten und Anbieter-Services hinter einem dünnen Interface zu kapseln, erhält die Option zum Wechsel, ohne das Modell aufzugeben.
Wie Sie entscheiden, ein praktisches Framework
Fünf Fragen klären die meisten Serverless-Entscheidungen, und es sind dieselben fünf, die wir in einem Architekturgespräch durchgehen, bevor wir etwas empfehlen. Beantworten Sie sie für jeweils einen Workload, denn der Kern Ihres Produkts und die Arbeit rundherum fallen meist unterschiedlich aus.
- Welche Form hat der Traffic? Konstant und vorhersehbar spricht für reservierte Kapazität. Stark schwankend, saisonal oder unbekannt spricht für Serverless.
- Welche Audit- und Compliance-Anforderungen gelten? Wenn für diesen Workload ein vollständiger, unveränderlicher Trail Pflicht ist, halten Sie ihn von Serverless fern.
- Welche Größenordnung erwarten Sie in zwei bis drei Jahren? Eine Abrechnung pro Request, die bei einer Million Aufrufen pro Monat günstig ist, sollten Sie auch für fünfzig Millionen durchrechnen.
- Welche DevOps-Kapazität haben Sie tatsächlich im Haus? Kein Plattform-Team ist ein starkes Argument für Serverless. Ein erfahrenes Plattform-Team verkleinert den Unterschied deutlich.
- Wie zentral ist dieser Workload für das Produkt? Unterstützende und Event-getriebene Aufgaben passen von Natur aus. Das System of Record meist nicht.
Wenn zwei oder drei dieser Antworten unsicher sind, lohnt es sich, diese Unsicherheit vor dem Build zu klären. Unsere Services für funktionale Spezifikationen gibt es genau dafür: eine nüchterne Architekturprüfung zuerst auf Papier.
Die meisten starken Architekturen sind Hybride
Serverless ist keine Alles-oder-nichts-Entscheidung, und wer es als eine behandelt, zahlt am Ende entweder für ungenutzte Kapazität, die niemand gebraucht hat, oder erklärt eine Lücke im Audit-Log. Die stärksten Architekturen, die wir seit 2005 über mehr als 250 Plattformen ausgeliefert haben, setzen Serverless dort ein, wo es sich rechnet, bei Event-getriebenen und unterstützenden Aufgaben, und halten zentrale, Compliance-sensible Logik auf traditionellen oder containerisierten Services.
Wenn Sie das für ein reales System abwägen, sprechen Sie mit uns über Ihre Architektur, und wir sagen Ihnen, welche Workloads auf Serverless gehören, welche nicht, und was jeder Weg kostet, bevor Sie Engineering-Zeit in die falsche Form investieren.
FAQ
Was sind die Vorteile und Nachteile der Serverless-Architektur?
Die Vorteile sind: kein Infrastrukturmanagement, automatische Skalierung, Pay-per-Use-Abrechnung und schnellere Lieferung für passende Workloads. Die Nachteile sind: Vendor Lock-in durch proprietäre Services, Cold-Start-Latenz, die AWS seit August 2025 berechnet, schwierigeres Debugging über verteilte Funktionen hinweg und die Schwierigkeit, einen vollständigen, unveränderlichen Audit-Trail zu garantieren.
Wann sollten Sie Serverless-Architektur nicht einsetzen?
Verzichten Sie darauf bei zentraler Anwendungslogik, die einen vollständigen, unveränderlichen Audit-Trail erfordert, bei konstantem und vorhersehbarem Traffic, wo reservierte Kapazität günstiger ist, und bei latenzkritischen, nutzerseitigen Pfaden, in denen Cold Starts nicht akzeptabel sind. Portabilitätsanforderungen sind ein weiterer Grund zur Vorsicht, denn proprietäre Managed Services sind der schwierigste Teil jedes Cloud-Ausstiegs.
Ist Serverless günstiger als der Betrieb von Containern?
Das hängt ganz von der Form des Traffics ab. Serverless ist meist günstiger bei stark schwankenden Workloads mit geringer Auslastung, weil im Leerlauf keine Kosten anfallen. Container sind meist günstiger bei konstanter, hoher Last, wo die Abrechnung pro Request schneller zusammenkommt als reservierte Kapazität. Rechnen Sie Ihre eigenen Aufrufzahlen für die erwartete Größenordnung durch, statt eine Richtung einfach anzunehmen.
Ist Serverless-Architektur dasselbe wie Microservices?
Nein. Serverless beschreibt, wer die Ausführungsumgebung verwaltet, und Microservices beschreibt, wie die Anwendung in unabhängig deploybare Teile zerlegt wird. Sie können einen Monolithen auf Serverless-Funktionen betreiben oder Microservices auf eigenen Servern, und die meisten Produktivsysteme mischen beide Modelle.
Bedeutet Serverless, dass es keine Server gibt?
Nein. Server führen Ihren Code weiterhin aus, aber der Cloud-Anbieter stellt sie bereit, patcht und skaliert sie, statt Ihr Team. Die Veränderung liegt darin, wer die operative Last trägt, nicht darin, ob Server existieren.
Erfahren Sie, wie wir AWE Learning dabei geholfen haben, von einer lokalen Lösung in die Cloud zu migrieren und durch die Implementierung einer skalierbaren SaaS-Lösung Benutzer außerhalb der USA zu erreichen.
