Katalog
concept#Architektur#Cloud#DevOps#Observability#Plattform

Serverless Architecture

Architekturparadigma, bei dem Anwendungen auf verwalteten Cloud-Diensten und ereignisgesteuerten Funktionen laufen, ohne Serverinfrastruktur zu verwalten.

Serverless Architecture beschreibt ein Cloud-natives Architekturparadigma, bei dem Anwendungen auf vollständig verwalteten Diensten und ereignisgesteuerten Funktionen laufen, ohne Serverinfrastruktur zu verwalten.
Etabliert
Mittel

Klassifikation

  • Mittel
  • Technisch
  • Architektur
  • Fortgeschritten

Technischer Kontext

API Gateway / Load BalancerManaged Datenbanken (z. B. DynamoDB, Cloud SQL)Observability-Tools (Tracing, Logs, Metrics)

Prinzipien & Ziele

Design für lose Kopplung und kurze Ausführungszeiten.Behandle Funktionen als unveränderliche, isolierte Deployables.Instrumentiere Observability und Kostenmetriken von Anfang an.
Umsetzung
Unternehmen, Domäne, Team

Use Cases & Szenarien

Kompromisse

  • Unerwartete Kosten bei fehlerhafter Skalierung oder Hotloops.
  • Schwierigkeiten bei verteiltem Tracing und Debugging.
  • Sicherheitsrisiken durch falsch konfigurierte Managed-Services.
  • Funktionen klein und single-responsibility halten.
  • Idempotenz und klare Retry-Strategien implementieren.
  • Kostenmetriken instrumentieren und Limits setzen.

I/O & Ressourcen

  • Definierte Ereignisquellen und Trigger
  • Minimaler Funktionscode mit klaren Interface-Verträgen
  • Managed-Dienste für Persistenz, Auth und Messaging
  • Skalierende Funktionen als Deployable-Artefakte
  • Metriken zu Latenz, Kosten und Fehlern
  • Integrierte Observability- und Alarmierungspipelines

Beschreibung

Serverless Architecture beschreibt ein Cloud-natives Architekturparadigma, bei dem Anwendungen auf vollständig verwalteten Diensten und ereignisgesteuerten Funktionen laufen, ohne Serverinfrastruktur zu verwalten. Es reduziert Betriebsaufwand und ermöglicht elastische Skalierung, erfordert aber neues Designdenken zu Kaltstarts, Abhängigkeiten und Observability. Gegenüber traditionellen Architekturen verändert sich auch das Kostenmodell und es entstehen Trade-offs bezüglich Ausführungsdauer, Kosten und Anbieterbindung.

✔

  • Reduzierter Betriebsaufwand durch Managed-Services.
  • Automatische, feingranulare Skalierung nach Bedarf.
  • Kostenmodell pay-per-use für unregelmässige Lasten.

✖

  • Kaltstart-Latenzen bei selten genutzten Funktionen.
  • Eingeschränkte Laufzeit oder Resourcen pro Ausführung.
  • Anbieterbindung durch proprietäre Dienste und APIs.

  • Kaltstart-Latenz

    Zeit zwischen Funktionsaufruf und voll handlungsfähiger Ausführung.

  • Kosten pro Anfrage

    Durchschnittliche Abrechnungskosten pro Funktionseinladung oder API-Call.

  • Fehlerrate / Retries

    Anteil fehlgeschlagener Ausführungen und Anzahl automatischer Wiederholungen.

Web-API mit AWS Lambda

API-Endpunkte werden durch Lambda-Funktionen bedient; API Gateway steuert Authentifizierung und Ratenbegrenzung.

Bildverarbeitungspipeline in Functions

Upload löst Funktion aus, die Bild transformiert und in object storage ablegt; Verarbeitung skaliert mit Eingangsrate.

Scheduled Report Generation

Geplante Lambda-Funktionen erzeugen Berichte und liefern Ergebnisse per Push an Speicher oder Benachrichtigungssysteme.

1

Architektur-Workshop durchführen und Use-Cases auswählen.

2

Proof-of-Concept mit einem kritischen Pfad implementieren.

3

Observability, Kostenalarme und Sicherheitsrichtlinien integrieren.

⚠️ Technische Schulden & Engpässe

  • Versteckte Abhängigkeiten zu provider-spezifischen Diensten.
  • Unzureichende Testabdeckung für asynchrone Prozesse.
  • Monolithe, die später schwer in Funktionen zu zerteilen sind.
KaltstartsVendor-Lock-InObservability
  • Migration ohne Re-Design: Lift-and-Shift monolithischer Services in einzelne Funktionen.
  • Intensive Low-Latency-Anwendungen, die von Kaltstarts stark leiden.
  • Unkontrollierte kostenintensive Events, die durch Fehlkonfiguration entstehen.
  • Unterschätzen der Gesamtbetriebskosten trotz pay-per-use.
  • Fehlende End-to-End-Traces über mehrere Managed-Dienste.
  • Nicht getestete Providerszenarien bei Ausfallzeiten.
Cloud-Architektur und ServiceauswahlAsynchrones Design und Event-ModellierungObservability, Monitoring und Kostenanalyse
Skalierbarkeit bei variablen LastenMinimierung operativer AufwändeSchnelle Time-to-Market
  • • Maximale Ausführungszeit pro Funktion (Provider-Limit)
  • • Beschränkte native Resourcen (CPU/Memory)
  • • Netzwerk-Latenz zu verwalteten Diensten