Serverless
Ein Cloud-Computing-Modell, bei dem der Cloud-Anbieter die Server-Infrastruktur vollständig verwaltet – Entwickler deployen nur ihren Code, der bei Bedarf ausgeführt wird.
Die Verzögerung beim ersten Aufruf einer Serverless-Funktion oder eines skalierten Services – wenn Container oder VMs erst gestartet werden müssen.
Cold Start ist die Verzögerung beim ersten Request, wenn ein Service erst hochgefahren werden muss. Bei Serverless passiert das nach jeder Inaktivitätsphase.
Der Ablauf:
Warm Start (Instanz läuft bereits):
Request ──► Handler ──► Response
~10ms
Cold Start (Instanz muss starten):
Request ──► Container Start ──► Runtime Init ──► Code Load ──► Handler ──► Response
~200ms ~100ms ~50ms ~10ms
════════════════════════════════════════════════════════
~360ms total
Cold Start Zeiten nach Runtime:
| Runtime | Typischer Cold Start | Anmerkung |
|---|---|---|
| Rust/Go | 50-100ms | Kompiliert, klein |
| Python | 100-300ms | Interpreter-Start |
| Node.js | 100-300ms | V8-Start |
| Java | 1-5 Sekunden | JVM + JIT |
| .NET | 500ms-2s | CLR-Start |
1. Container/MicroVM starten
└── Image pullen (wenn nicht gecached)
└── Netzwerk konfigurieren
└── Filesystem mounten
2. Runtime initialisieren
└── Interpreter/VM starten
└── Dependencies laden
3. Anwendungscode laden
└── Handler-Funktion importieren
└── Globale Initialisierung
4. Request verarbeiten
└── Eigentliche Logik
1. Provisioned Concurrency (AWS Lambda):
# serverless.yml
functions:
api:
handler: handler.main
provisionedConcurrency: 5 # 5 warme Instanzen
2. Warmup-Requests:
# CloudWatch Event alle 5 Minuten
import json
def handler(event, context):
# Warmup-Request erkennen
if event.get("source") == "warmup":
return {"statusCode": 200, "body": "warm"}
# Normale Logik
return process_request(event)
3. Kleinere Deployments:
# ❌ Schlecht: Alles importieren
import pandas as pd
import numpy as np
import tensorflow as tf
import boto3
# ... 500MB Dependencies
# ✅ Besser: Lazy Loading
def handler(event, context):
if event["type"] == "ml":
import tensorflow as tf # Nur wenn nötig
return ml_inference(event)
else:
return simple_response(event)
4. Schnellere Runtimes:
Java → GraalVM Native Image
Python → Rust/Go für kritische Pfade
Node.js → Bun oder Deno
# Problem: Modell bei jedem Cold Start laden
def handler(event, context):
model = load_model("s3://bucket/model.pkl") # 5 Sekunden!
return model.predict(event["data"])
# Lösung: Globale Initialisierung
model = None
def handler(event, context):
global model
if model is None:
model = load_model("s3://bucket/model.pkl")
return model.predict(event["data"])
# Noch besser: Model in Container-Image einbetten
import time
def handler(event, context):
# Cold Start erkennen
is_cold = not hasattr(handler, "_initialized")
if is_cold:
handler._initialized = True
handler._start_time = time.time()
# Metriken loggen
print(json.dumps({
"cold_start": is_cold,
"init_duration_ms": context.get("initDuration", 0)
}))
return process(event) Cold Start ist wie ein Auto im Winter: Der erste Start dauert länger, weil der Motor kalt ist. Danach läuft alles flüssig – bis du den Motor wieder abstellst und er auskühlt.
Erste Anfrage nach Inaktivität ist langsamer
Ursache: Container/VM muss gestartet, Code geladen werden
Besonders relevant bei Serverless (Lambda, Cloud Functions)
Serverless Functions
Lambda, Cloud Functions haben Cold Starts nach Inaktivität
Scale-to-Zero
Kubernetes Pods die auf 0 skaliert wurden
ML-Inference
Modell muss erst in GPU-Speicher geladen werden
JVM-Anwendungen
JIT-Kompilierung beim Start
Python/Node.js: 100-500ms. Java: 1-5 Sekunden. Mit Container: +1-2 Sekunden. ML-Modell laden: Sekunden bis Minuten je nach Größe.
Provisioned Concurrency, regelmäßige Warmup-Requests, kleinere Deployments, schnellere Runtimes (Go, Rust statt Java), oder kein Scale-to-Zero.
Nein. Cloudflare Workers: fast keine Cold Starts (V8 Isolates). AWS Lambda: 100ms-5s. Google Cloud Run: ähnlich Lambda. Architektur macht den Unterschied.