Self-Hosting

Wie Self-Hosting funktioniert

Beim Self-Hosting wird ein digitaler Dienst nicht vollständig durch einen externen Softwareanbieter betrieben.
Stattdessen übernimmt der Nutzer oder die Organisation wesentliche Teile des Betriebs selbst.

Dazu können beispielsweise gehören:

• Installation
• Konfiguration
• Updates
• Benutzerverwaltung
• Zugriffssteuerung
• Zertifikate
• Netzwerkbetrieb
• Monitoring
• Backups
• Wiederherstellung
• Fehleranalyse
• Migrationen

Wie viele dieser Aufgaben tatsächlich selbst übernommen werden, unterscheidet sich von System zu System.
Self-Hosting beschreibt deshalb kein einziges festes technisches Betriebsmodell.

Der Server muss nicht im Keller stehen

Self-Hosting wird häufig mit eigener Hardware verbunden.
Das ist jedoch nicht notwendig.

Ein Dienst kann beispielsweise betrieben werden auf:

eigenem physischen Server
gemietetem Root-Server
virtueller Maschine bei einem Hoster
gemieteter Infrastruktur in einem Rechenzentrum

In allen Fällen kann der eigentliche Anwendungsbetrieb unter eigener Verantwortung stattfinden.

Entscheidend ist weniger der Eigentümer der Hardware als die Frage:

Wer kontrolliert den Betrieb des Dienstes?

Self-Hosting besitzt Abstufungen

Zwischen vollständig selbst betrieben und vollständig ausgelagert existieren viele Zwischenstufen.

Ein Beispiel:

Hardware           → Rechenzentrum
Virtualisierung    → Hoster
Betriebssystem     → eigene Verantwortung
Anwendung          → eigene Verantwortung
Daten              → eigene Verantwortung
Backup             → eigene Verantwortung

Ein anderes Modell könnte so aussehen:

Hardware           → Cloud-Anbieter
Betriebssystem     → Managed Service
Datenbank          → Managed Service
Anwendung          → eigene Verantwortung

Ob die zweite Variante noch als Self-Hosting bezeichnet wird, hängt auch vom verwendeten Begriffsverständnis ab.

Für praktische Entscheidungen ist die Bezeichnung häufig weniger wichtig als die konkrete Frage:

Welche Schichten kontrollieren wir selbst und welche nicht?

Kontrolle wird gegen Verantwortung getauscht

Self-Hosting schafft häufig zusätzliche technische Kontrolle.

Beispielsweise kann selbst entschieden werden:

• wann Updates erfolgen
• welche Version verwendet wird
• welche Erweiterungen installiert werden
• wo Daten gespeichert werden
• welche Schnittstellen erreichbar sind
• welche Protokolle verwendet werden
• wie Backups erstellt werden
• wie lange Daten aufbewahrt werden

Diese Kontrolle besitzt jedoch einen Preis.

Für dieselben Entscheidungen muss nun jemand verantwortlich sein.

Aus:

Der Anbieter kümmert sich darum.

wird:

Wir müssen wissen, wer sich darum kümmert.

Kontrolle und Verantwortung lassen sich deshalb beim Self-Hosting nur schwer voneinander trennen.

Updates gehören zum Betrieb

Eine selbst gehostete Anwendung bleibt nicht dadurch zuverlässig, dass sie einmal erfolgreich installiert wurde.
Software verändert sich.
Sicherheitslücken werden entdeckt.
Abhängigkeiten erhalten neue Versionen.
Zertifikate laufen ab.
Betriebssysteme erreichen ihr Supportende.

Ein Self-Hosting-Konzept benötigt deshalb auch eine Antwort auf:

Wie erkennen wir notwendige Updates?
Wie testen wir Änderungen?
Wer führt sie durch?
Wie können wir zurück?

Der Aufwand entsteht damit nicht nur bei der Installation.
Er entsteht über die gesamte Betriebsdauer.

Backup ist nicht Restore

Eine häufige Betriebsanforderung lautet:

Wir haben Backups.

Das beschreibt zunächst nur, dass Daten irgendwo gesichert werden.

