Was ist PaaS (Platform-as-a-Service)?

PaaS ist ein Cloud-Modell, bei dem der Anbieter die Plattform für Ihren Code betreibt, während Sie die Anwendung weiter selbst schreiben und pflegen. Einfach gesagt: Sie mieten die Plattform, aber die App bleibt Ihre. Die NIST-Definition zieht die Grenze präzise — der Anbieter kontrolliert Server, Betriebssysteme und Runtimes, Sie kontrollieren die deployte Anwendung und ihre Daten.

Das Wichtigste in Kürze

Wie die Arbeit mit einem PaaS aussieht

Das typische PaaS-Erlebnis: Deployment mit einem einzigen Befehl, ohne Infrastruktur einzurichten:

# Der typische PaaS-Workflow: Code pushen, die Plattform erledigt den Rest
$ git push platform main
-----> Runtime detected: Node.js
-----> Installing dependencies, building release
-----> Launching web process (2 instances)
       https://my-api.example.app deployed

Was dieser Befehl deployt, ist allerdings immer noch eine vollständige Serveranwendung, die Sie geschrieben haben — Routing, Validierung, Datenbankanbindung, Authentifizierung:

// server.js — auf einem PaaS schreiben und pflegen Sie all das weiterhin selbst
import express from 'express';
const app = express();

app.get('/tasks', async (req, res) => {
  const user = await authenticate(req);            // selbst gebaut
  const tasks = await db.query(                    // ebenso
    'SELECT * FROM tasks WHERE owner = $1 AND done = false',
    [user.id]
  );
  res.json(tasks);                                 // und das auch
});

app.listen(process.env.PORT);

Das ist der Kern des PaaS-Tauschs: Die Infrastruktur verschwindet, aber die Backend-Anwendung — mitsamt jedem Sicherheitspatch, jedem Dependency-Upgrade und jedem Endpoint darin — bleibt Ihre Codebasis.

Die Abstraktionsleiter

Jedes Cloud-Servicemodell beantwortet eine Frage: Wie viel mieten Sie, und wie viel betreiben Sie noch selbst?

Die Aufteilung der Verantwortung, Schicht für Schicht:

Für engere Aufgaben gibt es spezialisierte PaaS-Varianten — Integrationsplattformen, Mobile-Plattformen, Datenbankplattformen, Kommunikationsplattformen —, doch sie alle stehen auf derselben Sprosse: ein verwalteter Ort, an dem die Software läuft oder angebunden wird, die Sie bauen.

PaaS vs. BaaS: der praktische Unterschied

BaaS ist die nächsthöhere Sprosse, und der Unterschied zeigt sich in dem, was Sie nicht schreiben. Der Aufgabenlisten-Endpoint oben — Authentifizierungsprüfung, Abfrage, Antwort — wird bei einem BaaS durch einen direkten SDK-Aufruf aus jedem Client ersetzt, wobei die Plattform die Zugriffskontrolle durchsetzt:

// JavaScript / Node.js — Back4app JS SDK
const query = new Parse.Query('Task');
query.equalTo('done', false);
query.descending('createdAt');
const tasks = await query.find();
console.log(`${tasks.length} open tasks`);

// Flutter / Dart — Back4app Flutter SDK
final query = QueryBuilder<ParseObject>(ParseObject('Task'))
  ..whereEqualTo('done', false)
  ..orderByDescending('createdAt');
final response = await query.query();
if (response.success) {
  print('${response.results?.length} open tasks');
}

// iOS / Swift — Back4app Swift SDK
let query = Task.query("done" == false)
  .order([.descending("createdAt")])
query.find { result in
  switch result {
  case .success(let tasks):
    print("\(tasks.count) open tasks")
  case .failure(let error):
    print(error.localizedDescription)
  }
}

// Android / Kotlin — Back4app Android SDK
val query = ParseQuery.getQuery<ParseObject>("Task")
query.whereEqualTo("done", false)
query.orderByDescending("createdAt")
query.findInBackground { tasks, e ->
  if (e == null) {
    Log.d("Tasks", "${tasks.size} open tasks")
  }
}

PaaS vs. Serverless

