© Alexander Korzh / 123RF.com

Der Sovereign Cloud Stack nimmt für sich in Anspruch, digitale Souveränität für Cloud-Setups auf eigener Infrastruktur zu ermöglichen. In der Realität hält sich die Anzahl der Dienstleister, die SCS unterstützen, jedoch noch in engen Grenzen. Was kann SCS wirklich?

Das Schlagwort digitale Souveränität hat in jüngerer Vergangenheit einiges Interesse auf sich gezogen. Völlig zu Recht, möchte man hinzufügen: Einerseits wird die Welt schließlich stetig komplizierter, andererseits verlagern sich immer größere Teile des Alltags in die digitale Hemisphäre. Da ist es nur folgerichtig, dass Gesellschaften ein Interesse daran haben, ihre eigenen digitalen Belange zumindest zum größten Teil unter Kontrolle zu behalten.

Mit den Hyperscalern – also AWS, Azure und GCP – lässt sich das aus europäischer Sicht nicht umsetzen: Sie unterliegen zuerst der amerikanischen Gesetzgebung und dienen vorrangig US-amerikanischen Interessen. An manchen Stellen wird das überdeutlich, etwa bei der Kollision der europäischen DSGVO mit dem US Cloud Act, für die eine echte Lösung bis heute nicht in Aussicht ist. Selbst der Politik ist schon vor Jahren klar geworden, dass Europa sich selbst um seine digitalen Belange kümmern muss, will es nicht Spielball anderer Mächte sein. Daraus resultierten Großprojekte wie Gaia-X, die bisher aber weniger öffentlich wahrnehmbaren Output geliefert haben, als es den jeweiligen Machern wohl lieb gewesen wäre.

Der Sovereign Cloud Stack [1] steht für digitale Souveränität von unten: Auf Basis freier Software wollen seine Macher eine Plattform definieren, die offene Standards nutzt und eine echte Wahl zwischen Anbietern ermöglicht. Dabei soll sie alles mitbringen, was ein Dienstleister benötigt, um digitale Plattformen schnell an den Start zu bekommen und komfortabel zu betreiben. Auf namhafte Kunden kann das Projekt trotz seines geringen Alters durchaus zurückblicken, Leuchtturmprojekte gibt es also.

Andererseits ruft der SCS bei manchem Beobachter durchaus Argwohn hervor, denn die Anzahl der Anbieter, die SCS-kompatible Clouds betreiben, ist im Augenblick noch sehr übersichtlich. Wer selbst eine Plattform für Cloud-Workloads bauen möchte, die den SCS nutzt, findet kaum Anbieter am Markt, die ihn entsprechend unterstützen. Hinzu kommt, dass es manchem potenziellen Kunden des Sovereign Cloud Stack durchaus schwerfällt, die Details der Lösung überhaupt zu erfassen.

Der Begriff des Stacks führt hier in gewisser Weise in die Irre: Er legt eine gewisse Nähe zu anderen Plattformlösungen wie OpenStack oder Cloud Stack nahe. Genau das ist der SCS aber explizit nicht, nämlich eine konkrete technische Lösung. Will man also verstehen, welche Stoßrichtung der SCS verfolgt und wie gut die Umsetzung bereits klappt, sieht man sich besser die handelnden Personen und die Ziele an, die sie mit dem Sovereign Cloud Stack verfolgen.

Hohe technische Komplexität

Auf den Punkt gebracht, arbeitet der Sovereign Cloud Stack auf die Definition einer Referenzumgebung hin, die Firmen aller Art dabei hilft, zum Plattformanbieter zu werden [2]. Ob es dabei um private Plattformen oder um Public Clouds geht, spielt zunächst gar keine große Rolle. Ebenso egal ist, welche Virtualisierung auf einer geplanten Plattform zum Einsatz kommt. Ob es also um Voll- oder Paravirtualisierung geht oder stattdessen Container ins Spiel kommen, spielt keine Rolle.

