Ein europäischer IT-Stack: Digitale Souveränität durch austauschbare Architektur

Was bedeutet digitale Souveränität, wenn eine Organisation ihre Infrastruktur nicht auf der grünen Wiese neu baut? Die Debatte bleibt häufig bei europäischen Cloud-Anbietern, dem Speicherort von Daten oder dem Austausch einzelner Anwendungen stehen. Das sind wichtige Fragen, aber noch keine belastbare Architektur.

Für uns bei ForgeOne beginnt Souveränität mit Kontrolle: über Daten, Betrieb, Identitäten, Schnittstellen, Wiederherstellung und zukünftige Veränderungen. Eine Technologieentscheidung darf nicht zur unumkehrbaren Bindung werden. Gleichzeitig wäre es unrealistisch, vollständige Unabhängigkeit oder einen unterbrechungsfreien Wechsel zwischen beliebigen Plattformen zu versprechen.

Unser Ziel ist deshalb keine uneingeschränkte Eins-zu-eins-Austauschbarkeit einzelner Produkte. Wir wollen funktionale Architekturbausteine so planen, dass eine Organisation sie mit Vorbereitung, Tests und geeigneten Ressourcen kontrolliert ersetzen kann. Wenn dabei angrenzende Werkzeuge oder Prozesse angepasst werden müssen, ist das kein Scheitern des Prinzips, sondern Teil einer ehrlich entworfenen Exit-Strategie.

Das Wichtigste auf einen Blick

Ein europäischer IT-Stack lässt sich für viele klar abgegrenzte Anforderungen bereits heute aufbauen. Technologien für Virtualisierung, Betriebssysteme, Identitätsmanagement, Backup und Zusammenarbeit sind verfügbar. Eine vollständige Unabhängigkeit von internationalen Herstellern und Lieferketten entsteht dadurch jedoch nicht.

Entscheidend sind nicht allein Herkunft und Lizenzmodell, sondern die Integration der Komponenten, langfristige Wartbarkeit, Wiederherstellbarkeit und realistische Migrationsmöglichkeiten. Gerade bei bestehenden Infrastrukturen müssen Funktionsumfang, Betriebsaufwand und wirtschaftliche Risiken berücksichtigt werden.

EuroStack verfolgt das Ziel, europäische Technologieangebote und deren Rahmenbedingungen zu stärken. Die Initiative ersetzt aber keine technisch geprüfte Referenzarchitektur.

Was ist ein europäischer IT-Stack?

Ein europäischer IT-Stack ist für uns kein Herkunftssiegel für eine willkürliche Produktliste. Mindestens fünf Perspektiven müssen getrennt bewertet werden: rechtlicher Unternehmenssitz, Eigentümerstruktur, Entwicklung und Governance, technologische Abhängigkeiten sowie die tatsächliche Fähigkeit, eine Lösung selbst zu betreiben und später zu verlassen.

A. Europäische Anbieter

Dazu zählen Anbieter mit europäischem Sitz und nachvollziehbarer Produktverantwortung. Beispiele im Infrastruktur- und Arbeitsplatzumfeld sind Proxmox und LINBIT in Österreich, Bareos, Univention, OpenProject, Nextcloud, Open-Xchange und Checkmk in Deutschland sowie XWiki in Frankreich. Dabei bleibt relevant, ob der Sitz innerhalb der EU oder in einem europäischen Nicht-EU-Staat liegt. Der Sitz allein beantwortet weder die Eigentümer- noch die Governance-Frage.

SUSE verdeutlicht diese notwendige Trennung: Das Unternehmen wurde in Deutschland gegründet, hat seinen Hauptsitz in Luxemburg und beschreibt sich selbst als schwedisch kontrolliert. Unternehmenssitz, Eigentümerstruktur, Entwicklungsstandorte und technische Kontrolle sind damit verschiedene Kriterien, die nicht zu einem einzigen Herkunftsetikett verkürzt werden sollten.

B. International entwickelte Open-Source-Technologien

