PaaS (Platform as a Service)

Perfekt für Entwickler, die keine Admins sind. Du tippst: git push heroku main. 2 Minuten später ist deine App online. Du musst dich nicht um Linux-Updates oder Firewalls kümmern. Das macht der Anbieter. Nachteil: Es ist teurer als ein nackter Server und du hast weniger Kontrolle ("Black Box").

1. Buildpacks

PaaS-Anbieter erkennen automatisch, was du hochlädst. "Oh, eine package.json? Das muss Node.js sein! Ich installiere Node." "Oh, eine requirements.txt? Das muss Python sein!" Diese Logik nennt man Buildpacks.

2. Lock-In-Effekt

Wenn du deine App speziell für Google App Engine schreibst, läuft sie vielleicht nur dort. Der Umzug zu AWS wird schwer. Deshalb gehen viele heute eher zu Containern (Docker/Kubernetes) – die laufen überall, sind aber mehr Arbeit (IaaS/CaaS).

1. Ephemeral Filesystems (Flüchtiger Speicher)

Der gravierendste Architekturfehler, den Newbies bei PaaS (Heroku, Vercel) begehen, ist das Uploaden in das lokale Dateisystem (./uploads/avatar.jpg). PaaS-Plattformen nutzen Ephemeral Filesystems. Die Container unterliegen keiner Persistenz-Garantie. Wenn die Plattform skaliert oder 1x in 24 Stunden re-deployt, wird der Container restlos in den Müll geworfen und ein brandneuer aus dem Git-Repo geklont aus dem Boden gestampft. Die Avatar-Bilder deiner User sind vernichtet. Die zwölf-Faktor-App Regel erzwingt Statelessness (Zustandslosigkeit): Die App darf File-Systeme nur für Caches nutzen (wie RAM) - echte Uploads müssen im Code zwingend synchron an objektbasierte Cloud-Speicher abstrahiert werden (AWS S3) und Datenbank-Dumps niemals in lokalen ./sqlite.db abgelegt werden.

2. Das Router/Ingress Mesh der Plattform

Wenn du auf myapp.heroku.com zugreifst, triffst du nicht deinen Node-Prozess. Der Traffic schlägt auf ein massives Nginx / HAProxy / Envoy Edge-Mesh des PaaS-Providers ein. Dieses Mesh fungiert als Terminate SSL Proxy. Der grüne HTTPS-Schlüssel wird hier von Let's Encrypt abgenommen und validiert. Dein eigener Node.js HTTP-Server innerhalb von Heroku spricht ab da im Backend oft unverschlüsselt rohes HTTP Port 80 (was CPU-Zeit dramatisch spart). Durch das Mesh greifen PaaS Feature-Gates ein: Zero-Downtime Deploys. Der alte Container läuft weiter auf Node-Port A. Der Buildpack baut den neuen auf Node-Port B. Der Edge-Router dreht den virtuellen Zeiger atomar auf Port B über, killt dann Node A lautlos.

3. Container Spawning: Die Kaltstart-Latenz (Cold Start)

Die PaaS Free-Tiers und Serverless Architekturen nutzen das Container-Scaling-to-Zero. Wer 30 Minuten keine Requests bekommt, dessen Container wird rigoros vom RAM zum Schlafen gefegt. Trifft ein Neu-Request ein, wacht die App auf. Dieser "Cold-Start" benötigt die Entpackung des Filesystem-Layers, das Booten des node Prozesses, die JIT-Compiler Warmups der V8-Engine, und das Aufziehen von DB-Verbindungspools. Bei Java/Spring kann dieser Kaltstart bis zu 9 Sekunden lang blockieren – Request-Dropouts der Kunden sind die Konsequenz. Bei Python/JS liegen die Cold-Starts bei ca. 1-2 Sekunden.