Wichtig ist aber, dass das Umsetzen einer solchen Plattform ein technisch hochkomplexer Vorgang ist, der selbst erfahrene IT-Architekten vor erhebliche Herausforderungen stellt. Es gilt, eine enorme Anzahl verschiedener Faktoren unter einen Hut zu bringen: Autorisierung, Authentifizierung und umfassende Benutzerverwaltung, klassisches Lifecycle-Management für die physischen Systeme der Umgebung, die Verwaltung von Ressourcen für Storage und Compute, Automation und Orchestrierung sowie viele andere Aspekte sind von Bedeutung.

Für praktisch jeden dieser Faktoren existieren am Markt verschiedene technische Umsetzungen, die meisten davon proprietär. Das stellt aus Sicht der Befürworter digitaler Souveränität ein großes Problem dar. Echte Souveränität erfordert in deren Augen im Kontext digitaler Plattformen – anders, als Medien und Politik es oft suggerieren – eben nicht nur, dass die eigenen Daten den eigenen Rechtsraum nicht verlassen. Vielmehr muss digitale Souveränität es auch ermöglichen, zwischen mehreren Anbietern vergleichbarer Lösungen hin und her zu migrieren oder hybride Umgebungen zu bauen. Das vermeidet den in der IT ganz generell so gefürchteten Hersteller-Lock-in – praktisch eines der wichtigsten Werkzeuge von Anbietern wie Azure, AWS oder GCP. Wer es sich erst einmal in der Public Cloud bequem gemacht hat und die dortigen Dienste intensiv nutzt, kann seine Umgebung nicht mal eben zu einem anderen Anbieter umziehen.

Ein eherner Grundsatz des Sovereign Cloud Stack ist deshalb, sich an offene Standards zu halten und quelloffene Software zu verwenden. Vor dem Hintergrund der Personen, die den SCS entwickeln und vorantreiben, kann das kaum überraschen. Projekt-CTO Kurt Garloff hat eine lange OSS-Geschichte und ist tief in der Open-Source-Community verwurzelt. Er war zudem bei T-Systems maßgeblich an der Open Telekom Cloud (Abbildung 1) und ihrer Bereitstellung beteiligt, kann also auf reichlich Erfahrung zurückblicken, wenn es um Plattformen auf Grundlage offener Standards geht.

Abbildung 1: Die Open Telekom Cloud war eine der ersten Nicht-Hyperscaler-Clouds in Deutschland und nutzt OpenStack-APIs, also offene Standards. SCS-CTO Kurt Garloff war an ihrer Planung maßgeblich beteiligt und hat insofern ein Gespür für das Thema digitale Souveränität.

Allein: Alle ehernen Grundsätze und Bekenntnisse zu offenen Standards helfen höchstens ideologisch. Allein dadurch, dass der Sovereign Cloud Stack als Spezifikation existiert, hat ein Admin noch keine einzige virtuelle Instanz zur Verfügung gestellt und kein einziges Megabyte On-Demand-Speicher angeboten. Will man über technischen Sinn und Unsinn des SCS diskutieren, muss man stattdessen einen genaueren Blick auf seinen Inhalt und die dort referenzierten Tools und Komponenten werfen.

Bekannte Namen

Das wiederum macht einem der Sovereign Cloud Stack einigermaßen leicht. Neben der Beschreibung in Textform liegt eine ausführliche Grafik vor, in der die SCS-Macher die Werkzeuge ihres Konzepts auflisten und kategorisieren [3]. Dabei gehen sie problemorientiert vor: Sie definieren also zentrale Funktionen, die für den effizienten Betrieb einer skalierbaren Computing-Plattform notwendig sind, und geben dann jeweils Software oder Standards an, die diese einzelnen Funktionen praktisch umsetzen.