Debian ist ein internationales Community-Projekt. Kubernetes und Keycloak werden in globalen Open-Source-Ökosystemen entwickelt. Ansible ist ein Open-Source-Projekt mit kommerziellem Red-Hat-Ökosystem; Ubuntu wird von Canonical mit internationaler Organisation getragen. Solche Technologien sind nicht ausschließlich europäisch. Sie können dennoch einen souveränen Eigenbetrieb ermöglichen, weil Quellcode, offene Schnittstellen, dokumentierte Datenpfade und ein breites Ökosystem die Kontrolle verbessern. Open Source ist hier ein Werkzeug für Kontrolle, aber kein automatischer Herkunftsnachweis.

C. Verbleibende Abhängigkeiten

Hardware, Prozessoren, Firmware, Fertigungskapazitäten, Bibliotheken, externe Dienste und spezialisierte Fachanwendungen bleiben häufig von internationalen Lieferketten oder proprietären Komponenten abhängig. Ein seriöses Zielbild benennt diese Grenzen und prüft, wer Roadmap, Lizenzmodell und technische Weiterentwicklung kontrolliert. Europäische Herkunft kann digitale Souveränität unterstützen, ersetzt aber keine offene, kontrollierbare und austauschbare Architektur.

EuroStack und europäische Technologiepolitik: Initiative statt Referenzarchitektur

Die EuroStack-Initiative ist mit Stand Oktober 2026 eine industriepolitische Initiative. Sie will Technologie, Governance und Finanzierung zusammenführen, damit europäische digitale Infrastruktur von Konnektivität über Cloud und Software bis zu KI aufgebaut und genutzt wird. Sie ist damit weder ein Produktkatalog noch eine getestete Referenzarchitektur, die konkrete Komponenten automatisch kompatibel macht.

EuroStack beschreibt die Leitlinien „Buy European“, „Sell European“ und „Fund European“. Die Initiative stellt zugleich klar, dass sie keine vollständige Abkopplung von US-Technologie anstrebt, sondern belastbare europäische Alternativen und mehr Wettbewerb. Diese Selbstbeschreibung und Abgrenzung ist wichtig: Politische Zielsetzung, verfügbare Produkte und praktisch integrierte Betriebsarchitektur sind drei unterschiedliche Reifegrade.

Die EU-Strategie zur Technologiesouveränität umfasst Chips, Infrastruktur, Software, Cloud und KI und verbindet sie unter anderem mit einer Open-Source-Strategie. Der Bericht zur digitalen Dekade 2026 dokumentiert jedoch weiterhin Marktfragmentierung und Fachkräftelücken. Er weist für die EU nur 9 Prozent des weltweiten Halbleitermarkts aus und nennt zugleich erhebliche Abhängigkeiten von Nicht-EU-Anbietern bei Cloud, Cybersecurity und weiteren strategischen Technologien. Produktive europäische und offen entwickelte Bausteine existieren bereits; Integration in großem Maßstab, tragfähige Lieferketten und dauerhaft finanzierbarer Betrieb bleiben davon getrennte Aufgaben.

Die Architektur: funktionale Bereiche statt starre Produktkombinationen

Die folgende Einteilung ist kein verpflichtender Produktkatalog und keine streng übereinanderliegende Schichtenarchitektur. Sie zeigt, welche Aufgaben eine betriebsfähige Plattform abdecken muss und an welchen Stellen Alternativen, Übergänge und Abhängigkeiten geplant werden sollten.

Identitätsmanagement, Sicherheit, Backup, Monitoring, Automatisierung und Lifecycle Management sind zugleich Querschnittsfunktionen. Sie wirken über mehrere Bereiche hinweg und dürfen in einer Visualisierung nicht wie isolierte Endpunkte erscheinen. Auch PKI, Secrets Management, DNS und CI/CD verlaufen quer durch die Architektur. Gerade diese unscheinbaren Abhängigkeiten entscheiden oft darüber, ob eine Migration planbar bleibt.

Weiterführende Einordnungen zu konkreten Bausteinen finden sich auf unseren Seiten zu Proxmox VE, SUSE, SUSE Multi-Linux Manager, Bareos, Keycloak, FreeIPA und Ansible.

Austauschbarkeit bedeutet mehr als die Verfügbarkeit einer Alternative

Für uns bei ForgeOne ist eine Technologie nicht bereits deshalb austauschbar, weil ein anderes Produkt mit vergleichbaren Funktionen existiert. Entscheidend ist, ob der Wechsel geplant, vorbereitet, getestet und mit vertretbarem Aufwand durchgeführt werden kann. Wir unterscheiden deshalb technische Austauschbarkeit und organisatorische Wechselbereitschaft.

