Serverless-Funktionen vs. eigene Microservices

Eine Serverless-Funktion ist eine einzelne deploybare Einheit von Backend-Logik; ein Microservice ist ein vollständiger, eigenständig betriebener Dienst. Dieser eine Satz enthält den gesamten Vergleich im Kleinen – alles andere (Betriebsaufwand, Kostenkurven, Cold Starts, Zustand) folgt daraus, was die Deployment-Einheit ist: eine Funktion, die Sie einer Plattform übergeben, oder ein Dienst, den Sie selbst betreiben.

Das Wichtigste in Kürze

Die Deployment-Einheit im Code

Das hier ist das gesamte Deployment-Artefakt für einen Checkout-Vorgang – eine Funktion, kein Repository pro Dienst, kein Container-Image, keine Pipeline:

// JavaScript / Node.js — the function is the whole deployable
// cloud/main.js — runs on the platform; there is no service to operate
Parse.Cloud.define('checkout', async (request) => {
  const cart = await new Parse.Query('Cart').get(request.params.cartId, {
    sessionToken: request.user.getSessionToken(),
  });
  // …price the cart, reserve stock, write the order…
  return { orderId: cart.id, status: 'confirmed' };
});

// Any client calls it by name — no gateway, container, or pipeline
const result = await Parse.Cloud.run('checkout', { cartId });

// Flutter / Dart — Back4app Flutter SDK
// Calling the function: one named endpoint, no service discovery
final checkout = ParseCloudFunction('checkout');
final response = await checkout.execute(
  parameters: {'cartId': cartId},
);
if (response.success) {
  print(response.result['status']); // confirmed
} else {
  print(response.error?.message);
}

// iOS / Swift — Back4app Swift SDK
// Calling the function: one named endpoint, no service discovery
struct Checkout: ParseCloudable {
    typealias ReturnType = [String: String]
    var functionName: String = "checkout"
    var cartId: String
}

let result = try await Checkout(cartId: cartId).runFunction()
print(result["status"] ?? "") // confirmed

// Android / Kotlin — Back4app Android SDK
// Calling the function: one named endpoint, no service discovery
val params = hashMapOf("cartId" to cartId)
ParseCloud.callFunctionInBackground<Map<String, String>>(
    "checkout", params
) { result, e ->
    if (e == null) {
        Log.i("Checkout", result["status"] ?: "")
    } else {
        Log.w("Checkout", "failed: ${e.code}")
    }
}

Das Microservice-Gegenstück zu diesem Snippet ist ein ganzes Repository: ein HTTP-Server, ein Container-Build, Deployment-Manifeste, Service Discovery, Health Checks, ein Dashboard und eine Rufbereitschaft – noch bevor die erste Zeile Checkout-Logik existiert.

Serverless-Funktionen vs. eigene Microservices

Die Fachliteratur zu Microservices sagt klar, dass die Vorteile dieser Architektur mit erheblicher betrieblicher Reife erkauft werden – automatisiertes Deployment, ausgefeiltes Monitoring, Design für den Fehlerfall. Funktionen lagern genau diese Rechnung an die Plattform aus, weshalb Mike Roberts’ Serverless-Analyse FaaS als Tausch beschreibt: Kontrolle gegen radikal weniger Betriebsaufwand. Keiner der beiden Tauschhandel ist kostenlos; die Frage ist, welchen Preis Ihr Team sich leisten kann.

Was mit einer Anfrage tatsächlich passiert

Achten Sie darauf, was die untere Hälfte hinzufügt, das die obere gar nicht ausdrücken kann: Aufrufe zwischen Diensten, Datenspeicher pro Dienst und ein Gateway – die Koordinationsfläche, auf der die Komplexität von Microservices tatsächlich sitzt. Verteilte Transaktionen, Retries und Teilausfälle zwischen Warenkorb- und Bestell-Dienst sind Ihr Code; im Funktionsmodell ist derselbe Workflow meist eine Funktion und eine Datenbank, und die ereignisgesteuerten Bausteine (Trigger, geplante Jobs) hängen an der Plattform statt an Queues, die Sie selbst betreiben.

Wann Funktionen eine Microservice-Flotte ersetzen – und wann nicht

Die ehrliche Beobachtung hinter dem BaaS-Muster: Die meisten Microservices in einem typischen Produkt sind dünn. Sie validieren Eingaben, setzen eine Regel durch, lesen oder schreiben eine Datenbank und rufen einen Nachbardienst auf – die betriebliche Hülle um diese Logik macht 90 % ihres Gewichts aus. Cloud-Funktionen innerhalb einer BaaS-Plattform streichen diese Hülle: Datenbank, Authentifizierung, Dateispeicher und APIs sind Plattformdienste, sodass jeder “Dienst” auf eine Handvoll Funktionen und Trigger zusammenschrumpft. Teams von einer bis zehn Personen, die Produkte aus CRUD plus Geschäftslogik ausliefern, brauchen selten mehr.