Nicht jedes im SCS genannte Programm ist dabei automatisch Pflichtkomponente. Stattdessen unterscheidet der SCS zwischen Tools, die unverrückbar Bestandteil jeder SCS-Installation sein sollen, und Werkzeugen, die sich bei Bedarf als offizielle SCS-Komponente zusätzlich ausrollen lassen. Schnell sticht bei einem Blick auf die genannte Zeichnung ins Auge, dass die eigentlichen Kernkomponenten des SCS gar nicht so zahlreich sind.

Im Hinblick auf zu nutzende Standards definiert der SCS auf der Ebene dynamisch nutzbaren Speichers lediglich das S3-Protokoll als unverrückbaren Standard. Detaillierter geht es beim Container-Layer zu, also auf jener Ebene, die die Grundlagen für den Betrieb einer skalierbaren Container-Plattform schafft: Hier ist Kubernetes ebenso gesetzt wie seine Schnittstellen für Storage- und Netzwerkanbindungen über Software Defined Storage (SDS) und Software Defined Networking (SDN). Der Kubernetes-Paketmanager Helm sowie die Container-Registry Harbor gehören ebenfalls zum Paket. In Sachen Autorisierung und Authentifizierung legt der SCS darüber hinaus bloß noch SAML und OpenID Connect als zwingende Voraussetzungen für die Föderation zwischen SCS-kompatiblen Plattformen fest. Fertig ist der Lack: Mehr muss ein Administrator streng genommen nicht administrieren, um eine mit dem SCS kompatible Plattform zu schaffen.

Ganz so einfach gestaltet sich die Sache in der Praxis dann allerdings doch wieder nicht. Hinzu kommt, dass der größte Teil der genannten Dienste und Protokolle impliziter Teil des Pakets SCS Platform Services ist, die das SCS-Projekt in Sachen Marketing geschickt nutzt: Die fraglichen Plattformdienste, so lautet das Versprechen, bilden die Grundlage für die Entwicklung neuer offener Standards und offener Schnittstellen für den Austausch von Daten, etwa im Gaia-X-Kontext. Tatsächlich definierte man im SCS-Projekt die Gruppe der Platform Services sogar auf Grundlage dessen, was Gaia-X in seinem Anforderungskatalog für Dienste fordert, die dem souveränen Austausch von Daten dienen.

Kubernetes rollt sich schließlich nicht von allein aus, ein Speicher mit S3-Protokoll fällt nicht vom Himmel, und Bare-Metal-Systeme verwalten sich nicht von allein. Wirklich als Plattform für Anbieter nutzbar wird der SCS erst mit jenen Komponenten, die der SCS als Optional Standard definiert und für die er eine offizielle Referenzimplementierung in Form einer konkreten Lösung vorgibt. Damit werden Linux, KVM und Libvirt ebenso Teil der Gleichung wie alle Grundkomponenten von OpenStack, die sowohl Paravirtualisierung anbieten als auch das Fundament für Container-Virtualisierung schaffen sollen.

Auch auf den Objektspeicher Ceph hat man sich festgelegt, der in Form des RADOS Gateways das geforderte S3-Protokoll praktischerweise gleich implementiert. Zudem sind dann die SDN-Standards Open vSwitch und Open Flow mit von der Partie. Schließlich gibt der SCS etliche weitere Standardkomponenten vor, die in einer SCS-Installation vorhanden sein können, aber nicht müssen: Prometheus und Grafana etwa für Teile des Themas Observability, Ansible für Automation oder Zuul für Continuous Development und Continuous Integration.

Damit ist klar: Auf dem Papier ist der Sovereign Cloud Stack ein moderner Standard. Er fungiert als eine Art Best-of-Breed-Liste von Open-Source-Software und von offenen Standards für den Betrieb von Plattformen, die den eigenen Kunden echte digitale Souveränität ermöglichen. Lediglich eine Lücke an einer einzigen Stelle vermögen Kritiker auszumachen, nämlich im Hinblick auf das Lifecycle-Management physischer Maschinen.

