Wie PHP die Wurzeln von Serverless legte

Bevor AWS Lambda, Google Cloud Functions oder der Begriff „Serverless“ überhaupt ins Rampenlicht rückten, arbeiteten Entwickler*innen bereits mit einem Modell, das heutigen Function-as-a-Service-Plattformen (FaaS) erstaunlich ähnlich sieht. Die Überraschung: Sie nutzten dafür PHP.

Willkommen in der Webentwicklung von 2005.

Das Web im Jahr 2005: Eine einfachere Welt

Damals war das Deployment eines Webprojekts simpel: Webspace bei einem Hoster mieten, per FTP eine .php-Datei hochladen – fertig. Kein Docker, keine Kubernetes-Cluster, keine CI/CD-Pipelines. Und trotzdem folgte dieses Vorgehen bereits einem Prinzip, das stark an modernes FaaS erinnert.

• Man schrieb eine einzelne PHP-Datei, z. B. send_email.php.
• Diese Datei erledigte genau eine Aufgabe – etwa das Versenden einer E-Mail.
• Wenn jemand https://deinedomain.de/send_email.php aufrief, startete der Server einen neuen PHP-Prozess, führte die Datei aus, und beendete sie sofort danach.

Jede HTTP-Anfrage startete den Code von vorn – stateless und isoliert.

Kommt dir das bekannt vor?

Die Anatomie einer „Funktion“ im Jahr 2005

Schauen wir uns das genauer an:

• Zustandslose Ausführung: Jede Anfrage startet mit einem leeren Kontext.
• Sofortiges Deployment: Datei hochladen = live.
• Kurzlebige Prozesse: Ein Aufruf, ein Durchlauf, dann Ende.
• „Cold Starts“ inklusive: Beim ersten Aufruf musste Apache ggf. den PHP-Prozess starten – leicht verzögert.

Im Grunde war jede .php-Datei eine HTTP-invokierbare Funktion – wie heute bei FaaS-Diensten.

Warum das funktionierte

PHP war genau für diesen Zweck gemacht:

• Request-basierte Ausführung: PHP war auf Webanfragen zugeschnitten.
• Keine dauerhaften Prozesse: Anders als bei Node.js oder Python liefen PHP-Skripte nicht dauerhaft.
• „Shared-nothing“-Architektur: Keine persistenten Speicher, keine globalen Zustände zwischen Requests.
• Deployment ohne Overhead: Kein Build, kein Deploy-Tool – einfach hochladen.

So war jede Datei eine in sich geschlossene Einheit – Code als Service, ganz ohne Cloud.

Die Grenzen des alten Modells

Natürlich hatte diese frühe Form von FaaS auch ihre Schwächen:

• Vendor Lock-in: Hosting-Anbieter bestimmten, welche PHP-Version lief.
• Begrenzte Skalierbarkeit: Apache mit mod_php stieß schnell an Grenzen.
• Sicherheitsrisiken: Jede Datei war potenziell direkt aufrufbar.
• Performance: Keine optimierten Warmstarts oder dynamische Ressourcenvergabe.

Aber für kleine bis mittelgroße Projekte funktionierte das erstaunlich gut – und sofort.

Die Rückkehr des Modells mit AWS Lambda

Mit AWS Lambda (2014) kehrte dieses einfache Modell zurück – diesmal jedoch mit Cloud-Vorteilen: automatische Skalierung, bessere Sicherheit, Monitoring, Event-Trigger. Doch das Prinzip war dasselbe: Kurze, zustandslose Funktionen, ausgeführt auf Anfrage.

Was wir aus der PHP-Ära lernen können

PHP war oft das Ziel von Spott, aber es war seiner Zeit voraus:

• Produktivität durch Einfachheit
• Ein Datei = eine Funktion
• Event-getriebene Architektur ohne Overhead

Moderne FaaS-Frameworks bringen dieses Modell in ein neues Zeitalter – aber ihre Wurzeln reichen zurück bis zu den ersten .php-Dateien auf einem 1&1-Server.

Fazit

PHP hat vielleicht nie das Label „serverless“ getragen – aber es lebte es. Im Jahr 2005 deployten Entwickler*innen kleine Funktionen, die sofort live gingen, ohne sich um Infrastruktur kümmern zu müssen.

Also: Wenn du das nächste Mal eine Lambda-Funktion schreibst, denk daran – PHP war schon da.

Was sachste dazu?