Was ist eine Serverless-Architektur?

Serverless-Architektur ist ein Cloud-Ausführungsmodell, bei dem der Anbieter Ihren Code bei Bedarf ausführt – Sie stellen nie Server bereit und verwalten keine. Server gibt es weiterhin – Sie mieten, patchen und skalieren sie nur nicht mehr selbst. Sie deployen Funktionen; die Plattform stellt Rechenleistung bereit, sobald ein Ereignis eintrifft, und berechnet nur, was tatsächlich läuft.

Das Wichtigste in Kürze

Das Problem, das sie löst

Bei einem klassischen Deployment mieten Sie Kapazität im Voraus: Instanz dimensionieren, Autoscaling konfigurieren, Leerlaufzeit bezahlen, Betriebssystem patchen. Liegen Sie in die eine Richtung daneben, verbrennen Sie Geld; in die andere, verlieren Sie Anfragen genau zur Lastspitze.

In einem Serverless-Modell entfällt dieser gesamte Kreislauf. Sie schreiben eine Funktion, und die Skalierung von null auf Tausende gleichzeitige Ausführungen ist Aufgabe des Anbieters. Das ist der gesamte Backend-Code, der nötig ist, um die Durchschnittsbewertung eines Films serverseitig zu berechnen:

// cloud/main.js — eine Cloud-Code-Funktion auf Back4app
Parse.Cloud.define('averageStars', async (request) => {
  const query = new Parse.Query('Review');
  query.equalTo('movie', request.params.movie);
  const reviews = await query.find();
  const sum = reviews.reduce((acc, r) => acc + r.get('stars'), 0);
  return sum / reviews.length;
});

Keine Express-App drumherum, kein Dockerfile, kein Load Balancer. Die Funktion ist die Einheit des Deployments.

Aufruf von jedem Client

Jedes Client-SDK ruft dieselbe Funktion per Name auf – Transport, Authentifizierung und Skalierung übernimmt die Plattform:

// JavaScript / Node.js — Back4app JS SDK
const params = { movie: 'Inception' };
const rating = await Parse.Cloud.run('averageStars', params);
console.log(`Average rating: ${rating}`);

// Flutter / Dart — Back4app Flutter SDK
final function = ParseCloudFunction('averageStars');
final params = <String, dynamic>{'movie': 'Inception'};
final response = await function.execute(parameters: params);
if (response.success) {
  print('Average rating: ${response.result}');
}

// iOS / Swift — Back4app Swift SDK
ParseCloud.callFunction("averageStars",
                        parameters: ["movie": "Inception"]) { result in
  switch result {
  case .success(let rating):
    print("Average rating: \(rating)")
  case .failure(let error):
    print(error.localizedDescription)
  }
}

// Android / Kotlin — Back4app Android SDK
val params = hashMapOf("movie" to "Inception")
ParseCloud.callFunctionInBackground<Float>("averageStars", params) { rating, e ->
  if (e == null) {
    Log.d("Cloud", "Average rating: $rating")
  }
}

Wie eine Serverless-Anfrage abläuft

Der kritische Zweig ist der Cold Start. Gibt es keine warme Instanz, muss die Plattform eine Runtime bereitstellen, bevor Ihr Code läuft – das dauert je nach Sprache, Codegröße und Abhängigkeiten wenige Millisekunden bis mehrere Sekunden. In der Produktion betrifft das nur einen kleinen Teil der Anfragen, da eine regelmäßig aufgerufene Funktion immer wieder warme Instanzen nutzt – für die meisten APIs vernachlässigbar, auf latenzkritischen Pfaden aber spürbar und ein Grund, warum es Edge-Funktionen und Warm-up-Strategien gibt.

Serverless vs. Container vs. klassische Server

FaaS und BaaS: die zwei Hälften von Serverless

“Serverless” umfasst zwei komplementäre Modelle – eine Unterscheidung, die Mike Roberts’ maßgeblicher Artikel auf martinfowler.com formalisiert hat. Die Trennung lässt sich datieren: Kommerzielle, ereignisgesteuerte Rechenleistung kam 2014 auf den Markt, und innerhalb von zwei Jahren wurde Serverless von einer Forschungsidee zum Produktionsstandard für ereignisgesteuerte Aufgaben – weshalb das Vokabular noch immer jünger wirkt als die Ideen dahinter. FaaS (Functions as a Service) bedeutet, dass Sie weiterhin serverseitige Logik schreiben, diese aber in zustandsloser, ereignisgesteuerter, vollständig verwalteter Rechenumgebung läuft – das Modell der “Cloud-Funktionen”. BaaS (Backend as a Service) geht weiter: Datenbank, Authentifizierung, Dateispeicher und APIs werden selbst als verwaltete Dienste genutzt, sodass der Großteil des Backend-Codes, den Sie sonst geschrieben hätten, ganz entfällt.