Auch das, so liest man mancherorts, sollte der SCS detailliert festschreiben und mit Referenzlösungen versehen. Bisher konnten die SCS-Macher dieser Idee allerdings nichts abgewinnen: Wie ein Unternehmen seine physischen Systeme verwaltet, mit denen es später die SCS-Plattformdienste anbietet, bleibt aus Kundensicht ohnehin im Verborgenen. Damit ist es für die Funktionalität des SCS irrelevant.

Machen statt lesen

Viel schlimmer als irgendwelche Debatten im Hinblick auf Bare-Metal-Lifecycle-Management ist für den SCS ohnehin ein Problem, mit dem er quasi seit Projektbeginn zu kämpfen hat: Ein schöner und offener Standard hilft nicht, wenn das konkrete Ziel darin besteht, eine technische Plattform zu bauen und an Kunden zu verkaufen.

Begibt sich ein dem SCS zugeneigter Administrator auf die Suche nach Anbietern, die ihm eine SCS-kompatible Cloud bauen, oder nach Produkten, die er dafür nutzen kann, stellt sich schnell Frust ein: Die Anzahl der Unternehmen, die dafür zur Verfügung stehen, ist nicht sonderlich hoch. Auch die Liste der Fertiglösungen, mittels derer sich SCS implementieren lässt, bleibt recht überschaubar. Selbst, wer “nur” Kunde auf einer SCS-kompatiblen Cloud werden möchte, hat im Augenblick kaum echte Auswahl.

Die Gründe dafür liegen auf der Hand: Hier spielt vor allem die hohe implizite technische Komplexität massiv skalierbarer Umgebungen eine große Rolle. Ohnehin schrumpft die Zahl entsprechender Lösungen von der Stange seit Jahren. Das gilt umso mehr, wenn OpenStack zum Einsatz kommen soll, wie der SCS es vorsieht. Gerade während des großen OpenStack-Hypes von 2012 bis 2015 beispielsweise haben sich in den USA und in Europa zahllose Unternehmen die Zähne an OpenStack-Projekten ausgebissen. Seither haftet der Plattform der Ruf an, verbrannt zu sein, und viele Administratoren ergreift die blanke Panik, wenn sie den Begriff OpenStack auch nur hören.

Aus heutiger Sicht erscheint das freilich zum Teil unfair. Seit seinen Anfängen hat sich OpenStack massiv weiterentwickelt und gilt heute als robuste und stabile Lösung. Insbesondere in der Volksrepublik China ist OpenStack deshalb mittlerweile weitverbreitet und sehr beliebt. Dort entstehen regelmäßig neue Cloud-Rechenzentren auf Grundlage der OpenStack-APIs. Einen großen Teil der OpenStack-Compute-Leistung findet man heute im Reich der Mitte.

Im Okzident aber trauen sich viele an OpenStack einfach nicht mehr heran, weil praktisch jeder eine Horror-Geschichte auf OpenStack-Basis kennt. Suse hat sein OpenStack-Engagement schon vor Jahren komplett aufgegeben (Abbildung 2). Selbst Red Hat als einer der bisher größten OpenStack-Befürworter hat mittlerweile seinen Red Hat OpenStack (Abbildung 3) abgekündigt, um Kunden in Richtung Kubernetes zu manövrieren, also zu OpenShift. Von den großen Anbietern vermarktet lediglich Canonical noch eigene OpenStack-Produkte und bietet Neuverträge für OpenStack-Support und OpenStack-Plattformen an.

Abbildung 2: Suse gehörte einst zu den OpenStack-Pionieren am deutschen Markt, hat aber längst alle OpenStack-Aktivitäten eingestellt. Quelle: Suse

Abbildung 3: Selbst Red Hat als einst weltgrößter Unterstützer der OpenStack-Community hat seine OpenStack-Produkte abgekündigt und setzt künftig voll auf OpenShift. Quelle: Red Hat

