Zum Hauptinhalt springen

Serverless Architecture

Einleitung​

Serverless ist kein Marketingbegriff für „ohne Server“, sondern ein Cloud-natives Betriebs- und Architekturmodell, bei dem Infrastruktur-Provisionierung, Skalierung und Wartung vollständig vom Cloud-Provider übernommen werden.

Anwendungen bestehen aus:

  • kleinen, isolierten Funktionen (FaaS)
  • oder vollständig verwalteten Cloud-Services

Ausführung erfolgt ereignisgetrieben und skaliert automatisch – inklusive Scale-to-Zero.

Einordnung​

Serverless ist primär ein Betriebsmodell, nicht ein fachlicher Schnitt.

Es beschreibt:

  • Wie Code ausgeführt wird
  • Wie Infrastruktur bereitgestellt wird
  • Wie Skalierung funktioniert
  • Wie Abrechnung erfolgt

Serverless kann kombiniert werden mit:

  • Microservices
  • Event-Driven Architecture
  • API-First-Ansätzen
  • Modularen Monolithen

Es ist kein Ersatz für Architektur – sondern ein Runtime-Modell.

Prinzipdiagramm (vereinfachte Darstellung)​

Ursprung / Historie​

  • 2014: AWS Lambda markiert Durchbruch von FaaS
  • Parallel: Aufstieg von Managed Services (DynamoDB, S3, Pub/Sub)
  • 2016–2020: starke Verbreitung durch Cloud-native Trends

Serverless entwickelte sich von reinen Funktionen zu einem Ökosystem aus Managed Services, das:

  • Compute
  • Storage
  • Messaging
  • Auth
  • API-Gateways

vollständig abstrahiert.

Zielsetzung​

Serverless adressiert primär betriebliche Probleme:

  • Reduktion von Infrastruktur-Management
  • automatische horizontale Skalierung
  • Pay-per-Use-Kostenmodell
  • schnelle Bereitstellung kleiner Funktionseinheiten

Es verschiebt Komplexität von Infrastruktur zu Plattform-Integration.

Charakteristika​

1. Event-getriebene Ausführung​

Typische Trigger:

  • HTTP-Requests
  • Queue-Nachrichten
  • Storage-Events
  • Cron-Jobs
  • Streaming-Events

Die Funktion existiert nur während ihrer Ausführung.

2. Stateless Compute​

Funktionen sind:

  • kurzlebig
  • zustandslos
  • isoliert

Persistenz erfolgt über externe Managed Services.

3. Automatische Skalierung​

Skalierung:

  • erfolgt transparent
  • ohne manuelle Provisionierung
  • oft bis sehr hohe Parallelität
  • inklusive Scale-to-Zero

4. Managed Infrastructure​

Provider übernimmt:

  • Betriebssystem-Patching
  • Container-Management
  • Skalierungslogik
  • Infrastruktur-Health

Teams fokussieren sich auf Anwendungslogik.

5. Feingranulare Deployment-Einheiten​

Deployment erfolgt häufig:

  • pro Funktion
  • pro Event-Handler
  • mit Infrastructure-as-Code

Das ermöglicht schnelle Iteration – erhöht aber Orchestrierungsaufwand.

Vorteile​

Betriebsökonomie​

  • keine Serververwaltung
  • keine Kapazitätsplanung
  • automatische Skalierung

Kostenmodell​

  • nutzungsbasierte Abrechnung
  • besonders effizient bei stark schwankender Last
  • keine Idle-Kosten bei Scale-to-Zero

Time-to-Market​

  • schneller Start ohne Infrastruktur-Setup
  • ideal für Prototypen und neue Features
  • geringe Eintrittsbarriere für kleine Teams

Nachteile / strukturelle Risiken​

1. Cold Starts​

Initiale Latenz bei:

  • niedriger Nutzung
  • neuen Instanzen
  • komplexeren Runtime-Umgebungen

Für latenzkritische Systeme problematisch.

2. Vendor Lock-in​

Serverless ist stark providerabhängig:

  • proprietäre APIs
  • spezifische Event-Modelle
  • Service-spezifische IAM-Konzepte

Portabilität ist eingeschränkt.

3. Verteilte Komplexität​

Viele kleine Funktionen bedeuten:

  • erschwertes Debugging
  • komplexere Observability
  • schwierigere Tracebarkeit
  • Event-Ketten mit indirekter Kontrolle

4. Kostenparadox​

Bei hoher, konstanter Last:

  • kann klassisches Container-Hosting günstiger sein
  • Pay-per-Invocation skaliert finanziell mit Nutzung

Serverless ist nicht automatisch kostengünstig.

5. Architektur-Verlust durch Plattformdenken​

Gefahr:

Teams bauen „Glue Code“ zwischen Managed Services,
ohne klare Domänenarchitektur.

Serverless ersetzt keine saubere Schnittdefinition.

Abgrenzung zu Microservices​

Microservices definieren:

  • fachliche Schnitte
  • Team-Autonomie
  • Datenhoheit

Serverless definiert:

  • Betriebs- und Skalierungsmodell

Man kann:

  • Microservices serverless betreiben
  • oder serverlose Funktionen in einem Monolith-Kontext nutzen

Beides sind unterschiedliche Dimensionen.

Eignung 2026​

Serverless eignet sich besonders für:​

  • stark schwankende Last
  • Event-Driven-Systeme
  • Medien- und Datenverarbeitung
  • Integrationspipelines
  • IoT
  • experimentelle Features

Serverless ist weniger geeignet für:​

  • extrem latenzkritische Systeme
  • dauerhaft hoch ausgelastete Workloads
  • komplexe zustandsbehaftete Prozesse
  • Plattformunabhängigkeitsanforderungen

Organisatorische Implikationen​

Serverless reduziert klassische Ops-Arbeit, erhöht aber Anforderungen an:

  • Observability
  • Monitoring
  • Event-Traceability
  • IAM-Konfiguration
  • Cloud-Kostenkontrolle

Die Rolle verschiebt sich von „Serverbetrieb“ zu „Plattform-Governance“.

Serverless 2026​

Serverless ist etabliert.

Es ist:

  • kein Hype mehr
  • kein Allheilmittel
  • sondern ein spezialisiertes Cloud-Betriebsmodell

Viele Organisationen nutzen hybride Ansätze:

  • Container für Kernservices
  • Serverless für Event-Workloads
  • Managed Services für State

Der Trend geht zu Platform Engineering, nicht zu „reinem Serverless“.

Praxis-Check​

Szenario 1: Medien-Pipeline​

Upload eines Videos triggert:

  • Transcoding-Funktion
  • Thumbnail-Generator
  • Metadaten-Indexierung
  • Event-basierte Benachrichtigungen

Serverless ist hier sehr gut geeignet.

Szenario 2: Hochfrequenz-Trading​

Erfordert:

  • deterministische Latenz
  • garantierte Performance
  • präzise Ressourcensteuerung

Serverless ist hier meist ungeeignet.

Fazit​

Serverless steht für:

Infrastruktur-Abstraktion und elastische Skalierung.

Es reduziert Betriebsaufwand,
verschiebt aber Komplexität in Plattform-Integration und Observability.

Serverless ist kein Architekturparadigma –
sondern ein Betriebsmodell, das bewusst und kontextabhängig eingesetzt werden sollte.