Technische Austauschbarkeit

• Dokumentierte Schnittstellen und offene Standards.
• Datenexport, Datenmigration und übertragbare Konfigurationen.
• Reproduzierbare, automatisierte Installation und Konfiguration.
• Dokumentierte Migrations- und Wiederherstellungsverfahren.
• Testbare Alternativplattformen und definierte Rückfallmöglichkeiten.
• Nachvollziehbare Abhängigkeiten zwischen Komponenten.

Organisatorische Wechselbereitschaft

• Aktuelle technische Dokumentation und klare Verantwortlichkeiten.
• Verfügbare interne oder externe Kompetenzen und Supportleistungen.
• Vertragliche Ausstiegsmöglichkeiten und geregelter Datenzugang.
• Geeignete Test- und Migrationsumgebungen.
• Ausreichende zeitliche und personelle Ressourcen.
• Definierte Freigabe-, Abnahme- und Eskalationsprozesse.

Auch eine technisch offene Plattform kann faktisch zu einer Abhängigkeit werden, wenn niemand mehr weiß, wie sie aufgebaut ist, wie ihre Daten exportiert werden oder wie eine Alternative eingeführt werden kann.

„Eine Technologie ist für uns erst dann kontrolliert austauschbar, wenn nicht nur eine Alternative existiert, sondern auch ein dokumentierter und überprüfbarer Weg dorthin.“

Wird eine Virtualisierungsplattform ersetzt, können sich Backup, Netzwerk, Storage, Monitoring und Automatisierung mit verändern. Entscheidend ist nicht, ob jeder Produktname unverändert bleibt, sondern ob die erforderlichen Betriebsfunktionen weiterhin kontrolliert bereitgestellt werden.

Damit unterscheiden wir Produktaustausch und den Austausch eines funktionalen Plattformverbunds. Ein einzelnes Werkzeug lässt sich manchmal direkt ersetzen. In anderen Fällen wird ein Verbund aus Hypervisor, Backup-Ziel, Storage-Treiber und Betriebsprozess gemeinsam neu zusammengesetzt. Eine souveräne Architektur macht diesen Umfang sichtbar, bevor der Wechsel notwendig wird.

Beispiel: von Proxmox VE zu SUSE Virtualization

Ausgangssituation

Eine Organisation betreibt Proxmox VE als Hypervisor, Proxmox Backup Server für VM-Backups, Linux-basierte virtuelle Maschinen, zentrales Monitoring, automatisierte Konfigurationsverwaltung und ein zentrales Identitätsmanagement. Die Plattform ist produktiv; Aufbewahrung, Wiederherstellungsziele und Verantwortlichkeiten sind definiert.

Neue Anforderung

Aus strategischen oder technischen Gründen soll die Virtualisierung künftig mit SUSE Virtualization betrieben werden. Die Entscheidung soll möglich sein, ohne Anwendungen, Identitäten und sämtliche Betriebsprozesse grundsätzlich neu zu entwerfen. Das bedeutet jedoch nicht, dass jede Integration unverändert übernommen werden kann.

Was sich tatsächlich ändert

Proxmox Backup Server ist direkt in Proxmox VE integriert und bietet dort VM- und Container-orientierte Sicherungsabläufe. Daraus folgt keine direkte Wiederherstellbarkeit bestehender PBS-Sicherungen in SUSE Virtualization. Die native Backup- und Restore-Funktion von SUSE Virtualization ist wiederum versions-, Storage- und konfigurationsabhängig. Die offizielle Dokumentation muss deshalb für die eingesetzte Version und das konkrete Backend geprüft werden.

Bareos kann ergänzend agenten- oder anwendungsbasierte Sicherungen innerhalb virtueller Maschinen übernehmen. Das macht Bareos nicht automatisch zum vollständigen Ersatz für alle PBS-Funktionen. VM-Snapshots, vollständige VM-Wiederherstellung, anwendungskonsistente Sicherung, Plattform-Disaster-Recovery sowie RPO und RTO müssen getrennt entworfen und getestet werden.

