- Startseite
- Skills
- Bereitstellung
- Serverless-Deployment
Serverless-Deployment
Auf AWS Lambda, Vercel und Netlify deployen — Serverless-Muster beherrschen ohne Cold-Start-Kopfschmerzen.
Das Problem
Serverless verspricht “deployen und vergessen,” liefert aber Cold Starts, Funktions-Timeouts, Speicherlimits und anbieterspezifische Eigenheiten, die Ihrer lokalen Entwicklungsumgebung in nichts gleichen. Ihre Funktion funktioniert lokal perfekt, scheitert aber unter Last mit mysterioesen Timeout-Fehlern. Zu verstehen, wann Serverless die richtige Wahl ist — und wie seine Einschraenkungen umgangen werden — macht den Unterschied zwischen einer schnellen, guenstigen Architektur und einer teuren, unzuverlaessigen.
Der Prompt
Du bist ein Serverless-Deployment-Experte. Hilf mir meine Anwendung auf einer Serverless-Plattform zu deployen.
ANWENDUNGSDETAILS:
- Funktion: [z.B. REST API, Bildverarbeitung, geplante Jobs, Webhook-Handler]
- Runtime: [z.B. Node.js 20, Python 3.12, Go]
- Abhaengigkeiten: [z.B. leichtgewichtig, schwere ML-Bibliotheken, Datenbankverbindungen]
- Erwarteter Traffic: [z.B. 100 Req/Tag, 10k Req/Stunde, sprunghaft/gleichmaessig]
- Plattform-Praeferenz: [z.B. AWS Lambda, Vercel Functions, Netlify Functions, Cloudflare Workers]
Hilf mir mit:
1. **Architektur-Eignung**: Ist Serverless fuer diesen Workload geeignet?
2. **Funktions-Design**: Wie Funktionen strukturiert werden — Single Responsibility, Shared Layers, Connection Pooling.
3. **Cold-Start-Minimierung**: Plattformspezifische Techniken zur Minimierung von Cold Starts.
4. **Konfiguration**: Optimale Memory-, Timeout- und Concurrency-Einstellungen.
5. **Lokale Entwicklung**: Wie lokal mit serverless-aehnlicher Umgebung entwickelt und getestet wird.
6. **Deployment-Pipeline**: CI/CD fuer Serverless — Infrastructure as Code, Versionierung, Rollback.
7. **Kostenschaetzung**: Projizierte monatliche Kosten basierend auf meinem Traffic-Muster.
Beispielausgabe
Architektur-Eignung: REST API → GUTE Eignung (kurzlebige Requests, variabler Traffic)
Bildverarbeitung → VORSICHT (speicherintensiv, kann 10s-Timeout erreichen)
WebSocket-Server → SCHLECHT geeignet (Serverless kann keine langen Verbindungen halten)
Cold-Start-Minimierung (AWS Lambda + Node.js):
- Mit esbuild buendeln (Paketgroesse von 50 MB auf 2 MB reduzieren)
- Provisioned Concurrency fuer kritische Endpunkte (5 Instanzen = ~15 EUR/Monat)
- Schwere Imports ausserhalb des Handlers (einmal pro Container initialisiert)
- ARM64-Architektur (20% schnellerer Cold Start, 20% guenstiger)
Geschaetzte Kosten: 10k Req/Stunde × 200ms Durchschnitt × 256 MB = ~8 EUR/Monat
Wann einsetzen
Verwenden Sie diesen Skill bei der Evaluation ob Serverless zu Ihrem Workload passt, bei der Migration von traditionellen Servern oder bei der Optimierung eines bestehenden Serverless-Deployments.
Profi-Tipps
- Bundle-Groesse beeinflusst Cold-Start-Zeit direkt — jedes Megabyte an Abhaengigkeiten fuegt 50-100ms zum Cold Start hinzu. Nutzen Sie Tree-Shaking und vermeiden Sie den Import ganzer SDKs.
- Datenbankverbindungen sind die Achillesferse von Serverless — jede Funktionsinstanz oeffnet eigene Verbindungen. Nutzen Sie Connection Pooling (RDS Proxy, PgBouncer).
- Setzen Sie Alarme auf Concurrency-Limits — AWS Lambda hat standardmaessig 1000 gleichzeitige Ausfuehrungen pro Region. Eine ausser Kontrolle geratene Funktion kann Ihr gesamtes Kontingent verbrauchen.
- Lokales Testen ist kein Produktionstest — Offline-Tools simulieren die Umgebung, aber verpassen echte Cold Starts, IAM-Berechtigungen und VPC-Latenz.