Für die tatsächliche Wiederherstellbarkeit sind weitere Fragen relevant:

• Sind die Backups vollständig?
• Sind sie lesbar?
• Sind benötigte Schlüssel vorhanden?
• Ist die Wiederherstellung dokumentiert?
• Wurde sie getestet?
• Wie lange dauert sie?
• Welche Daten gehen zwischen letzter Sicherung und Ausfall verloren?
• Ist auch die notwendige Konfiguration gesichert?

Ein Backup, das sich nicht zuverlässig wiederherstellen lässt, besitzt nur begrenzten praktischen Wert.
Self-Hosting bedeutet deshalb auch, Verantwortung für Wiederherstellbarkeit zu übernehmen.

Sicherheit entsteht nicht durch den Standort

Ein eigener Server ist nicht automatisch sicherer als ein externer Dienst.

Ein selbst gehostetes System kann beispielsweise:

ungepatcht
falsch konfiguriert
schlecht überwacht
ohne funktionierende Backups

sein.
Ein professionell betriebener externer Dienst kann in diesen Punkten wesentlich besser aufgestellt sein.
Umgekehrt kann Self-Hosting ermöglichen, Sicherheitsentscheidungen gezielter an eigene Anforderungen anzupassen.

Sicherheit ergibt sich deshalb nicht aus:

self-hosted = secure

sondern aus der tatsächlichen Architektur und Betriebsqualität.

Datenschutz entsteht ebenfalls nicht automatisch

Wenn Daten auf selbst kontrollierter Infrastruktur gespeichert werden, kann dies zusätzliche Kontrolle über Speicherorte und Zugriffe ermöglichen.
Damit sind jedoch nicht automatisch sämtliche Datenschutzfragen gelöst.

Auch beim Self-Hosting können beispielsweise beteiligt sein:

• Rechenzentrumsbetreiber
• Internetanbieter
• Backup-Dienstleister
• DNS-Anbieter
• externe Maildienste
• Zertifizierungsstellen
• externe Supportanbieter

Zusätzlich müssen eigene Zugriffsrechte, Protokollierung, Aufbewahrungsfristen und Sicherheitsmaßnahmen sinnvoll gestaltet sein.
Self-Hosting verändert die Verantwortungsstruktur.
Es beseitigt sie nicht.

Abhängigkeiten verschwinden nicht

Eine selbst gehostete Anwendung kann weiterhin abhängig sein von:

• dem Softwareprojekt
• Bibliotheken
• Betriebssystemen
• Hardware
• Paketquellen
• externen APIs
• DNS
• Zertifikaten
• Internetzugängen
• Dokumentation
• einzelnen Personen mit Spezialwissen

Self-Hosting reduziert deshalb bestimmte Anbieterabhängigkeiten, kann aber andere Abhängigkeiten verstärken.
Aus einer SaaS-Abhängigkeit kann beispielsweise eine starke Abhängigkeit von einer einzelnen Administratorin oder einem einzelnen Administrator entstehen.
Auch das gehört zur Systembetrachtung.

Self-Hosting und digitale Souveränität

Self-Hosting kann ein Werkzeug für digitale Souveränität sein.

Es kann beispielsweise ermöglichen:

eigene Kontrolle über Daten
eigene Versionsentscheidungen
direkten Zugriff auf Konfiguration
eigene Integrationen
unabhängigere Migration

Aber Self-Hosting ist nicht mit digitaler Souveränität identisch.
Ein selbst betriebenes System kann so komplex, schlecht dokumentiert oder schwer migrierbar sein, dass reale Handlungsmöglichkeiten kaum noch vorhanden sind.
Umgekehrt kann ein externer Dienst mit vollständigem Datenexport, offenen Schnittstellen und gut getesteter Exit-Strategie erhebliche Handlungsfreiheit ermöglichen.
Die wichtigere Frage lautet deshalb:

Welche realen Handlungsmöglichkeiten schafft uns dieses Betriebsmodell?

Komplexität zählt

Der Betriebsaufwand eines selbst gehosteten Systems hängt stark von seiner Architektur ab.

Ein kleiner Dienst mit:

