BaaS vs. Serverless: Was ist der Unterschied?

Serverless ist ein Ausführungsmodell, bei dem der Anbieter Code bei Bedarf ausführt; BaaS ist ein Serverless-Modell, das das Backend fertig mitliefert. Der Vergleich ist also kein Entweder-oder zwischen Konkurrenten, sondern eine Frage des Umfangs. FaaS (das Modell, das die meisten mit “Serverless” meinen) führt Funktionen aus, die Sie weiterhin selbst schreiben. BaaS geht weiter und nimmt Ihnen das Schreiben ab: Authentifizierung, Datenbank, Speicher und APIs kommen als fertige Features.

Das Wichtigste in Kürze

Wer schreibt das Backend? Zwei verschiedene Antworten

Bei FaaS bedeutet “Serverless”, dass Ihre eigene Logik in verwalteter, ereignisgesteuerter Rechenumgebung läuft — die Logik selbst schreiben Sie aber weiterhin:

// cloud/main.js — die FaaS-Hälfte: eigene Logik, die Sie weiterhin schreiben
Parse.Cloud.beforeSave('Review', (request) => {
  const stars = request.object.get('stars');
  if (stars < 1 || stars > 5) {
    throw 'Rating must be between 1 and 5';
  }
});

Bei BaaS ändert sich die Antwort: Für Standard-Features ist überhaupt kein Backend-Code zu schreiben. Einen Benutzer zu registrieren — Passwort-Hashing, Session-Tokens, Duplikatprüfung, der E-Mail-Ablauf — ist ein einziger SDK-Aufruf aus jedem Client:

// JavaScript / Node.js — Back4app JS SDK
const user = new Parse.User();
user.set('username', 'ada');
user.set('password', 'correct-horse-battery');
user.set('email', '[email protected]');
await user.signUp(); // hashing, session token, email flow — all managed
console.log(`Signed up: ${user.getUsername()}`);

// Flutter / Dart — Back4app Flutter SDK
final user = ParseUser.createUser(
    'ada', 'correct-horse-battery', '[email protected]');
final response = await user.signUp();
if (response.success) {
  print('Signed up: ${user.username}');
}

// iOS / Swift — Back4app Swift SDK
var user = User()
user.username = "ada"
user.password = "correct-horse-battery"
user.email = "[email protected]"
user.signup { result in
  switch result {
  case .success(let user):
    print("Signed up: \(user.username ?? "")")
  case .failure(let error):
    print(error.localizedDescription)
  }
}

// Android / Kotlin — Back4app Android SDK
val user = ParseUser().apply {
  username = "ada"
  setPassword("correct-horse-battery")
  email = "[email protected]"
}
user.signUpInBackground { e ->
  if (e == null) {
    Log.d("Auth", "Signed up: ${user.username}")
  }
}

Beide Beispiele sind Serverless — Sie stellen keinen Server bereit, patchen und skalieren keinen. Der Unterschied liegt darin, was ausgelagert wurde: FaaS lagert die Runtime aus, BaaS das Backend selbst.

Wie die beiden Modelle zusammenhängen

Die Verwirrung um diesen Vergleich ist eine Frage der Definition, deshalb lohnt es sich, sie ausdrücklich aufzulösen. Die maßgebliche Einordnung von Mike Roberts auf martinfowler.com — später vom Whitepaper der CNCF übernommen — definiert Serverless als Oberbegriff mit zwei Hälften:

Umgangssprachlich ist “Serverless” jedoch oft nur die Kurzform für die FaaS-Hälfte — deshalb wird “BaaS vs. Serverless” gefragt, als wären es Konkurrenten. Formal gilt: Jedes BaaS ist Serverless, aber nicht alles, was Serverless ist, ist ein BaaS.

BaaS vs. FaaS: die praktischen Unterschiede

Typische Anwendungsfälle