Zumindest theoretisch wäre es auf dieser Grundlage also möglich, SCS-kompatible Clouds auf OpenStack-Basis zu bauen. Dass der OpenStack von Canonical mehrere Komponenten für das Lifecycle-Management physischer Systeme im Schlepptau hat, die sich mit den Prinzipien des SCS eigentlich nicht in Einklang bringen lassen, spielt dabei erst einmal keine Rolle: Gerade deshalb klammert der SCS ja (zumindest bisher) das Thema Lifecycle-Management der physischen Systeme weitgehend aus.

Darüber hinaus sieht es in Sachen OpenStack am Markt allerdings düster aus. Kleinere Anbieter wie Mirantis legen den Fokus mittlerweile meist vollständig auf Container-Virtualisierung und Kubernetes. So wähnt sich der eigentlich an SCS interessierte Administrator in der ausweglosen Situation, eine Plattform bauen zu wollen, aber schlicht nicht die technischen Mittel zur Verfügung zu haben.

OSISM will helfen

An dieser Stelle kommt OSISM [4] ins Spiel, die einzige derzeit marktverfügbare Sammlung von Open-Source-Werkzeugen, die den SCS praktisch implementiert. Schon der Name ist Programm, denn das Akronym OSISM steht für Open Source Infrastructure & Service Manager und beschreibt sich im Subtext als “europäische OpenStack- und Ceph-Distribution”.

OSISM entspringt der Feder des gleichnamigen Unternehmens aus Stuttgart. Eine zentrale Figur dahinter ist Christian Behrendt, eine echte Größe in der deutschsprachigen OpenStack- und Kubernetes-Community, der im engen Austausch mit den Verantwortlichen des Sovereign Cloud Stack steht. Zentral beteiligt ist obendrein B1 Systems, ein renommierter Linux-Dienstleister aus Franken. Praktisch sammelt OSISM damit ein gerüttelt Maß an deutschem Linux Know-how hinter sich – sicher keine schlechte Voraussetzung für technischen Erfolg.

Was aber bekommen Kunden im Detail, wenn sie sich für OSISM entscheiden? Zunächst einmal reichlich Open-Source-Software gerade für den IaaS- und PaaS-Teil einer skalierbaren Computing-Plattform. Hinzu kommen einige Komponenten, die weit über das hinausgehen, was der SCS fordert. Gerade für IaaS braucht man ja Massen physischer Compute-Knoten, die man sinnvoll und automatisiert verwalten möchte, etwa durch die automatisierte Installation des Betriebssystems.

OSISM gibt sich hier modern und liefert einen auf dem Prinzip von Infrastructure as Code basierten Ansatz. Weite Teile der Konfiguration verwaltet die Lösung entsprechend in Git. Nach dem Deployment einiger Grunddienste übernehmen die OSISM-Komponenten dann das weitere Ausrollen der nötigen Software. Dabei setzt das Werkzeug ausschließlich auf solche Softwarekomponenten, die die SCS-Definition vorgibt. Teil des Pakets sind mehrere eigene Module, deren Umfang mittlerweile über den von OpenStack sogar hinausgeht: Neben Ceph und OpenStack pflegt OSISM heute eine eigene Kubernetes-Distribution und bietet die Funktion Kubernetes-as-a-Service (KaaS [5]). Kunden einer SCS-basierten Plattform erhalten dadurch in wenigen Sekunden eine gehostete Kubernetes-Umgebung, ähnlich wie AWS EKS oder Azure AKS.

Der Autor dieses Artikels hatte bisher bereits bei mehreren Projekten die Gelegenheit, frühe Versionen von OSISM unter die Lupe zu nehmen, und fand an der technischen Umsetzung durchaus Gefallen. Mit OSISM lässt sich zweifelsfrei eine skalierbare, gut zu verwaltende und sinnvoll automatisierte Compute-Plattform konstruieren, die sowohl IaaS als auch Container-Workloads effizient betreiben kann. Auch OSISM ändert aber nichts daran, dass potenzielle Interessenten für das Thema dazu bereit sein müssen, sich eine umfassende Lösung mit hoher impliziter Komplexität ins Rechenzentrum zu holen.