einem Prozess
einer Konfigurationsdatei
einer Datenbank
einem dokumentierten Backupverfahren

kann relativ einfach beherrschbar sein.

Ein anderes System benötigt möglicherweise:

Container-Orchestrierung
mehrere Datenbanken
Message Broker
verteilte Speicher
Service Mesh
externe Identitätsdienste
zahlreiche Hintergrunddienste

Beide Systeme können Self-Hosted sein.
Ihr tatsächlicher Betriebsaufwand unterscheidet sich erheblich.
Die Entscheidung für Self-Hosting sollte deshalb nicht nur fragen, ob eine Software grundsätzlich selbst betrieben werden kann.

Sie sollte fragen:

Können wir dieses konkrete System dauerhaft verstehen und zuverlässig betreiben?

Klein kann ein Vorteil sein

Ein kleineres System besitzt nicht automatisch bessere technische Eigenschaften.

Es kann aber leichter sein:

• vollständig zu verstehen
• zu dokumentieren
• zu sichern
• wiederherzustellen
• zu aktualisieren
• zu migrieren
• auf Abhängigkeiten zu untersuchen
• im Fehlerfall zu diagnostizieren

Dadurch kann geringe Komplexität selbst zu einem betrieblichen Vorteil werden.
Das ist insbesondere dann relevant, wenn ein Dienst über viele Jahre mit begrenzten personellen Ressourcen betrieben werden soll.

Self-Hosting braucht Informationen über den Systemzustand

Wer einen Dienst selbst betreibt, muss erkennen können, ob er funktioniert.

Dazu können beispielsweise gehören:

Dienststatus
Fehlerprotokolle
Speicherverbrauch
Festplattenplatz
Antwortzeiten
Fehlerquoten
Backupstatus
Zertifikatslaufzeiten

Ohne geeignete Beobachtbarkeit wird ein Problem möglicherweise erst bekannt, wenn Nutzer es bemerken.
Self-Hosting bedeutet deshalb nicht nur Kontrolle über einen Dienst.
Es benötigt auch ausreichende Informationen über seinen Zustand.

Self-Hosting braucht eine Exit-Strategie

Auch eine selbst gehostete Lösung kann irgendwann ersetzt werden müssen.

Beispielsweise weil:

• das Projekt eingestellt wird
• Sicherheitsupdates fehlen
• Anforderungen sich verändern
• das System zu komplex geworden ist
• eine bessere Alternative entsteht
• notwendiges Fachwissen verloren geht

Darum ist die Frage:

„Wie kommen wir hier hinein?“

nur die Hälfte einer Systementscheidung.

Die zweite lautet:

„Wie kommen wir wieder heraus?“

Auch beim Self-Hosting können offene Datenformate, dokumentierte Schnittstellen, reproduzierbare Konfigurationen und getestete Migrationen die spätere Handlungsfähigkeit erheblich verbessern.

Wann Self-Hosting sinnvoll sein kann

Self-Hosting kann besonders interessant sein, wenn beispielsweise:

• besondere Kontrolle über Daten benötigt wird
• ein Dienst stark angepasst werden soll
• externe Anbieter bestimmte Anforderungen nicht erfüllen
• bestehende Systeme direkt integriert werden müssen
• langfristige Anbieterabhängigkeiten vermieden werden sollen
• Betrieb und Architektur mit vertretbarem Aufwand beherrschbar sind

Diese Bedingungen sind keine allgemeine Checkliste.
Je nach System können andere Gründe entscheidend sein.

Wann ein externer Dienst sinnvoller sein kann

Ein externer Dienst kann die bessere Lösung sein, wenn beispielsweise:

• die Funktion wenig strategische Bedeutung besitzt
• eigener Betrieb unverhältnismäßig aufwendig wäre
• spezialisiertes Betriebswissen fehlt
• hohe Verfügbarkeitsanforderungen extern besser erfüllt werden können
• gute Export- und Migrationsmöglichkeiten vorhanden sind
• die vorhandene Anbieterabhängigkeit akzeptabel ist