• Vollständige VM-Sicherungen und die Wiederherstellung kompletter virtueller Maschinen.
• Dateibasierte und anwendungskonsistente Sicherungen innerhalb der Gastsysteme.
• VM-Snapshots als kurzlebiger Betriebsmechanismus statt als alleinige Datensicherung.
• Bare-Metal- beziehungsweise Systemwiederherstellung und Wiederaufbau der gesamten Plattform.
• RPO, RTO, langfristige Aufbewahrung und Zugriff auf historische Backup-Bestände.

Die konkrete Backup-Architektur richtet sich deshalb nach unterstützten Funktionen, Storage-Technologien und Wiederherstellungsanforderungen. Wir erhalten beim Plattformwechsel die erforderlichen Betriebsfunktionen, nicht zwangsläufig dieselben Produkte.

Versionshinweis zur dokumentierten Backup-Funktion: In der hier geprüften SUSE-Virtualization-Dokumentation für Version 1.8 ist die Backup-Unterstützung auf SUSE-Storage-Volumes begrenzt; Volumes auf externem Storage werden mit dieser Funktion nicht gesichert.

Die Tabelle ist zugleich die textuelle Architekturvisualisierung: In beiden Varianten bleiben Linux-Workloads, zentrale Identität, Service-Monitoring, Automatisierungsprinzipien und Collaboration-Anwendungen als Funktionen bestehen. Ausgetauscht werden Virtualisierungs- und native Backup-Schicht; angepasst werden deren Integrationen. Ein automatisches Umschalten wird damit ausdrücklich nicht behauptet.

Beispielhafte Sicherungspfade: Proxmox VE → Proxmox Backup Server → Backup-Storage. In einer möglichen Zielarchitektur: SUSE Virtualization → unterstützte native VM-Backup-Funktionen → geeigneter Backup-Storage. Ergänzend: SUSE Virtualization → Gastbetriebssysteme und Anwendungen → Bareos → Backup-Storage.

Diese Darstellung ist ein Architekturbeispiel und keine vollständig getestete oder zertifizierte ForgeOne-Referenzimplementierung. Eine konkrete Umsetzung muss Version, Storage, Workloads, Konsistenzanforderungen und Restore-Ziele separat validieren.

Herstellerabhängigkeit in der Praxis: VMware VDDK

Das VMware Virtual Disk Development Kit (VDDK) ist ein proprietäres SDK für den Zugriff auf virtuelle VMware-Datenträger. Red Hat empfiehlt ein daraus gebautes VDDK-Image für die Übertragung virtueller Festplatten mit dem Migration Toolkit for Virtualization (MTV); ohne VDDK können Übertragungen deutlich langsamer sein, und bei VMware-vSAN-gestützten virtuellen Maschinen funktioniert dieser MTV-Pfad laut Dokumentation zu den VMware-Voraussetzungen nicht.

Laut dem am 27. August 2026 aktualisierten Red-Hat-Hinweis waren frühere öffentliche Downloadpfade nicht mehr verfügbar. Weil Broadcom das proprietäre Paket besitzt und lizenziert, kann Red Hat das Image nicht selbst verteilen; zu diesem Stand musste der Zugang über den VMware-/Broadcom-Support angefordert werden. Für eine Migrationsplanung bedeutet das: VDDK-Zugang, Nutzungsbedingungen, passende Version und ein intern erreichbares Image müssen vor dem Zeitplan praktisch geprüft werden, statt sie als dauerhaft verfügbare Fremdkomponente vorauszusetzen. Der Red-Hat-Hinweis zur VDDK-Verfügbarkeit beschreibt genau diese Abhängigkeit.

Das macht VMware-Migrationen nicht allgemein unmöglich. MTV kann in bestimmten Konstellationen ohne vSAN auch ohne VDDK arbeiten, allerdings mit möglichen Leistungseinbußen. Red Hat nennt außerdem Storage Copy Offload/XCopy als möglichen Ausweg, wenn das Storage-Backend dies unterstützt. Ob dieser oder ein anderer Export-, Konvertierungs- oder Neuaufbaupfad geeignet ist, hängt von Storage, Workloads, Ausfallfenster und Rückfallanforderungen ab und muss im Lab validiert werden.