Mangels entsprechender Informationen lässt sich kaum realistisch einschätzen, wie viele private OSISM-Setups – und mithin SCS-kompatible Setups – mittlerweile existieren. Im Hinblick auf SCS-kompatible Public Clouds kann man aber zumindest sagen, dass solche bisher spärlich gesät sind: Lediglich Plusserver in Köln ist am Markt mit seiner PlusCloud Open vertreten (Abbildung 4).

Abbildung 4: Die PlusCloud Open ist die erste verfügbare Public Cloud auf Grundlage von SCS und OSISM. Eine echte Auswahl haben potenzielle SCS-Public-Cloud-Kunden bisher insofern nicht.

Wette auf die Zukunft

Gerade vor dem Hintergrund der bereits verfügbaren Qualität von Lösungen wie OSISM können die Gründe dafür aber nicht nur funktionaler Art sein. Mit den Ausschlag geben dürfte, dass der Bau einer solchen Plattform stets mit einer gehörigen Wette auf die Zukunft verbunden ist. Bei allen (völlig berechtigten) ideologischen Aspekten im Hinblick auf souveränes Cloud-Computing ist auch klar, dass sich der Betrieb der Plattformen für den Anbieter kommerziell lohnen muss. Anderenfalls ergäbe ein SCS-basiertes Projekt schlicht keinen Sinn. Lohnen heißt dabei, dass es mehr Geld abwerfen muss, als es kostet.

Das ist im Kontext skalierbarer Plattformen für Computing-Dienste kein einfaches Unterfangen: Sie verschlingen gerade zu Beginn der Planung und des Aufbaus absurde Mengen Geld. Es gilt, zunächst, die gesamte umgebende Infrastruktur bereitzustellen, also ein Rechenzentrum mit genügend Fläche, Strom und Kühlung. Dann müssen zentrale Dienste wie das Netzwerk funktionieren, wobei skalierbare Setups moderne Technologien wie Spine-Leaf-Architekturen erfordern. Obendrein braucht es riesige Mengen an Compute- und Storage-Systemen für die Plattform selbst. Hinzu kommt die Notwendigkeit, viel Personal für Betrieb und Support einzustellen, das man am Markt entweder gar nicht erst findet oder nur für viel Geld bei der Konkurrenz abwerben kann.

Ein solches Projekt bricht man also nur vom Zaun, wenn man ein funktionierendes Geschäftsmodell hat und obendrein technische Lösungen zur Verfügung stehen, von denen man annimmt, man könne sich langfristig auf sie und auf ihre Funktionalität verlassen. Genau darin dürfte der eigentliche Grund dafür liegen, dass der SCS bisher nicht für mehr Furore gesorgt hat.

Kurt Garloff und seine Mitstreiter haben die Organisation hinter dem SCS unter die Obhut der Open Source Business Alliance e.V. (OSBA [6]) gestellt. Ein Großteil der SCS-spezifischen Entwicklung wurde bisher über Fördergelder finanziert, etwa im Rahmen von Gaia-X oder über die Bundesagentur für Sprunginnovation. Es lässt sich jedoch absehen, und an dieser Stelle spielen die SCS-Macher wie immer mit absolut offenen Karten, dass die Fördergelder für SCS und verbundene Projekte nicht ewig fließen.

In Geldnot ist SCS zwar nicht, doch bei einem deutschen eingetragenen Verein wie der OSBA wird anders als bei einem US-Startup nicht von Anfang an mit Beträgen im Millionenbereich hantiert. Das dürfte bei einigen Beobachtern durchaus Zweifel auslösen, ob es sich bei SCS um eine nachhaltige Lösung handelt oder doch nur um ein kurzes Strohfeuer europäischer Souveränitätsträume. In Letzteres möchten die meisten potenziellen Betreiber entsprechender Plattformen wohl eher keine Millionen versenken – nachvollziehbar.

