Serverless verspricht eine Welt ohne Server — Sie bezahlen nur für die tatsächliche Rechenzeit, kein Infrastrukturmanagement, automatische Skalierung bis ins Unendliche. Im Jahr 2018 haben wir zwei dominante Plattformen: AWS Lambda und Azure Functions. Nach einem Jahr Produktionsbetrieb auf beiden teilen wir unsere Erfahrungen.
Was Serverless ist und was nicht¶
Serverless bedeutet nicht, dass es keine Server gibt — es bedeutet, dass Sie sie nicht verwalten. Der Provider verwaltet die Infrastruktur, Sie liefern Code in Form von Funktionen. Jede Funktion verarbeitet ein Event — HTTP-Request, Queue-Nachricht, Datenbankänderung.
Serverless ist nicht für alles geeignet. Lang laufende Prozesse, WebSocket-Verbindungen oder Anwendungen, die konsistent niedrige Latenz erfordern, sind bessere Kandidaten für Container. Serverless glänzt bei Event-Driven Workloads mit unvorhersehbarem Traffic.
AWS Lambda — Der Serverless-Veteran¶
AWS Lambda hat die Serverless-Revolution 2014 gestartet. Im Jahr 2018 bietet es:
- Runtime: Node.js 8.10, Python 3.6, Java 8, Go 1.x, C# (.NET Core 2.0)
- Memory: 128 MB – 3 GB (CPU skaliert proportional)
- Timeout: max. 5 Minuten (für die meisten Anwendungsfälle ausreichend)
- Integration: API Gateway, S3, DynamoDB, SQS, SNS, Kinesis, Step Functions
Lambdas größter Vorteil ist das Ökosystem. Jeder AWS-Service kann eine Lambda-Funktion auslösen. Step Functions ermöglichen die Orchestrierung komplexer Workflows. SAM (Serverless Application Model) vereinfacht das Deployment.
Azure Functions — Microsoft im Serverless-Spiel¶
Azure Functions sind 2016 auf den Markt gekommen und holen schnell auf:
- Runtime: C#, JavaScript, F#, Java (Preview), Python (experimentell)
- Durable Functions: zustandsbehaftete Orchestrierung — das hat Lambda nicht nativ
- Binding-Modell: deklarative Input/Output Bindings sparen Boilerplate-Code
- Hybrid: Azure Functions Runtime läuft auch on-premise (Kubernetes)
// Azure Functions — Durable orchestration
[FunctionName("OrderProcessing")]
public static async Task RunOrchestrator(
[OrchestrationTrigger] DurableOrchestrationContext ctx)
{
var order = ctx.GetInput<Order>();
await ctx.CallActivityAsync("ValidateOrder", order);
await ctx.CallActivityAsync("ChargePayment", order);
await ctx.CallActivityAsync("ShipOrder", order);
await ctx.CallActivityAsync("SendConfirmation", order);
}
Cold Start — Der Elefant im Raum¶
Cold Start ist der größte Schmerzpunkt von Serverless. Wenn eine Funktion länger nicht aufgerufen wurde, muss der Provider einen neuen Container starten. Wir haben gemessen:
- AWS Lambda (Node.js): 150–400 ms Cold Start
- AWS Lambda (Java): 3–8 Sekunden (JVM-Startup)
- Azure Functions (C#): 500 ms – 2 s (Consumption Plan)
- Azure Functions (C#): ~0 ms (Premium Plan — vorgewärmte Instanzen)
Für API-Endpoints, bei denen Benutzer auf Antworten warten, ist Cold Start ein Problem. Lösungen: Warm-up Pinging (CloudWatch Scheduled Events rufen die Funktion alle 5 Minuten auf) oder Wechsel zu Provisioned Concurrency (Lambda) / Premium Plan (Azure).
Preise — Tatsächliche Kosten¶
Beide Provider rechnen per Invocation + per GB-Sekunde ab:
- AWS Lambda: $0,20 / Million Invocations + $0,00001667 / GB-s
- Azure Functions: $0,20 / Million Invocations + $0,000016 / GB-s
- Free Tier: beide bieten 1M Invocations + 400K GB-s monatlich kostenlos
Für niedrigen bis mittleren Traffic ist Serverless dramatisch günstiger als EC2/VM-Instanzen. Unser API-Backend, das 2M Requests monatlich verarbeitet, kostet auf Lambda $12/Monat. Eine gleichwertige EC2-Instanz würde ~$50/Monat kosten.
Vorsicht bei High-Throughput-Szenarien — bei 100M+ Invocations monatlich wird Serverless teurer als dedizierte Container.
Monitoring und Debugging¶
Serverless verändert die Art, wie Sie Anwendungen debuggen. Sie haben keinen SSH-Zugang zu Servern, keine lokalen Logs. Sie brauchen:
- Distributed Tracing: AWS X-Ray, Azure Application Insights
- Structured Logging: JSON-Logs mit Correlation ID zur Verfolgung von Requests über mehrere Funktionen
- Alerting: CloudWatch Alarms / Azure Monitor für Error Rate, Duration, Throttling
Vendor Lock-in — Ein reales Risiko?¶
Serverless Framework (serverless.com) abstrahiert provider-spezifische Details und ermöglicht Deployment auf AWS, Azure und GCP. In der Praxis stammt jedoch der größte Wert von Serverless aus provider-spezifischen Integrationen (API Gateway + Lambda, Event Grid + Functions). Portabilität ist daher eher theoretisch.
Unsere Empfehlung: Schreiben Sie Business-Logik als reine Funktionen ohne Abhängigkeiten von Provider-SDKs. Der Handler (Einstiegspunkt) ist eine dünne Schicht, die Sie austauschen können. Die Kernlogik bleibt portabel.
Serverless ist produktionsreif — mit Vorbehalten¶
Für Event-Driven Workloads, API-Backends mit variablem Traffic und Data-Processing-Pipelines ist Serverless 2018 eine ausgezeichnete Wahl. Vermeiden Sie es bei latenzempfindlichen Anwendungen und lang laufenden Prozessen. AWS Lambda hat ein breiteres Ökosystem, Azure Functions bieten eine bessere Developer Experience für .NET-Teams. Die Wahl hängt von Ihrem bestehenden Cloud-Provider ab.
Brauchen Sie Hilfe bei der Implementierung?
Unsere Experten helfen Ihnen bei Design, Implementierung und Betrieb. Von der Architektur bis zur Produktion.
Kontaktieren Sie uns