Die beiden Modelle sind verwandt, aber keine Synonyme. Eine PaaS-App läuft dauerhaft auf Kapazität, die Sie konfigurieren; Serverless-Rechenleistung entsteht pro Ereignis, wird pro Aufruf abgerechnet und skaliert auf null — um den Preis von Cold Starts und Ausführungslimits. In der Praxis verschwimmt die Grenze: Moderne Plattformen ergänzen PaaS-artiges Hosting um Serverless-Funktionen, und eine Serverless-Architektur kann eine komplette API bereitstellen, die ein PaaS als einzelne App gehostet hätte. Entscheidend ist das Traffic-Profil: Gleichmäßige Last spricht für einen ständig laufenden PaaS-Prozess, schwankende Last oder viel Leerlauf für Abrechnung pro Aufruf.

Typische Anwendungsfälle

• Eigene Web-APIs und Dienste. Ein Backend mit Logik, die für fertige Features zu spezifisch ist — Preis-Engines, Marktplätze, interne Tools —, deployt, ohne eigene Server zu besitzen.
• Viele Deployments vereinheitlichen. Teams mit Dutzenden Diensten setzen auf ein PaaS, damit jeder Dienst auf dieselbe Weise gebaut, deployt, geloggt und skaliert wird.
• Weg von selbst verwalteten Servern. Bestehende Serveranwendungen (besonders Twelve-Factor-Apps) ziehen weitgehend unverändert auf ein PaaS um — derselbe Code, keine Betriebssystem-Patches mehr.
• Wo BaaS das PaaS ersetzt: Standard-App-Backends. Besteht das Backend aus Benutzern, Daten, Dateien und Benachrichtigungen, machen fertige Features die Anwendungsschicht überflüssig, die ein PaaS hosten würde — der Normalfall bei mobilen und Web-Produkten.
• Hybrid: eigener Kern im PaaS-Stil, BaaS für den Rest. Manche Teams betreiben einen eigenen Dienst auf einer Plattform, während Benutzerverwaltung, Daten-APIs und Speicher von einem BaaS daneben kommen.

Sollten Sie PaaS oder BaaS wählen? Eine Entscheidungsmatrix

Sind die meisten Anforderungen Standard und nur wenige individuell, ist das kein Grund für PaaS — ein BaaS mit eingebetteter Funktions-Runtime deckt beide Seiten ab, mit weniger Code, den Sie verantworten müssen.

Grenzen und Trade-offs

• Sie verantworten weiterhin eine Anwendung. Framework-Upgrades, Sicherheitspatches in Abhängigkeiten, Authentifizierungsfehler — ein PaaS hostet Ihr Backend, es pflegt es nicht. Genau diese Kosten entfallen bei BaaS, bei PaaS nicht.
• Vendor-Lock-in. Apps, die gegen plattformspezifische Dienste und Deploy-Formate geschrieben sind, lassen sich nur teuer umziehen. Gegenmittel: bei offenen Standards bleiben, containerisieren, Plattformen auf Open-Source-Basis bevorzugen — dieselbe Vorsicht gegenüber Vendor-Lock-in gilt auf jeder Sprosse der Leiter.
• Kosten bei dauerhafter Last. Verwalteter Komfort hat eine Marge; große, gleichmäßige Workloads werden irgendwann auf tieferen Sprossen günstiger — um den Preis, den Betriebsaufwand wieder selbst zu tragen.
• Weniger Kontrolle. Kein Zugriff auf das Betriebssystem, begrenzte Netzwerkoptimierung und Runtime-Versionen nach dem Zeitplan des Anbieters. Compliance-Vorgaben, die Kontrolle über die Infrastruktur verlangen, können das Modell ausschließen.
• Abhängigkeit vom Anbieter. Ausfälle, Preisänderungen und Abkündigungen kommen nach dem Zeitplan des Anbieters, nicht nach Ihrem. Bewerten Sie die Erfolgsbilanz des Anbieters als Teil der Architektur.

PaaS vs. BaaS 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 steht Back4app eine Sprosse über PaaS: Jede App startet mit einem bereits vollständig eingerichteten Backend. Die Lücke bei eigener Logik, die Sie sonst zurück auf ein PaaS ziehen würde, schließt Cloud Code — Serverless-Funktionen, Trigger und geplante Jobs. Und weil der Stack Open Source ist, kehrt sich der Lock-in-Einwand um: Dasselbe Backend lässt sich auf jeder Infrastruktur selbst hosten, sodass der spätere Schritt die Leiter hinunter ohne Neuschreiben möglich bleibt.