Die Obergrenze ist ebenso ehrlich benannt. Funktionen können kein Empfehlungsmodell hosten, das spezielle Hardware braucht, keinen Video-Transcoder, der eine Stunde läuft, keine speziell abgestimmte WebSocket-Fan-out-Engine und keine Komponente, deren Dauerdurchsatz die Abrechnung pro Aufruf zur teuren Option macht. Überschreitet eine Komponente diese Grenzen, lösen Sie sie als echten Dienst heraus und lassen sie mit den Funktionen zusammenarbeiten – einen nachweislichen Hotspot herauszulösen, ist eine weit günstigere Migration, als eine auf Verdacht zu früh gebaute Flotte zu zerlegen. Das ist dieselbe Lehre, die das Monolith-first-Argument eine Ebene höher vermittelt.

Typische Anwendungsfälle

• Funktionen: APIs und mobile Backends. Anfragegetriebene Logik über einer verwalteten Datenbank – der häufigste Fall und genau der, den BaaS-Plattformen durchgängig abdecken.
• Funktionen: Trigger und Glue-Code. Beim Speichern validieren, beim Upload skalieren, mit einer Drittanbieter-API synchronisieren, nächtliche Jobs ausführen – kurzlebige Reaktionen, für die ein eigener Dienst völlig überdimensioniert wäre.
• Funktionen: schwankender und unbekannter Traffic. Launches, Kampagnen, MVPs – die Skalierung auf null fängt sowohl die Spitze als auch die Flaute ab.
• Microservices: Komponenten mit dauerhaft hoher Last. Suche, Feeds, Preis-Engines – gleichmäßige Last, bei der ständig verfügbare Kapazität günstiger und feiner abstimmbar ist.
• Microservices: besondere Runtimes. Nicht standardmäßige Sprachen, native Abhängigkeiten, GPUs, lang laufende Prozesse.
• Die Hybridlösung. Funktionen für die API und für Ereignisse; ein oder zwei herausgelöste Dienste für die Komponenten, bei denen die Zahlen es verlangen.

Sollten Sie Funktionen oder Microservices bauen? Eine Entscheidungsmatrix

Grenzen und Trade-offs

• Funktionen: Ausführungslimits sind harte Grenzen. Lange Aufgaben müssen in Job-Systeme oder Dienste umziehen – kein noch so geschickter Kniff verlängert einen Timeout sauber.
• Funktionen: Cold Starts und Ketten. Pro Aufruf selten, aber Architekturen, in denen Funktionen Funktionen aufrufen, addieren sie; halten Sie Hot Paths flach.
• Funktionen: Plattformbindung. Die Runtime und ihre APIs gehören der Plattform – ein Open-Source-Fundament, das Sie selbst hosten können, ist die praktische Absicherung gegen Lock-in.
• Microservices: Die Betriebskosten fallen pro Dienst an. Pipelines, Monitoring, versionierte Schnittstellenverträge und Rufbereitschaft wachsen mit der Flotte; diesen Aufwand zu unterschätzen, ist der klassische Fehler.
• Microservices: Probleme verteilter Systeme gibt es vom ersten Tag an. Netzwerkpartitionen, Teilausfälle und dienstübergreifende Konsistenz sind architektonische Konstanten, keine Randfälle.
• Beide: Zustand wird ohnehin ausgelagert. Funktionen erzwingen es, gut betriebene Dienste entscheiden sich dafür. In beiden Designs hält am Ende die Datenbank die Wahrheit, nicht die Rechenschicht.

Serverless-Funktionen und Microservices 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 liefert Back4app die Funktionsseite dieses Vergleichs komplett: Cloud Code führt benannte Funktionen wie checkout oben sowie Datenbank-Trigger und geplante Jobs aus – direkt neben allem, wofür eine Microservice-Flotte überhaupt da ist. So wird aus der Flotte, die die meisten Produkte gebaut hätten, eine Reihe von Funktionen über verwalteten Diensten. Und weil das Fundament Open Source ist und sich selbst hosten lässt, bleibt der Weg zum Herauslösen offen: Wächst eine Komponente über das Funktionsmodell hinaus, kann sie zu einem eigenen Dienst werden, ohne dass Sie die Plattform drumherum aufgeben.