Ein Blog in 2025

Finden der passenden Architektur

Die Arbeit an diesem Blog hat als eine React-Applikation gestartet, da ich mit React bereits Erfahrung aus vorherigen Projekten hatte. Es schien zuerst das perfekte Framework für meinen Blog zu sein. Jedoch bemerkte ich schon bald, dass meine Arbeit am Frontend mit React Router das repliziert, was ich im Backend vorhatte. Zudem war ich besorgt, dass mein Blog schlechte SEO (Search Engine Optimization) Metriken haben würde, ohne auch noch Lösungen wie SSR (Server Side Rendering) anzuwenden. Ein solches Unterfangen hätte jedoch die Komplexität meiner Seite deutlich erhöht und mein Ziel untermauert, einen einfach zu unterhaltenen Blog zu kreieren.

Deshalb habe ich die Architektur nochmals überdacht und entschieden, ohne dediziertes Frontend fortzufahren. Stattdessen verwende ich Go HTML-Templates, um das Frontend dynamisch im Backend zu erzeugen. Mit diesem neuen Ansatz brauche ich das Routing nur einmal in meinem Go Web Framework, Echo, zu implementieren und kann statische Seiten liefern, die optimiert sind, um von Web-Crawlern gelesen zu werden.

Als Programmiersprache für das Backend habe ich mich für Go entschieden, da sie es mir erlaubt, eine ressourcenschonende und effiziente Applikation zu schreiben. Als Konsequenz brauche ich weniger Ressourcen, um meine Seite zu hosten. Andere Architekturen, die ich betrachtet habe, waren zum Beispiel eine komplett statische Seite. Jedoch könnte ich damit nicht die Dokumentation meiner Open-Source-Projekte dynamisch updaten. Zudem gibt mir die Wahl von Go die Chance, in einer anderen Sprache als Python Erfahrung zu sammeln.

Die Suche nach der passenden Hosting Lösung

Meine Suche nach einer Hosting-Lösung war gekennzeichnet durch zwei Hauptanliegen: die Kosten und die Benutzerfreundlichkeit. Für das erste Anliegen habe ich nicht nur die Basiskosten des Service betrachtet, sondern auch die Kosten, die durch Überschreiten von Bandweite oder Aufrufzulagen entstehen. Eine diesbezügliche Sorge sind DDoS-Attacken, welche das Potenzial haben, grosse Mengen an Bandweite aufzubrauchen. Eine ideale Lösung für mich wäre es, wenn man bei den Hyperscaler, wie AWS oder Azure, ein fixes Budget angeben kann, nach dessen Überschreitung die bezogenen Services pausiert würden. Jedoch bietet keiner von ihnen ein solches Feature an. Deshalb gäbe es nur die Option, teuren DDoS-Schutz zu kaufen oder Scripte zu schreiben, welche die bezogenen Services herunterfahren, wenn eine Budgetwarnmeldung eintrifft. Als Konsequenz habe ich nach Alternativen gesucht und dabei einen Schweizer VPS Provider namens Infomaniak entdeckt, der unlimitierte Bandbreite anbietet, was meine Sorgen von unkontrolliertem Kostenwachstum besänftigt. Jedoch heisst das Betreiben eines eigenen Servers einen grösseren Kompromiss in meinem zweiten Anliegen, der Benutzerfreundlichkeit, einzugehen.

Glücklicherweise habe ich Erfahrung im Betreiben von Linux-Servern von meiner vorherigen Position als DevOps Engineer. Obwohl ich nur plane, einen einzigen Server zu unterhalten, habe ich trotzdem Ansible Playbooks erstellt, um mein System schnell, zuverlässig und reproduzierbar bereitzustellen und gegen Attacken zu schützen.

Betreiben der Seite

Für das Anbieten der Seite habe ich mich entschieden, mit Docker Compose zu starten, da ich es bereits kenne und ähnliche Lösungen wie Podman Compose nicht funktioniert haben mit meinem Set-up. Zurzeit stehen komplexere Lösungen, wie Docker Swarm oder ein leichter Kubernetes-Cluster mit K3s nicht infrage, weil diese zu viel Overhead verursachen für meine einfache Seite, die aus meinem Backend Container und dem Reverse Proxy Traefik besteht. Dies könnte sich jedoch ändern, wenn sich der Umfang meiner Seite vergrössert oder Deployments ohne Downtime notwendig werden.