Beim traditionellen Hosting-Modell (EC2, DigitalOcean) mieten Sie einen Computer. Sie zahlen 50 €/Monat. Wenn um 3:00 Uhr morgens niemand Ihre Website besucht, bleibt der Computer im Leerlauf. Du zahlst trotzdem. Wenn um 10:00 Uhr 100.000 Menschen zu Besuch kommen, stürzt der Computer ab. Sie verlieren Einnahmen.

Das ist das Dilemma der Kapazitätsplanung. Sie müssen unbedingt überdimensionieren, um Spitzenzeiten bewältigen zu können, was bedeutet, dass Sie in 99 % der Fälle zu viel bezahlen.

Serverlos (FaaS) dreht das Modell um. Sie mieten keinen Computer. Sie laden Code hoch. Sie zahlen pro Aufruf.

0 Besuche = 0,00 €.
1 Million Besuche = AWS führt 1.000 gleichzeitige Funktionen aus. Sie zahlen für genau 1 Million Ausführungssekunden.

Bei Maison Code Paris nutzen wir Serverless nicht nur aus Kostengründen, sondern auch aus Gründen der Betriebsvereinfachung. Wir patchen keine Linux-Kernel. Wir rotieren keine SSH-Schlüssel. Wir konzentrieren uns auf Logik.

Warum Maison Code darüber spricht

Bei Maison Code Paris fungieren wir als das architektonische Gewissen unserer Kunden. Wir übernehmen oft „moderne“ Stacks, die ohne grundlegendes Verständnis für Skalierung gebaut wurden.

Wir diskutieren dieses Thema, weil es einen kritischen Wendepunkt in der technischen Reife darstellt. Die korrekte Implementierung unterscheidet ein fragiles MVP von einer widerstandsfähigen Plattform auf Unternehmensniveau.

Warum Maison Code Serverless First einführt

Wir betrachten Infrastruktur als eine Belastung, nicht als einen Vermögenswert. Jeder von uns verwaltete Server ist ein Server, der kaputt gehen kann. Unsere „Scale-to-Zero“-Philosophie steht im Einklang mit der Gewinn- und Verlustrechnung unserer Kunden:

Effizienz: Wir haben die alten Cron-Jobs eines Kunden von einem dedizierten EC2 für 100 €/Monat nach Lambda migriert. Die Kosten sanken auf 0,12 €/Monat.
Resilienz: Während des Black Friday wurden unsere serverlosen Endpunkte auf 5.000 gleichzeitige Ausführungen ohne einen einzigen Timeout skaliert.
Fokus: Unsere Ingenieure verbringen 100 % ihrer Zeit mit der Geschäftslogik (Preise, Warenkorb, Kasse), nicht mit der Docker-Orchestrierung.

Architektur: Ereignisgesteuerte Muster

Serverlos ist am besten, wenn es asynchron ist. Während Sie eine Standard-API („GET /users“) ausführen können, liegt die wahre Stärke im Event Sourcing.

Das Puffermuster (SQS + Lambda)

Szenario: Sie führen einen Flash Sale durch. 10.000 Benutzer gehen in 1 Sekunde zur Kasse. Wenn Sie Lambda direkt mit Ihrem ERP (SAP/NetSuite) verbinden, machen Sie DDoS zu Ihrem eigenen ERP. Es kann keine 10.000 Verbindungen verarbeiten.

Lösung:

API-Gateway: Akzeptiert die HTTP-Anfrage. Gibt „202 Akzeptiert“ zurück.
SQS (Simple Queue Service): Speichert die Anfrage in einer Warteschlange. Es kann Millionen von Nachrichten enthalten.
Lambda: fragt die Warteschlange ab. Es verarbeitet Nachrichten mit einer kontrollierten Geschwindigkeit (z. B. 50 gleichzeitig).
Ergebnis: Ihr ERP erhält einen stetigen Strom an Bestellungen, keinen Tsunami. Der Benutzer erhält eine schnelle Antwort.

Fehlerbehandlung: Die Dead Letter Queue (DLQ)

Wenn auf einem Node.js-Server eine Anfrage abstürzt, geht sie verloren. In Serverless konfigurieren wir Wiederholungen. AWS Lambda wird eine fehlgeschlagene asynchrone Funktion automatisch zwei Mal wiederholen. Wenn es immer noch fehlschlägt (z. B. ein Fehler im Code), wird das Ereignis in eine Dead Letter Queue (DLQ) verschoben. Ingenieure können die DLQ überprüfen, den Fehler beheben und die Nachrichten „neu senden“. Es gehen keine Daten verloren.

