// technologien
Infrastruktur
Software, die nur auf dem Rechner des Entwicklers läuft, ist nicht fertig. Ich richte Deployment und Betrieb so ein, dass ein Stand reproduzierbar entsteht, automatisiert ausgerollt wird und sich im Fehlerfall zurücknehmen lässt.
// einsatz
Wie ich das einsetze
Überall dieselbe Umgebung
Container beschreiben die Laufzeitumgebung als Datei im Repository. Lokal, in der Vorschau und in der Produktion läuft dasselbe Abbild.
Automatisierte Auslieferung
Ein Push löst Bau, Prüfung und Deployment aus. Was manuell passiert, wird irgendwann vergessen oder unterschiedlich gemacht.
Vorschau vor Produktion
Änderungen bekommen eine eigene URL zum Ansehen, bevor sie live gehen. Rückmeldungen entstehen am tatsächlichen Ergebnis statt an Screenshots.
Rückweg einplanen
Zu jedem Deployment gehört der Weg zurück auf den vorherigen Stand. Ohne diesen Weg wird jede Auslieferung zur Mutprobe.
// im detail
Die einzelnen Technologien
Docker
Anwendung samt Abhängigkeiten in einem Abbild. Beendet die Diskussion darüber, welche Version wo installiert ist, und macht einen Umzug zwischen Anbietern zur Konfigurationsfrage statt zum Projekt.
Kubernetes
Betrieb mehrerer Container mit Neustart, Skalierung und Ausrollen ohne Ausfall. Sinnvoll ab einer gewissen Größe – für eine einzelne Website ist es Aufwand ohne Gegenwert.
CI/CD
Pipelines, die bei jeder Änderung bauen, prüfen und ausliefern. Der Nutzen ist weniger Geschwindigkeit als Gleichförmigkeit: derselbe Ablauf, jedes Mal, unabhängig davon wer auslöst.
Linux
Die Umgebung, in der am Ende fast alles läuft. Serverkonfiguration, Dienste, Zertifikate und Fehlersuche auf der Kommandozeile gehören zur Umsetzung dazu und nicht zu einem separaten Gewerk.
Vercel
Hosting mit enger Anbindung an Next.js: Vorschau-Bereitstellungen je Änderung, globale Auslieferung und wenig Konfigurationsaufwand. Passend, wenn kein eigener Server betrieben werden soll.
Cloudflare
Vorgeschaltetes Netz für Auslieferung, Zwischenspeicher und DNS. Übernimmt Aufgaben, die sonst der Ursprungsserver bei jedem Aufruf erledigen müsste, und hält unerwünschten Verkehr vom Server fern.
// auswahl
Wonach ich auswähle
- 01
Wie kritisch ist Verfügbarkeit?
Eine Firmenwebsite und ein Buchungssystem haben unterschiedliche Ansprüche. Danach richtet sich, wie viel Redundanz sich lohnt.
- 02
Wer betreibt es nach der Übergabe?
Ein Setup, das ohne mich nicht wartbar ist, ist kein gutes Setup. Die Komplexität richtet sich danach, wer sie später trägt.
- 03
Wie oft wird ausgeliefert?
Bei häufigen Änderungen zahlt sich Automatisierung sofort aus. Bei wenigen Änderungen im Jahr reicht ein einfacher, dokumentierter Ablauf.
// faq
Häufige Fragen
Brauche ich Kubernetes?
Meistens nicht. Für die große Mehrheit der Projekte genügen ein Container und ein einfacher Ablauf zum Ausrollen. Kubernetes lohnt sich, wenn mehrere Dienste zusammenspielen, Lastspitzen abgefangen werden müssen oder ein Team parallel ausliefert.
Kann das Hosting später gewechselt werden?
Ja, sofern die Anwendung containerisiert ist und keine anbieterspezifischen Funktionen tief eingebaut sind. Genau deshalb bleibt der anbieterspezifische Teil so klein wie möglich.
Was passiert, wenn ein Deployment schiefgeht?
Der vorherige Stand wird wieder ausgerollt. Deshalb bekommt jede Auslieferung eine Version, und Datenbank-Migrationen werden so geschrieben, dass sie den alten Stand nicht sofort unbrauchbar machen.
// passend dazu
Wo das zum Einsatz kommt
Passt das zu deinem Vorhaben?
Welche Technologie sinnvoll ist, ergibt sich aus dem Vorhaben – nicht andersherum. Beschreib kurz, was entstehen soll; du bekommst eine Einschätzung dazu, was dafür passt und was nicht.
// weitere