• BaaS: komplette App-Backends. Eine mobile oder Web-App, die Konten, Daten, Dateien und APIs braucht — die Standard-80 % jedes Backends —, betrieben ohne Backend-Team.
• BaaS: MVPs unter Zeitdruck. Bei der Validierung eines Produkts sind Wochen an Authentifizierungs- und CRUD-Infrastruktur die Kosten, die Sie einsparen, nicht der Wert, den Sie testen.
• FaaS: ereignisgesteuerter Integrationscode. Webhook-Empfänger, Zahlungsbestätigungen und Synchronisation mit Drittanbietern — kurzlebige Reaktionen ohne umgebendes Backend.
• FaaS: Datenverarbeitung. Bildskalierung beim Upload, Validierung beim Speichern, geplante Aufräum-Jobs — Rechenarbeit, die Sekunden läuft und dann verschwindet.
• Beides: echte Produkte im großen Maßstab. Die Standard-Features laufen auf der BaaS-Schicht; die unvermeidliche eigene Logik — Geschäftsregeln, Integrationen, Jobs — läuft als Funktionen daneben.

Das hybride Muster: warum es selten ein Entweder-oder ist

Die häufigste Produktionsarchitektur ist keine Wahl zwischen den beiden Modellen, sondern eine Kombination. Die BaaS-Schicht übernimmt Benutzer, Daten und Speicher; eine eingebettete FaaS-Runtime übernimmt alles, was die Plattform nicht vorhersehen konnte — die beforeSave-Validierung oben, einen Zahlungs-Webhook, einen nächtlichen Bericht. Deshalb liefern ausgereifte BaaS-Plattformen Funktionen als vollwertiges Feature mit: Die Modelle sind sich ergänzende Schichten, kein Ersatz füreinander. Die Backend-as-a-Service-Schicht legt fest, was Sie nicht schreiben; die Funktionsschicht legt fest, wie der Teil läuft, den Sie doch schreiben.

Sollten Sie BaaS oder FaaS wählen? Eine Entscheidungsmatrix

Wenn Sie in beiden Spalten Häkchen setzen — und das tun die meisten realen Anwendungen —, wählen Sie ein BaaS mit eingebetteter FaaS-Runtime, und Sie müssen sich nicht entscheiden.

Grenzen und Trade-offs

• Cold Starts (FaaS-Hälfte). Ruhende Funktionen zahlen beim ersten Aufruf einen Bereitstellungsaufschlag, von Millisekunden bis zu Sekunden. Die API-Schicht eines BaaS nicht, Ihre eigenen Funktionen aber schon.
• Anpassungsgrenze (BaaS-Hälfte). Fertige Features decken den Normalfall ab; Anforderungen weit außerhalb davon — exotische Authentifizierungsabläufe, ungewöhnliche Query-Engines — können mit der Plattform kollidieren. Die eingebettete Funktionsschicht ist das Überdruckventil, hat aber ebenfalls Grenzen.
• Lock-in (beide Hälften). Proprietäre SDK-Aufrufe und proprietäre Ereignisformate sind gleichermaßen Migrationskosten. Plattformen auf Open-Source-Basis neutralisieren das: Der Stack von Back4app ist Parse Server und jederzeit selbst hostbar.
• Kosten bei dauerhafter Last (beide Hälften). Nutzungsbasierte Preise sind bei schwankendem Traffic unschlagbar und bei konstant hoher Last gnadenlos. Rechnen Sie neu, sobald sich die Nutzung stabilisiert — in beiden Modellen.
• Zustandslosigkeit (FaaS-Hälfte). Funktionen behalten zwischen Aufrufen nichts; der Zustand muss in der Datenbank oder im Cache liegen. Ein BaaS macht das weniger mühsam, weil die verwaltete Datenbank bereits vorhanden ist.

BaaS und Serverless 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. Damit ist Back4app das hybride Muster als Produkt: Die BaaS-Schicht stellt mit jeder App die Grundbausteine einer Serverless-Architektur bereit. Die FaaS-Schicht ist Cloud Code — JavaScript-Funktionen, Datenbank-Trigger und geplante Jobs, die Sie über das Dashboard oder die CLI deployen. Und weil der gesamte Stack darunter Open Source ist, bleiben beide Hälften portabel: Die Abwägung, der Sie tatsächlich entgehen, lautet “verwalteter Komfort vs. künftige Freiheit”.