LLMs sind das Ende von Serverless

Erinnert ihr euch, als Serverless alles revolutionieren sollte? Nun, LLMs haben gerade den Todesstoß versetzt.

Hier ist die Sache: In einer KI-unterstützten Coding-Welt sind proprietäre Serverless-Plattformen totes Gewicht. Warum? Weil LLMs Docker verstehen wie das Atmen, aber an deiner speziellen Schneeflocken-Lambda-Konfiguration ersticken.

Lass mich erklären, warum Serverless schon immer ein Betrug war und wie LLMs es zehnmal schlimmer gemacht haben.

Die Ursünde: Serverless war schon immer kaputt

Bevor wir zum LLM-Aspekt kommen, lass uns zusammenfassen, warum Serverless schon immer eine schlechte Idee war:

Das Versprechen:

• Keine Server zu verwalten!
• Unendliche Skalierung!
• Zahle nur, was du nutzt!

Die Realität:

• 15-Minuten-Ausführungslimits
• Cold Starts, die deine App kaputt wirken lassen
• Überraschende 10.000€-Rechnungen
• Vendor Lock-in, der wehtut
• Debugging, das dich deine Karriere hinterfragen lässt

Weißt du, was diese Probleme nicht hat? Ein Container.

LLMs betreten die Bühne: Der letzte Nagel im Sarg

Hier wird's pikant.

Wenn du mit Claude, ChatGPT oder Cursor programmierst, was funktioniert besser?

Option A: "Deploy das nach Docker"

docker build -t my-app .
docker run -p 3000:3000 my-app

Option B: "Deploy das nach AWS Lambda mit API Gateway, konfiguriere die Execution Role, richte die VPC Endpoints ein, erstelle ein Deployment Package mit der richtigen Runtime, konfiguriere die Event Source Mappings..."

Die Antwort des LLMs auf Option B: verwirrtes Schreien

Warum LLMs Docker lieben (und deine Serverless-Plattform hassen)

1. Dokumentationsdichte

Docker gibt es seit 2013. Das sind über ein Jahrzehnt von:

• Stack Overflow Antworten
• GitHub Beispielen
• Blog-Posts
• Offiziellen Docs
• YouTube Tutorials

AWS Lambda? Klar, es gibt Dokumentation. Aber sie ist:

• Ständig im Wandel
• Plattform-spezifisch
• Voller Edge Cases
• Begraben in AWS' Labyrinth von Services

Wenn ein LLM im Internet trainiert, sieht es 1000x mehr Docker-Beispiele als CloudFormation YAML-Albträume.

2. Universelle Muster vs. Proprietärer Unsinn

Docker ist nur Linux-Container. Die Muster sind universell:

• Umgebungsvariablen funktionieren überall gleich
• Volumes sind nur gemountete Verzeichnisse
• Networking ist Standard TCP/IP

Serverless? Jede Plattform erfindet ihre eigenen:

• Event-Formate
• Konfigurations-Syntax
• Deployment-Prozeduren
• Debugging-Tools
• Abrechnungsmodelle

LLMs können mit diesem babylonischen Turm nicht mithalten.

3. Lokale Entwicklung = Bessere LLM-Unterstützung

Schau dir das an:

Ich: "Hilf mir zu debuggen, warum mein Container sich nicht mit Redis verbindet"

LLM: "Lass uns deine docker-compose.yml überprüfen, sicherstellen, dass die Services im selben Netzwerk sind, den Connection String verifizieren..."

vs.

Ich: "Hilf mir zu debuggen, warum meine Lambda sich nicht mit ElastiCache verbindet"

LLM: "Erst mal, überprüfe deine VPC-Konfiguration, dann die Security Groups, Subnet-Zuordnungen, NAT Gateway, Execution Role Permissions, und... moment, nutzt du VPC Endpoints? Was ist mit dem Lambda ENI Lifecycle? Hast du DNS Resolution in deiner VPC aktiviert?"

Kopf explodiert

"Aber Serverless skaliert!"

Das tut Kubernetes auch. Das tut Docker Swarm auch. Das tut buchstäblich jeder Container-Orchestrator.

Aber hier ist die Sache: mit Containern + LLMs kannst du diese Skalierung tatsächlich implementieren:

Ich: "Füge horizontales Autoscaling zu meinem Docker Compose Setup hinzu"

LLM: "Hier ist eine vollständige docker-compose.yml mit Skalierungs-Konfiguration, Health Checks und Load Balancing..."

vs.

Ich: "Füge Autoscaling zu meiner Lambda hinzu"

LLM: "Erstelle zuerst ein Application Auto Scaling Target, dann definiere eine Scaling Policy mit CloudWatch Metriken, aber stelle sicher, dass deine Concurrent Execution Limits nicht mit den Account Limits interferieren, und vergiss nicht Reserved Concurrency vs Provisioned Concurrency..."

Welches wirst du wohl korrekt implementieren?

Der Ausweg: Die Container + LLM Kombo

Hier ist dein Fluchtplan:

1. Wähle langweilige Technologie: Docker, PostgreSQL, Redis
2. Nutze Standard-Muster: REST APIs, Background Workers, Cron Jobs
3. Deploye überall: VPS, Kubernetes, sogar Sliplane (ja, schamlose Eigenwerbung)
4. Lass LLMs tatsächlich helfen: Sie verstehen diese Tools

Dein KI-Assistent wird zum Kraftmultiplikator statt zum verwirrten Praktikanten.

Die Zukunft ist langweilig (und das ist wunderschön)

Wir betreten eine Ära, in der KI den Großteil unseres Codes schreiben kann. Aber sie kann nur Code für Plattformen schreiben, die sie versteht.

Docker ist langweilig. PostgreSQL ist langweilig. Redis ist langweilig.

Weißt du was? Langweilig bedeutet:

• Dokumentiert
• Vorhersehbar
• LLM-freundlich
• Funktioniert tatsächlich

Serverless ist "aufregend": aufregend kaputt, aufregend teuer, aufregend unmöglich zu debuggen.

TL;DR

Serverless war schon immer eine fragwürdige Wahl. Jetzt, wo wir mit LLMs programmieren, ist es praktisch Sabotage.

Dein KI-Assistent kann in Sekunden eine vollständige containerisierte Anwendung aufsetzen. Aber frag ihn, deine Lambda Cold Start Probleme zu debuggen? Viel Glück.

Die Zeichen stehen an der Wand: In einer LLM-gesteuerten Entwicklungswelt sind proprietäre Plattformen totes Gewicht. Bleib bei Technologien mit tiefer Dokumentation, breiter Adoption und Standard-Mustern.

Oder kämpfe weiter mit CloudFormation, während deine Konkurrenten Features shippen. Deine Wahl.

Cheers,

Jonas, Co-Founder von sliplane.io