Was ist Serverless? Die Zukunft der serverlosen Architektur

01Was ist Serverless?

Anders als der Name vermuten lässt, kommt Serverless nicht ohne Server aus. Ihr Code läuft weiterhin auf Maschinen in einem Rechenzentrum; der Unterschied ist, dass nicht Sie, sondern der Cloud-Anbieter diese Maschinen verwaltet. Betriebssystem-Updates, Kapazitätsplanung, Lastverteilung und Hardwareausfälle sind nicht mehr Ihr Problem.

Ein klassischer Server läuft rund um die Uhr, ob Anfragen kommen oder nicht, und wird entsprechend bezahlt. In der serverlosen Architektur startet der Code dagegen nur, wenn er ausgelöst wird, erledigt seine Aufgabe und wird wieder beendet. Ohne Traffic fallen die Kosten gegen null.

Dieser Ansatz gehört zu einem allgemeinen Trend in der Softwarewelt: Infrastrukturkomplexität zu abstrahieren, damit sich das Team nur auf die Geschäftslogik konzentriert. Diese Entwicklungen haben wir in einem größeren Zusammenhang im Beitrag Software-Trends 2026 behandelt.

02Wie funktioniert Function as a Service?

Beim Modell Function as a Service (FaaS) zerlegen Sie Ihre Anwendung in kleine Funktionen, die jeweils eine Aufgabe erfüllen. Jede Funktion wird durch ein Ereignis ausgelöst: eine HTTP-Anfrage, eine Nachricht in einer Warteschlange, eine in den Speicher hochgeladene Datei oder eine zeitgesteuerte Aufgabe.

AWS Lambda, Azure Functions, Google Cloud Functions und Cloudflare Workers sind bekannte Beispiele für dieses Modell. Das Prinzip ist überall gleich; Laufzeitumgebung, Zeitlimits und Preisdetails unterscheiden sich je nach Anbieter.

1. Ein Ereignis tritt ein, zum Beispiel sendet ein Nutzer ein Formular ab.
2. Der Anbieter stellt eine Laufzeitumgebung für die Funktion bereit oder nutzt eine bereits vorhandene.
3. Die Funktion verarbeitet das Ereignis, gibt das Ergebnis zurück und schreibt es in eine Datenbank.
4. Steigt die Nachfrage, führt der Anbieter viele Kopien derselben Funktion parallel aus.

export const handler = async (event) => {
  const ad = event.queryStringParameters?.ad || 'Besucher';
  return {
    statusCode: 200,
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ mesaj: `Merhaba ${ad}` })
  };
};

03Vorteile von Serverless

Die Vorteile von Serverless zeigen sich besonders bei Teams mit schwankendem Traffic, die schnell Produkte auf den Markt bringen wollen.

Denken Sie an eine Buchungsseite, deren Traffic in der Reisesaison sich vervielfacht, oder an einen Shop mit nur wenigen großen Aktionen im Jahr. In klassischen Setups müssen Sie Serverkapazität für den Spitzentag reservieren und zahlen das restliche Jahr umsonst dafür. In der serverlosen Architektur wächst und schrumpft die Kapazität von selbst mit der Nachfrage.

• Automatische Skalierung: Plötzlicher Traffic während einer Aktion lässt sich ohne Kapazitätsplanung abfangen.
• Pay-as-you-go: Für ungenutzte Server zahlen Sie nichts; Anwendungen mit wenig Traffic können sehr günstig sein.
• Weniger Betriebsaufwand: Patches, Updates und die Hardware-Überwachung liegen beim Anbieter.
• Schnelle Entwicklung: Das Team konzentriert sich auf Geschäftslogik statt Infrastruktur, neue Funktionen sind schneller fertig.
• Hohe Verfügbarkeit gehört bei den meisten Plattformen zum Standard.

04Grenzen und Nachteile

Serverless ist keine Wunderlösung. Für manche Workloads ist es ideal, für andere kann es teurer und komplizierter sein als ein klassischer Server.

Kaltstart

Eine Funktion, die lange nicht aufgerufen wurde, wird bei der ersten Anfrage von Grund auf gestartet; das nennt man Kaltstart (Cold Start). Für die meisten Aufgaben spielt diese Verzögerung keine Rolle, bei Seiten mit Echtzeit-Antwort kann sie aber spürbar sein. Hier macht die Schlankheit der Laufzeitumgebung den Unterschied; deshalb sind die kompilierten Sprachen, die wir im Beitrag Was ist Rust vorstellen, in der Serverless-Welt interessant.