Das Kaltstartproblem

Ressourcen sind nicht kostenlos. Um Geld zu sparen, fährt AWS Ihren Container herunter, wenn er etwa 15 Minuten lang nicht verwendet wurde. Die nächste Anfrage löst einen Kaltstart aus.

AWS weist eine microVM (Firecracker) zu.
Lädt Ihren Code herunter.
Startet Node.js.
Führt Ihren Handler aus.

Latenz: ~300 ms – 1 s (Node.js). ~3s (Java). Auswirkung: Gut für Hintergrundjobs. Schlecht für Checkout-APIs.

Die Lösung: Vercel Edge Runtime (V8-Isolate)

Vercel (und Cloudflare Workers) haben eine neue Laufzeit eingeführt. Anstatt einen vollständigen Node.js-Container (VM + Betriebssystem + Knoten) zu booten, laufen sie auf V8-Isolaten. Dies ist dieselbe Engine, die JavaScript in Chrome ausführt.

Kaltstart: ~0ms.
Einschränkungen: Sie können keine Node.js-APIs wie „fs“, „child_process“ oder native Binärdateien verwenden.
Anwendungsfall: Middleware, Authentifizierungsweiterleitung, A/B-Test-Buckets, Geo-Routing.

Die Datenbankfalle: Verbindungspooling

Hier scheitern 90 % der Anfänger. Eine Standard-Postgres-Bibliothek („pg“) öffnet eine TCP-Verbindung. Bei einem Monolith-Server öffnen Sie eine Verbindung und geben diese frei. Bei Serverless ist jede Funktion ein isolierter Container. Wenn Sie 1.000 gleichzeitige Benutzer haben, öffnen Sie 1.000 DB-Verbindungen. Postgres hat nicht mehr genügend RAM und stürzt ab. „FATAL: Die verbleibenden Verbindungsslots sind reserviert.“

Lösung 1: Verbindungspooling (PgBouncer) Ein Middleware-Dienst, der Postgres vorgeschaltet ist. Es enthält 1.000 Client-Verbindungen, ordnet sie jedoch 10 echten DB-Verbindungen zu. DigitalOcean und AWS RDS Proxy bieten dies als Service an.

Lösung 2: HTTP-basierte Datenbanken Neue Datenbankanbieter (Neon, PlanetScale, Supabase) bieten HTTP-APIs an. Sie öffnen keinen TCP-Socket. Sie fetch('https://db.neon.tech/query'). HTTP ist zustandslos. Es lässt sich perfekt mit Serverless skalieren.

„Typoskript // Verwendung von Neon (Serverloses Postgres) import { neon } from ‘@neondatabase/serverless’;

const sql = neon(process.env.DATABASE_URL);

Asynchronen Funktionshandler (Ereignis) exportieren { const result = waiting sqlSELECT * FROM Users; return { body: JSON.stringify(result) }; } „

Statusverwaltung: Es ist kein Speicher vorhanden

Auf einem normalen Server können Sie Folgendes tun: let requestCount = 0; app.get('/', () => requestCount++); In Serverless ist „requestCount“ praktisch immer 1 oder 0. Der Container wird nach der Ausführung zerstört. Globale Variablen werden gelöscht.

Regel: Alle Zustände müssen extern sein.

Sitzungsdaten -> Redis.
Benutzerdaten -> Datenbank.
Datei-Uploads -> S3 / Blob Storage. Schreiben Sie nicht in „/tmp“ (es verschwindet). Verwenden Sie keine globalen Variablen.

Kostenanalyse: Der Wendepunkt

Serverlos ist nicht immer günstiger. Es gibt einen „Aufschlag“ auf die Rohdatenverarbeitung (~2x Kosten pro CPU-Zyklus im Vergleich zu EC2). Die Einsparungen ergeben sich aus 0 % Leerlaufzeit.

Geringer Datenverkehr/Spitzenmäßiger Datenverkehr: Serverlos ist 90 % günstiger.
Ständig hohe Auslastung: Wenn Ihr Prozess rund um die Uhr läuft (z. B. ein WebSocket-Server oder eine starke Datenverarbeitung), ist EC2 günstiger. Wir führen für unsere Kunden TCO-Prüfungen (Total Cost of Ownership) durch. Die Betriebskosten für die Verwaltung von EC2 (Patching, Sicherheit) machen Serverless oft auch bei höheren Volumina zum Gewinner.