Es ergibt sich das typische Henne-Ei-Problem: Erfolg wäre das perfekte Werkzeug für den SCS, unter Beweis zu stellen, dass man gekommen ist um zu bleiben. Ohne am Markt breit und erfolgreich aufgestellt zu sein, bleibt man für viele potenzielle Kunden aber langfristig uninteressant und kann nur schwer die eigene Nachhaltigkeit unter Beweis stellen. Ein Pfund, mit dem man wuchern könnte, gibt es allerdings: Das technologische Fundament auf Basis von OpenStack und Kubernetes kommt außerhalb der formalen Organisation des SCS bereits gut an.

Fast alle europäischen Alternativen zu Hyperscalern, darunter Cleura aus Schweden (Abbildung 5) oder OVH aus Frankreich, setzen ebenfalls auf ein Gespann aus OpenStack und Kubernetes – und mithin grundsätzlich auch auf zum SCS kompatible APIs. Technische Details im Hinblick auf etwa die Föderation zwischen mehreren Plattformen unterscheiden sich dann zwar. Die Möglichkeit, zwischen den Plattformen zu wechseln und dieselben Werkzeuge hier wie dort zu verwenden, ist jedoch durchaus gegeben. Zu einer typischen SCS-Installation (teil)kompatible Clouds gibt es also bereits, auch wenn das so ursprünglich nicht geplant war. Darauf lässt sich technisch wie kommerziell aufbauen.

Abbildung 5: Andere europäische Public Clouds wie Cleura sind zwar nicht vollständig mit dem SCS kompatibel, nutzen aber immerhin dieselben Komponenten. Hier wäre der Wechsel zwischen den Anbietern also mit Einschränkungen bereits möglich.

Fazit

Die technische Bewertung des Sovereign Cloud Stack ist schnell erledigt. Der Standard selbst setzt auf gut etablierte Werkzeuge, Protokolle und Schnittstellen und schafft mithin ein ideales Fundament für tatsächliche Souveränität im Cloud-Kontext. OSISM als erste Zielimplementierung von SCS zeigt sich in einem guten Zustand und vermag grundsätzlich zu überzeugen. Der Vergleich mit anderen Produkten fällt schwer, weil es davon am Markt kaum welche gibt. Mit der vergleichbaren Lösung von Canonical jedoch zeigt OSISM sich durchaus auf Augenhöhe. Sollte der SCS letztlich scheitern, liegt das sicher nicht an der Technik.

Sorgen bereitet allerdings der Umstand, dass sich die Zukunft von SCS und dem damit eng verbundenen OSISM nicht wirklich absehen lässt. Die SCS-Macher immerhin agieren in dieser Hinsicht vorbildlich transparent, doch nutzt das einem potenziellen Plattformanbieter nicht, wenn er über ein großes Investment entscheiden muss. Viel wird in Sachen SCS daher davon abhängen, ob es gelingt, weitere Provider und Unternehmen für den Bau SCS-kompatibler Plattformen zu gewinnen und damit einen echten, innereuropäischen Wettbewerb zwischen SCS-Plattformen zu etablieren. Dann könnte es auch für größere Kreise potenzieller Kunden interessant werden, sich auf Alternativplattformen zu AWS, Azure & Co. einzumieten.

Bei den Hyperscalern landet nämlich noch immer das größte Stück des kommerziellen Cloud-Kuchens, obwohl gerade sie mit digitaler Souveränität absolut nichts am Hut haben. Daran ändern auch irgendwelche Setups vor Ort nichts, die trotzdem unter der Knute des Anbieters und dadurch indirekt unter den Fittichen der US-Regierung stehen. Echte digitale Souveränität lässt sich ideologisch wie technisch nur mit einem Ansatz wie dem des SCS erzielen. Allen, die Wert auf digitale Souveränität und offene Standards legen, gerade auch den Europäern, bleibt nur die Hoffnung, dass der SCS seine bisherigen Erfolge ausbauen kann und sich zu einer relevanten Marktgröße entwickelt. (jcb/jlu)