Zeit- und Ressourcenlimits

Laufzeit, Arbeitsspeicher und Paketgröße von Funktionen sind begrenzt. Bei AWS Lambda darf ein Aufruf beispielsweise höchstens 15 Minuten dauern. Datenverarbeitung über Stunden oder Aufgaben mit dauerhaft offener Verbindung passen nicht zu diesem Modell.

Abhängigkeit vom Anbieter

Funktionen werden oft eng mit den Warteschlangen-, Speicher- und Datenbankdiensten des Anbieters verzahnt. Das erschwert einen späteren Umzug auf eine andere Plattform. Das nennt man Vendor Lock-in, und es muss bei der Architekturentscheidung unbedingt berücksichtigt werden.

Planbarkeit der Kosten

Was bei geringem Traffic günstig ist, kann bei dauerhaft hohem Traffic teurer werden als ein fester Server. Für Szenarien wie eine fehlerhafte Schleife, die Millionen von Aufrufen erzeugt, sind Budgetwarnungen unverzichtbar. Hinzu kommen Netzwerkverkehr, Log-Speicherung und die Gebühren angebundener Dienste, die die Gesamtrechnung erhöhen.

05Serverless und klassischer Server im Vergleich

Die richtige Wahl hängt vom Charakter des Workloads ab. Die folgende Tabelle fasst die allgemeinen Tendenzen zusammen; für eine verbindliche Entscheidung sollten Sie mit echten Traffic-Daten rechnen.

06Wofür eignet sich Serverless?

Am effizientesten ist Serverless bei ereignisgesteuerten, kurzen Aufgaben. Im digitalen Alltag eines Unternehmens gibt es davon mehr, als man denkt.

• Formularübermittlungen verarbeiten und E-Mails oder Benachrichtigungen versenden.
• Hochgeladene Produktbilder automatisch skalieren und in WebP umwandeln.
• Webhooks von Zahlungs-, Versand- und Marktplatzsystemen entgegennehmen; diese Abläufe sind Teil von Projekten zur E-Commerce-Integration.
• Nachts laufende Aufgaben für Reporting, Backup und Bereinigung.
• Formular- und Zähler-Funktionen von Projekten zum Landingpage-Design, die in Aktionsphasen plötzlichen Traffic erhalten.
• Routing- und Personalisierungsregeln, die nah am Browser am Netzwerkrand (Edge) laufen.

07Serverless und Performance

Serverlose Funktionen lassen sich in verschiedenen Regionen der Welt verteilen und können deshalb nah am Nutzer antworten. Vor allem Dienste am Netzwerkrand liefern in Kombination mit statischen Websites sehr schnelle Erlebnisse.

Geschwindigkeit hängt aber nicht an einer einzigen Schicht. Seitengewicht, Bildoptimierung, Caching und Datenbankabfragen wirken mindestens so stark wie die Infrastruktur. Die Speed- und Performance-Optimierung betrachtet das Ganze und zielt auf die Core-Web-Vitals-Werte (LCP ≤ 2,5 s, INP ≤ 200 ms, CLS ≤ 0,1).

Auch die Wasm-Module aus unserem Beitrag Was ist WebAssembly kommen in Funktionen am Netzwerkrand immer häufiger zum Einsatz; ihr leichter und schneller Start verringert das Kaltstart-Problem.

08Die richtige Architektur für Unternehmen

Für ein Unternehmen lautet die eigentliche Frage nicht “Serverless oder nicht?”, sondern “Welche Architektur ist für diesen Workload zuverlässiger und nachhaltiger?”. Über die Architektur sollten nicht Trends entscheiden, sondern Traffic-Muster, Budget, Teamkompetenz und Wachstumsplan.

Kernprozesse wie Bestellung, Lagerbestand und Rechnung laufen in der Regel besser in einer berechenbaren, dauerhaft laufenden Struktur. Nebenaufgaben wie Bildverarbeitung, Benachrichtigungen und Reporting lassen sich in Serverless-Funktionen auslagern. Auch in den Projekten rund um das Shopsystem, die integrierten Lösungen und die Softwarelösungen von Aurora wird die Architektur nach diesem Gleichgewicht je nach Bedarf aufgebaut.