Code: Vercel-API-Route (Best Practice)

Wir strukturieren unsere Funktionen so, dass sie testbar sind, und trennen Logik von Netzwerk.

„Typoskript // app/api/checkout/route.ts (Next.js App Router) import { NextResponse } from ‘next/server’; import { createCheckout } from ’@/lib/checkout’; // Geschäftslogik

// Der Handler (Netzwerkschicht) Asynchrone Funktion exportieren POST(request: Request) { versuche es mit { const body = waiting request.json();

// Eingabe validieren (Zod)
if (!body.cartId) {
  return NextResponse.json({ error: 'Missing Cart ID' }, { status: 400 });
}

// Logik aufrufen
const url = waiting createCheckout(body.cartId);

return NextResponse.json({ url });

} Catch (Fehler) { console.error(error); // Protokolliert bei CloudWatch / Datadog return NextResponse.json({ error: ‘Internal Error’ }, { status: 500 }); } } „

10. Beobachtbarkeit: Verteilte Nachverfolgung

In einem Monolithen grepen Sie „server.log“. In Serverless trifft eine einzelne Benutzeranfrage auf „API Gateway“ -> „Lambda A“ -> „SQS“ -> „Lambda B“ -> „DynamoDB“. Wenn es fehlschlägt, wo ist es fehlgeschlagen? Sie können Protokolle nicht über 5 Dienste hinweg durchsuchen. Wir implementieren Distributed Tracing (OpenTelemetry / AWS X-Ray). Wir übergeben jedem Dienst einen „trace_id“-Header. Dadurch wird ein „Flammendiagramm“ generiert, das genau zeigt, wo die Latenzspitze aufgetreten ist (z. B. „Lambda B hat 3 Sekunden gebraucht, weil DynamoDB gedrosselt hat“).

11. Der Vendor-Lock-in-Mythos

Rezensenten sagen oft: „Serverless bindet Sie an AWS.“ WAHR. Aber Docker bindet Sie an den Linux-Kernel. React bindet Sie an das virtuelle DOM. Lock-in ist unvermeidlich. Die Frage ist: „Ist der Lock-in die Geschwindigkeit wert?“ Wir können eine Lambda-Funktion in Go/Rust in einem Tag neu schreiben. Die Kosten für die Wegmigration von Serverless sind gering, da die Codeeinheiten klein sind. Die Kosten für die Nicht-Nutzung von Serverless (Verwaltung von EC2-Flotten) sind hoch und laufend an.

13. Sicherheit: Geringste Privilegien (IAM)

Ein Lambda = eine Rolle. Geben Sie Ihrem Lambda keinen „AdministratorAccess“. Wenn dieses Lambda kompromittiert ist (Abhängigkeitsinjektion), ist der Angreifer Eigentümer Ihres Kontos. Geben Sie Folgendes ein: „s3:GetObject“ NUR für „bucket-a“. Dieses granulare Sicherheitsmodell ist einem Monolith überlegen, bei dem der gesamte Server Root-Zugriff auf die Datenbank hat. Tools wie SST (Serverless Stack) automatisieren diese Richtlinienerstellung: „bucket.grantRead(lambda)“ generiert die strenge IAM-Richtlinie automatisch.

14. Frameworks: Warum wir SST verwenden

Raw CloudFormation ist schmerzhaft. Terraform ist ausführlich. Wir verwenden SST (Serverless Stack). Es ermöglicht uns, Infrastruktur in TypeScript zu definieren. Es ermöglicht „Live Lambda Development“ (lokale Umgebungs-Proxys für AWS). Sie legen Haltepunkte in VS Code fest, erreichen einen Endpunkt und er pausiert innerhalb des Lambda, das auf AWS läuft. Es ist die einzige Möglichkeit, Serverless vernünftig zu entwickeln.

15. Fazit

Serverlose Funktionen sind der Klebstoff des modernen Internets. Sie ermöglichen es Frontend-Ingenieuren, „Full Stack“ zu werden, ohne dass ein Abschluss in Linux-Administration erforderlich ist. Sie skalieren unendlich. Im Leerlauf kosten sie nichts. Aber sie erfordern eine disziplinierte „staatenlose“ Denkweise.

Für ungenutzte Betriebszeit bezahlen?

Betreiben Sie einen 100-Dollar-Server für einen Job, der 5 Sekunden pro Tag dauert? Beauftragen Sie unsere Architekten.