Digitale Souveränität verlangt nicht, jede mögliche Aufgabe selbst zu übernehmen.
Sie verlangt vor allem, Abhängigkeiten und Konsequenzen bewusst beurteilen zu können.

Warum Self-Hosting praktische Auswirkungen hat

• Mehr Kontrolle bedeutet mehr Verantwortung: Betrieb und Wartung werden Teil der eigenen Aufgabe.
• Infrastruktur kann trotzdem gemietet sein: Self-Hosting benötigt keine eigene Hardware.
• Updates werden zur dauerhaften Aufgabe: Eine erfolgreiche Installation ist noch kein Betriebskonzept.
• Backups müssen wiederherstellbar sein: Sicherungsdateien allein reichen nicht.
• Sicherheit und Datenschutz entstehen nicht automatisch: Sie hängen von Architektur und Betrieb ab.
• Abhängigkeiten werden verschoben: SaaS-Abhängigkeiten können durch Infrastruktur-, Software- oder Wissensabhängigkeiten ersetzt werden.
• Komplexität beeinflusst Beherrschbarkeit: Ein technisch mögliches Self-Hosting muss nicht praktisch sinnvoll sein.
• Exit-Fähigkeit bleibt relevant: Auch selbst betriebene Software muss später austauschbar sein können.
• Self-Hosting kann digitale Souveränität unterstützen: Es ist ein Werkzeug dafür, aber kein Selbstzweck.

Typisches Beispiel

Eine Organisation benötigt einen internen Dienst für Dokumentation.

Variante A ist ein SaaS-Angebot.
Es kostet wenig, wird vollständig betrieben und benötigt praktisch keine eigene Administration.
Allerdings können die Daten nur unvollständig exportiert werden und mehrere wichtige Funktionen sind ausschließlich über proprietäre Schnittstellen erreichbar.

Variante B ist eine selbst gehostete Open-Source-Anwendung.
Sie lässt sich vollständig exportieren und besitzt dokumentierte Schnittstellen.

Der Betrieb benötigt:

ungefähr eine Stunde Wartung pro Monat

Backups werden automatisch erstellt und regelmäßig testweise wiederhergestellt.
Updates können zunächst auf einer Testinstanz geprüft werden.
Für diese Organisation kann Variante B zusätzliche digitale Handlungsfähigkeit schaffen.
Bei einer anderen Organisation ohne entsprechendes Betriebswissen könnte dieselbe Lösung jedoch eine größere Abhängigkeit und ein höheres Risiko erzeugen als das SaaS-Angebot.
Die Software allein entscheidet deshalb nicht darüber, welches Modell souveräner ist.
Entscheidend ist das gesamte System einschließlich der vorhandenen Fähigkeiten und Ressourcen.

Abgrenzung

• Self-Hosting bezeichnet den Betrieb eines digitalen Dienstes unter eigener technischer und organisatorischer Verantwortung.
• Software as a Service (SaaS) bezeichnet ein Modell, bei dem eine Anwendung als Dienst durch einen externen Anbieter betrieben und bereitgestellt wird.
• Digitale Souveränität beschreibt die Fähigkeit, über digitale Systeme und ihre Abhängigkeiten selbstbestimmt entscheiden und bei Veränderungen handlungsfähig bleiben zu können. Self-Hosting kann diese Fähigkeit unterstützen.
• Open Source beschreibt unter anderem die Rechte zur Nutzung, Untersuchung, Veränderung und Weitergabe von Software gemäß ihrer Lizenz. Open-Source-Software kann selbst gehostet werden, muss es aber nicht.
• Resilienz beschreibt die Fähigkeit eines Systems, wesentliche Funktionen unter Störungen und Veränderungen zu erhalten, wiederherzustellen oder angepasst fortzuführen.
• Beobachtbarkeit ermöglicht, Zustand und Verhalten eines Systems aus verfügbaren Informationen zu untersuchen und ist eine wichtige Grundlage für zuverlässigen Eigenbetrieb.

Weiterführend

Verwandte Begriffe

→ Digitale Souveränität
→ Systemarchitektur
→ Systemintegration
→ Beobachtbarkeit
→ Resilienz
→ Legacy-System
→ Offenes Datenformat