Foto: Paul Hanaoka auf Unsplash
»Digitale Souveränität« klingt in der Regel nach einem riesigen Infrastruktur-Projekt: da müssen Anbieter evaluiert, Prozesse umgestellt und Systeme migriert werden. So entsteht leicht der Eindruck, dass Souveränität vor allem eines ist: aufwändig, teuer und kompliziert.
Ein möglicher Einstieg ist, sich eine konkrete Anwendung vorzunehmen und zu prüfen, welche Abhängigkeiten bestehen und welche Alternativen sich schaffen lassen. Wir erproben das an unserer DevOps-Umgebung. Dabei interessiert uns auch, wie sich aus einem solchen Versuch ein Vorgehen für andere Anwendungen und Organisationen entwickeln lässt.
Im Wesentlichen geht es bei digitaler Souveränität um Wahlfreiheit: Bin ich mit meiner Infrastruktur an einen bestimmten Anbieter gebunden oder habe ich die Option zu wechseln? Es kann technische, wirtschaftliche oder organisatorische Gründe geben, einen externen Anbieter zu nutzen. Souveränität zeigt sich darin, dass aus dieser Entscheidung keine unnötige digitale Abhängigkeit wird und wir mit angemessenem Aufwand wechseln können, wenn beispielsweise sich ändernde Betriebsstrukturen dies erfordern.
Für unser Experiment setzen wir bei der Infrastruktur an, mit der wir Software entwickeln und ausliefern: unserer DevOps-Umgebung (siehe Infobox). Hier liegt unser Quellcode und damit geistiges Eigentum, hier werden Deployment-Prozesse gesteuert und häufig auch Zugangsdaten (Secrets) zu zentralen Systemen verwaltet. Das macht diese Umgebung zu einem besonders sensiblen Teil der gesamten Infrastruktur. Die meisten Projekte, die wir kennen, laufen bei kommerziellen Anbietern in den USA, beispielsweise GitHub. Für uns ist das der Anlass zu prüfen, welche Alternative wir bei Bedarf selbst betreiben könnten.
Was bedeutet DevOps?
DevOps verbindet Softwareentwicklung (Development) und IT-Betrieb (Operations) durch gemeinsame Arbeitsweisen und Werkzeuge. Die technische Umgebung unterstützt dabei unter anderem die Versionsverwaltung von Quellcode, automatisierte Tests und die Bereitstellung neuer Softwareversionen. In diesem Artikel betrachten wir diese Infrastruktur. Sie verwaltet Quellcode und benötigt häufig sensible Zugangsdaten für die Systeme, auf denen die Software läuft.
Als Berater und Softwareentwickler fragen wir uns, wie aufwändig es ist, eine DevOps-Umgebung selbst zu betreiben. Wir wollen eine Alternative kennenlernen, die wir bei Bedarf selbst betreiben können, beispielsweise bei einem deutschen Hosting-Anbieter. Bereits nach zwei Stunden hatten wir einen funktionierenden Proof of Concept.
Was nach zwei Stunden funktioniert
Die Auswahl an möglichen DevOps-Systemen war größer als erwartet. Unsere Wahl fiel auf Forgejo. Das ist eine schlanke Open-Source-Plattform für die Bereitstellung und Verwaltung von Git-Repositories. Neben Versionskontrolle bietet sie Funktionen wie Issues, Pull Requests, Benutzer- und Rechteverwaltung sowie CI/CD, also automatisiertes Testen und Bereitstellen von Software. Sie kann vollständig auf eigener Infrastruktur betrieben werden.
Teile unserer Infrastruktur laufen bereits bei Hetzner, entsprechend fiel die Wahl des Hosting-Service. Wir arbeiten auf virtuellen Maschinen (Infrastructure as a Service, IaaS) und verwenden mit Ubuntu ein Standard-Linux. Entsprechend ist der Anbieter hier gar nicht entscheidend, weil sich das Setup ohne weiteres auf vergleichbare deutsche oder europäische Anbieter übertragen lässt.
Die Einrichtung dauerte etwa zwei Stunden ohne Unterbrechung: eine halbe Stunde für die Konfiguration des Linux-Servers, eine Stunde für das Setup der Systeme und noch eine halbe Stunde für die Fehlerbehebung, bis auch die benötigten Zugriffe von außen funktionierten. Die vorherige Planung und grobe Vorauswahl von Forgejo sind darin nicht enthalten. Nach diesen zwei Stunden funktionierten der Git-Zugriff und die Benutzerverwaltung; eine Test-Pipeline und ein Deployment liefen erfolgreich durch. Dafür war auch ein Runner eingerichtet, der die automatisierten Abläufe ausführt.
Damit hatten wir eine funktionierende Testumgebung. Für einen produktionsreifen Einsatz fehlen uns noch Erkenntnisse zur Wiederherstellung aus Backups, zu Updates und zum laufenden Betreuungsaufwand. Unser Experiment zeigt zunächst, dass wir die getesteten Funktionen selbst bereitstellen können und die technischen Anforderungen an die Einrichtung kennen.
Damit wir diese Alternative für bestehende Projekte nutzen können, müssen wir auch Daten und Arbeitsabläufe aus den bisherigen Systemen übertragen können. Die gemeinsame Nutzung von Git erleichtert die Übernahme der Repositories aus GitHub. Für weitere Daten wie Issues gibt es Importfunktionen.
Bei Pipelines hängt der Anpassungsaufwand von den verwendeten Workflows ab: Forgejo Actions unterscheidet sich in einigen Funktionen von GitHub Actions. Secrets müssen im Zielsystem erneut hinterlegt werden, weil die GitHub-API ihre gespeicherten Werte nicht zurückgibt; das kann auch automatisiert erfolgen. Angebote, die speziell in GitHub eingebunden sind, wie GitHub Apps, lassen sich nicht direkt übernehmen. Insgesamt erscheint uns die Migration mit vertretbarem Aufwand möglich. Wie hoch dieser für unsere bestehenden Projekte tatsächlich ist, muss eine konkrete Migration zeigen.
Wir können zunächst zweigleisig fahren: mit Open-Source-Projekten und Ähnlichem bei GitHub bleiben und sensible Projekte im eigenen System verwalten. Das gibt uns eine Wahlmöglichkeit bei der Zuordnung von Projekten. Ob sich ein bestehendes Projekt bei Bedarf vollständig übertragen lässt, ist damit noch nicht erprobt.
Digitale Abhängigkeiten systematisch prüfen
Unser Experiment zeigt, dass sich eine erste Alternative für unsere DevOps-Umgebung mit überschaubarem Aufwand einrichten lässt. Daraus ergibt sich für uns ein Vorgehen, das auch für andere Anwendungen hilfreich sein kann: Abhängigkeiten benennen, eine Alternative erproben und beurteilen, unter welchen Bedingungen sie eine realistische Wahl darstellt. Dafür unterscheiden wir drei Dimensionen digitaler Souveränität.
Datensouveränität betrifft die Frage, wo Daten liegen, wer auf sie zugreifen kann und ob sie sich vollständig und in geeigneten Formaten übertragen lassen. Software-Souveränität beschreibt den Spielraum gegenüber einzelnen Anwendungen und Plattformen: Können wir die Software selbst betreiben, austauschen oder mit vertretbarem Aufwand durch eine Alternative ersetzen? Hardware- und Infrastruktur-Souveränität richtet den Blick auf die technische Grundlage. Hier ist unter anderem relevant, ob die Systeme auf standardisierten Technologien aufbauen und sich zwischen Infrastruktur- und Hosting-Anbietern verlagern lassen.
In unserem Experiment wird dieses Raster konkret: Die gemeinsame Nutzung von Git erleichtert die Übertragung der Repositories. Forgejo eröffnet uns die Möglichkeit, die Plattform selbst zu betreiben. Die standardisierte Linux- und IaaS-Infrastruktur schafft Spielraum bei der Wahl des Hostings. Die drei Dimensionen helfen so, genauer zu benennen, an welcher Stelle eine Alternative zusätzliche Wahlfreiheit ermöglicht und welche Abhängigkeiten weiter bestehen.
Ob diese Wahlfreiheit praktisch nutzbar ist, lässt sich anhand weiterer Fragen beurteilen. Rechtlich geht es etwa darum, welche Anforderungen Datenschutz, Regulierung und bestehende Verträge an einen Wechsel stellen. Organisatorisch müssen Kompetenzen, Verantwortlichkeiten und der laufende Betriebsaufwand zur jeweiligen Organisation passen. Technische Interoperabilität bedeutet schließlich, dass Daten, Schnittstellen und Arbeitsabläufe zwischen den bestehenden und den alternativen Systemen zusammenpassen oder mit vertretbarem Aufwand angepasst werden können. Diese Fragen ergänzen die drei Dimensionen: Sie zeigen, unter welchen Bedingungen eine mögliche Alternative tatsächlich tragfähig wird.
So lässt sich digitale Souveränität schrittweise angehen. Für eine konkrete Anwendung können wir bestimmen, welche Abhängigkeiten wir bewusst akzeptieren und wo wir eine belastbare Alternative benötigen. Eine Organisation kann dabei durchaus zu dem Ergebnis kommen, einen externen Anbieter weiter zu nutzen. Entscheidend ist, dass sie ihre Bindungen kennt und den Aufwand eines Wechsels einschätzen kann. Die leitende Frage lautet: Haben wir eine realistische Wahl, wenn wir sie brauchen?