Ein kontrollierter Migrationspfad

1. Bestehende Plattform, Abhängigkeiten, Datenpfade und Wiederherstellungsziele dokumentieren.
2. Zielplattform, Storage-Backend und benötigte Begleitwerkzeuge anhand der realen Anforderungen auswählen.
3. Neue Infrastruktur parallel und getrennt von der produktiven Umgebung aufbauen.
4. Backup-, Restore- und Disaster-Recovery-Verfahren vor der ersten produktiven Migration implementieren.
5. Repräsentative Test-VMs einschließlich zustandsbehafteter Anwendungen migrieren.
6. Datenintegrität, Boot, Netzwerk, DNS, Zeit, Performance, Berechtigungen und Anwendungspfade prüfen.
7. Monitoring, Alarmierung, Automatisierung, Inventar und Dokumentation anpassen.
8. Produktive Workloads in kontrollierten Wellen mit Abbruchkriterien migrieren.
9. Wiederherstellung und Rückfall praktisch testen; Ergebnisse und Restabweichungen dokumentieren.
10. Die alte Plattform erst nach fachlicher und technischer Abnahme außer Betrieb nehmen.

Historische PBS-Sicherungen können während einer Übergangsphase weiterhin für Wiederherstellungen auf oder über die bisherige Proxmox-Umgebung benötigt werden. Aufbewahrungsfristen, die Verfügbarkeit der alten Plattform und ein dokumentierter Lesepfad gehören daher in den Migrationsplan.

Austauschbarkeit ist eine Eigenschaft der Architektur

Offene Standards und dokumentierte APIs

OIDC, SAML, LDAP und andere etablierte Protokolle können Kopplungen reduzieren, wenn sie für den jeweiligen Zweck geeignet und sauber implementiert sind. Ein Standard auf dem Datenblatt genügt nicht: Claims, Gruppenabbildung, Zertifikate, Fehlerverhalten und Logout-Pfade müssen dokumentiert und getestet sein.

Datenportabilität

Export- und Importmöglichkeiten müssen die tatsächlich benötigten Daten, Metadaten, Rechte, Historien und Anhänge umfassen. Ein vorhandener Exportknopf ist noch keine verifizierte Datenübernahme. Testimporte und Prüfsummen liefern einen belastbareren Nachweis.

Automatisierung und Trennung

Versionierte Infrastruktur- und Konfigurationsquellen machen Zustände reproduzierbar. Gleichzeitig sollten Hypervisor, Backup, Identity und Anwendungsschicht nicht unnötig vermischt werden. Git-basierte Ansible-Automatisierung hilft besonders dann, wenn allgemeine Rollen von plattformspezifischen Modulen getrennt bleiben.

Dokumentation, Validierung und Exit

Abhängigkeiten, Schnittstellen, Credentials-Pfade, Restore-Verfahren und Eigentümerschaft müssen verständlich dokumentiert sein. Alternative Plattformen und Wiederherstellungen gehören regelmäßig ins Lab. Bereits bei der Einführung sollte feststehen, wie Daten exportiert werden, welche Komponenten ersetzt werden müssten und wie lange notwendige Altzugriffe erhalten bleiben. Offene Standards verbessern die Ausgangslage, garantieren aber keine vollständige Austauschbarkeit.

Zeitliche Zielsetzung ohne falsche Versprechen

Technologiewechsel sollen mit ausreichender Vorbereitung in überschaubaren und planbaren Zeiträumen realisierbar bleiben. Eine pauschale Zusage für wenige Tage wäre unseriös. Anzahl und Kritikalität der Systeme, Datenvolumen, Anwendungskopplungen, Schnittstellen, Verfügbarkeitsanforderungen, Compliance, verfügbare Fachkräfte und Testumfang bestimmen den Aufwand.

Der Architekturgewinn liegt darin, dass Alternativen und Abhängigkeiten schon bei der Einführung dokumentiert, Automatisierung wiederverwendbar gehalten und Migrationen im Lab erprobt werden. Dadurch muss ein Wechsel nicht automatisch zu einem monatelangen Grundsatzprojekt werden. Produktive Wechsel benötigen trotzdem eine eigene Risiko-, Ressourcen- und Zeitplanung sowie eine fachliche und technische Abnahme.

