Bei einer Laravel-Anwendung denke ich früh an den Server. Ein Upload braucht einen Speicherort und ein Backup. Eine Queue braucht einen laufenden Worker. Und beim nächsten Deployment sollen die angemeldeten Benutzer möglichst wenig davon mitbekommen.
Das sind Fragen, die mir aus Entwicklung und Webhosting vertraut sind. Wenn ich sie erst beim Einrichten des Produktivsystems stelle, muss ich unter Umständen noch einmal an den Code.
Was nach dem Deployment passiert
Auf dem Entwicklungsrechner ist vieles bequem: eine Instanz, überschaubare Datenmengen, kurze Wege. Im Betrieb kommen gleichzeitige Zugriffe, längere Laufzeiten und Neustarts dazu. Dann zeigt sich zum Beispiel, ob ein Hintergrundjob nach einem Abbruch sauber erneut ausgeführt werden kann.
Bei der Planung kläre ich deshalb, welche Aufgaben warten dürfen und welche sofort erledigt werden müssen. Ein umfangreicher Export kann in einer Queue laufen. Eine Rückmeldung an den Benutzer braucht die Oberfläche trotzdem. Auch ein Fehler im Hintergrundjob muss irgendwo sichtbar werden.
Ähnlich ist es bei Datenbankabfragen. Mit ein paar Testdatensätzen fällt eine ungünstige Abfrage kaum auf. Mit den Daten aus mehreren Geschäftsjahren kann derselbe Bildschirm plötzlich zäh werden. Datenmenge und Nutzung gehören für mich deshalb zur Entwicklung dazu.
Queues und Scheduler brauchen einen laufenden Betrieb
Laravel bringt Queues, einen Scheduler, Caching und Migrationen mit. Das spart viel Arbeit. Für interne Oberflächen kommen Livewire und Filament dazu, mit denen sich viele Verwaltungsaufgaben ohne separaten JavaScript-Frontend-Stack umsetzen lassen.
Beim Queue-Worker bleiben aber ein paar Entscheidungen: Wie lange darf ein Job laufen? Was passiert nach einem Fehler? Kann eine Wiederholung versehentlich dieselbe Aktion zweimal auslösen? Und wer merkt, wenn der Worker gar nicht mehr läuft?
Auch ein korrekt geschriebener Scheduler hilft wenig, wenn sein Aufruf auf dem Server fehlt. Solche Dinge sind im Code-Review leicht zu übersehen. Ich nehme sie lieber in die Planung und ins Deployment auf, statt sie später bei der Fehlersuche zusammenzusuchen.
Wo liegen Dateien, Sessions und Konfiguration?
Solange eine Anwendung auf einem einzelnen Server läuft, sind lokale Dateien und Sessions oft eine einfache Lösung. Bei mehreren Instanzen muss geklärt sein, wie alle auf denselben benötigten Stand zugreifen. Sonst hängt das Verhalten davon ab, welcher Server die Anfrage bearbeitet.
Dazu kommen Zugangsdaten, Berechtigungen und Backups. Was gehört in die Konfiguration? Welche Verzeichnisse muss PHP beschreiben können? Welche Dateien müssen bei einem Umzug mit, und wie lässt sich die Anwendung aus einer Sicherung wiederherstellen?
Diese Fragen bespreche ich gern, solange sich die Struktur noch gut anpassen lässt. Das erspart später Änderungen unter Zeitdruck.
Wie viel Infrastruktur braucht die Anwendung?
Aus all dem folgt für mich kein Automatismus in Richtung Cluster. Eine überschaubare Anwendung kann auf einem einzelnen, gut betreuten Linux-Server sinnvoll aufgehoben sein. Mehr Instanzen bringen zusätzliche Aufgaben bei Datenhaltung, Deployment und Fehlersuche mit.
Der Aufbau muss sich im Alltag betreuen lassen. Dazu gehört für mich eine klare Antwort auf die Frage: Wie bekommen wir die Anwendung wieder zum Laufen, wenn etwas ausfällt?