Die meisten realen Anwendungen brauchen beides – Funktionen für eigene Logik, verwaltete Dienste für alles andere. Genau diese Kombination bündelt eine BaaS-Plattform. Für einen tieferen Einblick in diese Hälfte des Modells lesen Sie unseren vollständigen Leitfaden zu Backend as a Service.

Typische Serverless-Anwendungsfälle

• APIs und mobile Backends. Der häufigste Fall: anfragegetriebener Traffic, der nachts ruht und beim Launch in die Höhe schießt – genau das Lastprofil, das nutzungsbasierte Abrechnung belohnt.
• Ereignis- und Datenverarbeitung. Ein Bild beim Upload verkleinern, einen Datensatz beim Speichern validieren, eine Änderung mit einem Drittsystem synchronisieren – kurzlebige Reaktionen auf Ereignisse.
• Geplante Jobs. Nächtliche Reports, Aufräumaufgaben und wiederkehrende Synchronisierungen laufen als per Cron ausgelöste Funktionen, ohne dass zwischen den Läufen ein Server bereitsteht.
• Echtzeit-Features. Chat, Benachrichtigungen und Live-Dashboards kombinieren Serverless-Funktionen mit verwalteter Echtzeit-Infrastruktur statt selbst gebauter WebSocket-Server.
• MVPs und Prototypen. Wer eine Idee validiert, will genau null Zeit in Infrastruktur stecken – Funktion deployen, URL erhalten, ausliefern.
• KI-Agenten und Webhooks. Glue-Code zwischen LLMs, Zahlungsanbietern und SaaS-APIs ist von Natur aus ereignisgesteuert und kurzlebig – ideal für Serverless.

Sollten Sie auf Serverless setzen? Eine Entscheidungsmatrix

Bei den Kosten helfen konkrete Anhaltspunkte: Serverless-Plattformen rechnen pro Anfrage plus verbrauchter Rechenzeit (GB-Sekunden) ab, ohne Vorabverpflichtung – und der kostenlose Tarif von Back4app umfasst 25.000 API-Anfragen pro Monat, genug, um ein echtes MVP für 0 $ zu betreiben, bevor überhaupt eine Skalierungsentscheidung ansteht.

Grenzen und Trade-offs

• Cold Starts. Der erste Aufruf einer inaktiven Funktion zahlt einen Bereitstellungsaufschlag (unter 100 ms bis über eine Sekunde). Gegenmittel: vorgewärmte Parallelität, kleinere Bundles, Edge-Runtimes.
• Ausführungszeitlimits. Funktionen sind für kurze Aufgaben gebaut; Video-Encoding oder stundenlange Batch-Jobs gehören in Container oder Systeme für Hintergrund-Jobs.
• Schwierigeres Debugging und eingeschränkte Observability. Es gibt keinen Server, auf den Sie sich per SSH verbinden könnten. Sie sind auf Logs, Metriken und Tracing der Plattform angewiesen – prüfen Sie diese, bevor Sie sich festlegen.
• Vendor-Lock-in. Funktionen, die gegen proprietäre APIs geschrieben sind, lassen sich nur teuer umziehen. Bevorzugen Sie Plattformen auf Open-Source-Basis – Cloud Code von Back4app läuft auf einem Open-Source-Fundament, das Sie jederzeit selbst hosten können.
• Kosten bei Dauerlast. Nutzungsbasierte Abrechnung ist bei geringer und schwankender Last unschlagbar, kann bei konstant hoher Last aber pauschale Serverpreise übersteigen. Rechnen Sie neu, sobald sich der Traffic stabilisiert.
• Zustandslosigkeit. Funktionen behalten zwischen Aufrufen keinen Speicherzustand; Sitzungs- und Anwendungszustand müssen in einer Datenbank oder einem Cache liegen – eine Designvorgabe, wenn Sie zustandsbehafteten Code portieren.

Serverless-Architektur mit Back4app

Back4app ist eine Open-Source-Plattform für Backend as a Service (BaaS), die eine verwaltete Datenbank, automatisch generierte REST- und GraphQL-APIs, Authentifizierung, Dateispeicher und Serverless-Funktionen mit Cloud Code kombiniert. Sie erhalten beide Hälften auf einer Plattform. Die FaaS-Hälfte ist Cloud Code: JavaScript-Funktionen wie averageStars oben, die Sie über das Dashboard oder die CLI deployen, dazu Datenbank-Trigger und geplante Jobs – kein Gateway, keine IAM-Richtlinien, keine Infrastruktur zu konfigurieren. Die BaaS-Hälfte ist bei jeder Back4app-App bereits bereitgestellt: Datenbank, Benutzerauthentifizierung, Dateispeicher sowie automatisch generierte REST- und GraphQL-APIs. Und weil Back4app auf einem Open-Source-Fundament aufbaut, sind die Funktionen, die Sie schreiben, portabel – Sie können denselben Stack später selbst hosten. Damit entfällt der Lock-in-Einwand, der über anbietergebundenen Serverless-Plattformen schwebt.