Wo Europa bereits gut aufgestellt ist

Grenzen eines europäischen IT-Stacks

• Integration: Standardisierte Schnittstellen erleichtern die Verbindung produktiv verfügbarer Komponenten. Einheitliche Upgrades, Fehlerbilder und Ende-zu-Ende-Support entstehen daraus jedoch nicht automatisch.
• Betrieb: Ein modularer Stack verlangt zusätzliche Integrations-, Kompatibilitäts- und Wiederherstellungstests. Auch Proxmox, SUSE und offene Projekte müssen nach denselben Kriterien für Lifecycle, Monitoring und Support bewertet werden.
• Funktionsumfang: Eng integrierte Plattformfunktionen, proprietäre Fachanwendungen, Spezialhardware und historisch gewachsene Automatisierung lassen sich nicht immer eins zu eins ersetzen.
• Lieferketten: Abhängigkeiten bei Prozessoren, Fertigung, Firmware, Netzwerkkomponenten, Bibliotheken, Drittanbietern und einzelnen Cloud-Diensten bleiben bestehen.
• Wirtschaftlichkeit: Eine Migration kann technisch möglich und trotzdem unverhältnismäßig sein, wenn Anpassung, Parallelbetrieb, Tests und Schulung mehr kosten als das vermiedene Risiko.
• Kompetenz und Verantwortung: Fachkräfte, belastbare Dokumentation, Hersteller- oder Community-Support und klare Eskalationswege bestimmen, ob Eigenbetrieb tatsächlich mehr Kontrolle schafft.

Eine belastbare Entscheidung vergleicht deshalb nicht nur Lizenzkosten oder Herkunft. Sie bewertet technische Abhängigkeiten, Betriebsaufwand, Ausfallrisiko, Exit-Kosten und verfügbare Kompetenzen über den geplanten Lebenszyklus. Digitale Souveränität ist dabei kein erreichter Endzustand, sondern die nachweisbare Fähigkeit, Entscheidungen und Wechsel unter realistischen Bedingungen selbst zu steuern.

Unsere Position bei ForgeOne

Wir glauben nicht, dass Europa sämtliche IT-Technologien neu entwickeln muss. Viele geeignete Produkte und Open-Source-Projekte existieren bereits. Entscheidend ist, sie sinnvoll zu kombinieren, ihre Grenzen zu verstehen und eine Architektur aufzubauen, die langfristig anpassbar bleibt.

Wir möchten keine neue geschlossene Plattform schaffen. Unser Ansatz ist eine offene, modulare Infrastruktur, bei der einzelne Technologien und bei Bedarf ganze funktionale Plattformverbünde kontrolliert ausgetauscht werden können. Technologien sind für uns Werkzeuge, keine unumkehrbaren Entscheidungen.

Das gilt auch oberhalb der Infrastruktur: grommunio, Nextcloud, OpenProject und XWiki können je nach Anforderungen unterschiedliche Aufgaben im digitalen Arbeitsplatz übernehmen. Souverän wird daraus erst ein System mit dokumentierten Datenpfaden, Identitäten, Backups, Updates und Exit-Optionen.

Fazit

Ein vollständig europäischer IT-Stack ohne internationale Abhängigkeiten ist heute nur eingeschränkt realisierbar. Für klar abgegrenzte Anforderungen kann bereits heute ein weitgehend europäischer und Open-Source-basierter Stack aufgebaut werden. Ob er souverän betreibbar ist, muss die konkrete Organisation durch getestete Betriebs-, Wiederherstellungs- und Exit-Verfahren nachweisen.

Die eigentliche Herausforderung besteht nicht darin, für jede proprietäre Anwendung einen europäischen Produktnamen zu finden. Sie besteht darin, Komponenten so zu verbinden, dass Organisationen die Kontrolle über Infrastruktur, Daten und Veränderungen behalten.

Für uns ist eine IT-Architektur dann wirklich souverän, wenn wir nicht nur entscheiden können, welche Technologie wir heute einsetzen, sondern auch, welche wir morgen wieder ersetzen.

Eine breitere Einordnung unseres Ansatzes bietet die Seite Digitale Souveränität; Anforderungen an Datensicherung und Wiederanlauf vertieft der Bereich Backup und Data Protection.