© fotokvadra / 123RF.com

Der Sovereign Cloud Stack ist eine Sammlung von Standardkomponenten für private Cloud-Umgebungen, die ausschließlich auf Open-Source-Software basiert und so für Datensouveränität sorgen soll. Was ist das Ziel der Macher, und was hat es mit dem Konzept des Open Operatings auf sich?

Seit IT-Infrastruktur immer häufiger der Cloud zugutekommt und seit Firmen immer stärker von den IT-Umgebungen der Plattformbetreiber abhängen, mehren sich die Stimmen, die fehlende digitale Souveränität beklagen. Der Begriff ist so neu wie sperrig, und wirklich definiert ist er auch nicht.

Wenn Unternehmen über digitale Souveränität sprechen, gibt es allerdings zumindest so etwas wie einen kleinsten gemeinsamen Nenner: Wer Daten in eine Cloud auslagert, gibt die Kontrolle über sie praktisch auf. Das ist nur dann akzeptabel, wenn ein unbedingtes Vertrauensverhältnis zwischen Kunde und Plattformbetreiber besteht, denn der Kunde riskiert viel: Beispielsweise ließen sich allein durch das gezielte Vorenthalten von Daten Firmen und ganze Wirtschaftszweige mit wenig Aufwand ruinieren. Und selbst wenn die bösen Absichten gar nicht so weit gehen: Exponierte Daten auf fremden Systemen sind in jedem Fall ein potenzielles Ziel für Wirtschaftsspionage.

Mittlerweile beschäftigt das Thema auch die höchsten Kreise deutscher wie europäischer Politik. Weil die großen Hyperscaler samt und sonders in den USA sitzen, schlagen hiesige Behörden und Institutionen Alarm. Sie weisen dabei einerseits auf die Probleme hin, die sich aus bereits bestehendem Regelwerk wie der DSGVO ergeben, und warnen andererseits vor der Abhängigkeit deutscher und europäischer Unternehmen, die durch die Nutzung von Big Tech aus den USA entsteht. Die Interessen deutscher und amerikanischer Unternehmen müssen sich nicht immer decken, und so kann es nachteilig sein, wenn das Gegenüber am längeren Hebel sitzt und man nicht frei entscheiden kann.

Entsprechend, so werden europäische Politiker und Behörden nicht müde zu betonen, müsse man das eigene digitale Schicksal selbst in die Hand nehmen. Das geschieht in Ansätzen durchaus: Gaia-X (Abbildung 1) ist nur ein Beispiel für eine Reihe von Projekten, die darauf abzielen, die digitale Unabhängigkeit europäischer Institutionen zu erhöhen. Auch wenn es für die breite Öffentlichkeit oft nicht so aussieht, ist Gaia-X kein Papiertiger, denn im Hintergrund arbeiten und forschen die diversen Mitglieder des Konsortiums an verschiedenen Ansätzen – und das durchaus mit Erfolg.

Abbildung 1: Allen Kritikern zum Trotz produziert Gaia-X nicht nur Altpapier, und der Sovereign Cloud Stack schickt sich an, ein solides technisches Fundament für die Gaia-X-Schnittstellen zu werden. Quelle: BMWI

Echte Souveränität mit SCS

Handfest und konkret geht das Projekt Sovereign Cloud Stack (SCS) die Sache an. Im Fokus von SCS steht das Schaffen eines Software-Stacks, der Komponenten aus der Open-Source-Welt kombiniert und fit für den Einsatz macht. Damit sollen hiesige Unternehmen standardisierte, offene Cloud-Plattformen im eigenen Rechenzentrum betreiben können.

SCS geht sogar noch ein paar Schritte weiter: Langfristig möchte man auch die Art und Weise verändern, wie das Operating von großen Plattformen funktioniert. Es geht dabei vor allem darum, von alten, konventionellen Ansätzen wegzukommen und stattdessen Offenheit und Transparenz zu verwirklichen. Dieser Artikel stellt Sovereign Cloud Stack vor, geht auf die Ideen dahinter ein und beleuchtet auch das mit SCS verbundene Konzept des Open Operatings im Detail.

Wie SCS funktioniert

Wer sich erstmals auf der SCS-Website [1] umsieht, hat es anfangs gar nicht so leicht, die Funktionsweise des Projekts zu verstehen oder herauszufinden, was SCS denn nun eigentlich ist und was er bietet. Zunächst beschreibt der Sovereign Cloud Stack sich auf seiner eigenen Website nämlich primär als Konsortium verschiedener Anbieter und Hersteller, die sich das Ziel der digitalen Souveränität auf die Fahnen geschrieben haben.

Das Ziel, so steht da zu lesen, sei ein standardisierter Technik-Stack, der nicht nur auf offenen Standards basieren und technisch einwandfrei funktionieren soll: Auch das Thema Federation spielt beim Sovereign Cloud Stack eine bedeutende Rolle. Damit meinen die Firmen hinter der Idee, dass verschiedene SCS-Clouds interoperabel sein sollen. Das ideale Ziel besteht darin, dass Kunden vom SCS-kompatiblen Stack eines Anbieters zu dem eines anderen wechseln können, ohne sich großem Migrationsaufwand gegenüberzusehen.

Hier ergibt sich ein weiteres zentrales Unterscheidungsmerkmal zu den großen Hyperscalern, denen naturgemäß gar nichts daran liegt, die Abhängigkeit der eigenen Klientel von der jeweiligen Plattform irgendwie zu reduzieren. Ganz im Gegenteil: Wer einmal auf AWS oder Azure gelandet ist, der soll dort gefälligst bleiben. Das Ziel erreichen die Anbieter implizit wie explizit. Explizit, weil ein auf AWS oder Azure optimierter Workload sich kaum ohne große Umbauten auf ein Konkurrenzprodukt umziehen lässt. Regelmäßig erfordert ein solches Szenario große Änderungen an der genutzten Toolchain, weil etwa APIs und die für den API-Zugriff genutzten Werkzeuge inkompatibel sind.

Implizit erreichen Anbieter wie AWS einen Vendor Lock-in, indem sie Dienste anbieten, die es bei der Konkurrenz schlicht nicht gibt. Wer zum Beispiel alle in AWS angebotenen As-a-Service-Angebote konsequent nutzt, kann extrem schlanke, gut zu wartende Setups bauen. Datenbanken, Netzwerkdateisysteme, ein globaler DNS-Dienst, der geobasiertes Routing beherrscht, sowie ein Speicherdienst, der auch regionale Unterschiede kennt – aus Sicht eines Anwendungsentwicklers oder Administrators sind das extrem praktische Features. Den größten Teil davon gibt es bei anderen Anbietern aber entweder gar nicht oder in kaum vergleichbarer Weise.

Wer also einmal diese Dienste nutzt und dann zu einem anderen Anbieter migrieren will, baut im Regelfall den größten Teil des eigenen Setups von Grund auf neu. Diesen finanziellen Aufwand scheuen viele Unternehmen aus nachvollziehbaren Gründen. Kunden von Sovereign-Cloud-Stack-Plattformen sollen eben diese Probleme nicht haben. SCS-Nutzer sollen auf einer anderen SCS-Plattform Dienste entweder hybrid in Anspruch nehmen, gern auch im Tandem mit einer privaten, SCS-basierten Cloud, oder ohne große Schwierigkeiten die Plattform wechseln können.

Damit das funktioniert, genügt es freilich nicht, schöne Websites zu gestalten und bunte Broschüren mit Inhalt zu füllen. Den SCS-Machern rund um Hauptinitiator Kurt Garloff ist das durchaus klar. Und so entsteht bei SCS nicht nur viel Theorie rund um die Nutzung von Cloud-Technologien, sondern auch handfeste Architektur.

Flexibles Herangehen

Am ehesten lässt der technische Teil des SCS-Projekts sich mit einem Baukastensystem vergleichen. Welche Teile davon ein Unternehmen nutzt, hängt vorrangig davon ab, welche Aufgaben es in technischer Sicht erledigen muss. Die SCS-Entwickler teilen das Deployment einer SCS-Instanz in unterschiedliche Aufgabengebiete und Abschnitte ein, für die sie im Anschluss Standardwerkzeuge definieren. Weil der Sovereign Cloud Stack sowohl klassische IaaS-Dienste als auch Container-Virtualisierung umfasst, stellen beide Aufgabengebiete einzelne Segmente im SCS-Universum dar. Die Technik setzt aber noch eine Ebene tiefer an, nämlich beim Lifecycle-Management für Bare-Metal-Systeme.

Hier bedient man sich einzelner Dienste des OpenStack-Universums wie Ironic und Bifrost. Eine Ebene höher siedelt sich der klassische OpenStack-Stack mit den drei Teilbereichen Compute, Storage und Netz an. Für Compute kommt OpenStack zum Einsatz, Storage erledigt der SCS auf Basis des Objektspeichers Ceph, für das Netz sorgen Open Flow, Open vSwitch sowie Open Virtual Network. Dabei fällt auf, dass im Architekturdiagramm (Abbildung 2) der Plattform alle diese Dienste als “Optional Standard” definiert sind. Als Kerndienstleistung eines SCS-Clusters verstehen die SCS-Macher nämlich Kubernetes as a Service, also Virtualisierung auf Basis von Containern. Zumindest in der Theorie lassen sich diese Komponenten also sogar ohne den Rest des SCS-Stacks ausrollen. Praktisch sieht der SCS-Standard aber auch die Option vor, die zu OpenStack gehörenden Komponenten zur Außenwelt hin zu exponieren und so klassisches IaaS auf Hardwareebene anzubieten.

Abbildung 2: Das Architekturdiagramm von Gaia-X macht deutlich: Das Baukastensystem lässt Unternehmen viel Auswahl hinsichtlich der Komponenten, die sie verwenden wollen. Quelle: SCS

Wieder eine Ebene höher finden sich die SCS-Plattformdienste wie OpenShift (Abbildung 3), Cloud Foundry oder TensorFlow, die in SCS-Clouds “as a Service” zur Verfügung stehen. An den Seiten – also mit Gültigkeit für alle Ebenen – finden sich schließlich Komponenten, die zur SCS-eigenen Infrastruktur gehören und deren Betrieb ermöglichen und erleichtern sollen. Das betrifft einerseits den kompletten IAM-Komplex mit Diensten wie Keycloak, OpenID-Konnektoren und Keystone für OpenStack und andererseits den Betriebskomplex, der sich vor allem um die Bereiche Monitoring, Alerting und Trending (MAT) sowie Continuous Integration und Continuous Development (CI/CD) kümmert. Auch hier begegnen dem Administrator viele alte Bekannte: Ansible für das Deployment von Software, Prometheus und Grafana für MAT, Telemetry zur Erhebung von genutzten Ressourcen in den Fällen, in denen SCS eine OpenStack-Cloud umfasst. Hinzu kommen der Open Policy Agent für Compliance und Zuul für CI/CD.

Abbildung 3: OpenShift ist ein möglicher Aufsatz für den Betrieb innerhalb des SCS, aber zweifelsohne einer der umfassenderen mit großer Anwendungsunterstützung. Quelle: Red Hat

Schnittstellen für andere

Das beschriebene Baukastensystem ist für potenzielle Kunden von SCS-Plattformen vor allem deshalb attraktiv, weil es etliche Dienste fertig vorbereitet bietet, die sich in der Software höherer Ebenen später gut wiederverwenden lassen. Das eingangs bereits erwähnte Gaia-X bietet dafür ein perfektes Beispiel: Benutzerauthentifizierung ist ein wichtiges Thema, wenn es etwa um das Verarbeiten von Gesundheitsdaten geht. Auch Compliance und Sicherheit spielen hier eine große Rolle. Bietet eine Zielplattform dafür bereits fertige Dienste an, wie SCS es tut, fällt es dem Kunden sehr leicht, sich daran anzuhängen und deren Fähigkeiten zu nutzen.

Wer eine bestehende Benutzerverwaltung an die Cloud eines externen Anbieters etwa mittels OpenID problemlos anklöppeln kann, erspart sich nicht nur den eigenen Betrieb solcher Dienste, sondern obendrein viel Arbeit. Und genau darauf läuft es beim Sovereign Cloud Stack in der Tat hinaus: Im Kern definiert das Projekt eine Sammlung von Werkzeugen und Protokollen als Standard, alle offen und am Markt gut etabliert. Wer Workloads auf eine Cloud auf Basis von SCS packen möchte, soll so wenige Schwierigkeiten wie möglich haben, genau das schnell und einfach zu tun, und zwar bei Bedarf sogar über die Grenzen einzelner Anbieter hinweg.

Das Deployment-Szenario für die einzelnen SCS-Komponenten setzt bedingungslos auf das Thema Automation. Frei nach dem Motto “was nicht automatisiert ist, existiert nicht” will der SCS – durchaus im Einklang mit der Konkurrenz – also dafür sorgen, dass bei der Installation und dem Betrieb der Plattform möglichst wenig manueller Aufwand für die Administratoren anfällt.

Open Operating

Kritiker und Spötter muss man in der IT nicht lange suchen, wenn es um das Thema Cloud Computing geht. Unvergessen bleiben etwa die “Clown-Computing”-Aufkleber, die vor ein paar Jahren auf jeder CCC-Konferenz verteilt wurden. Dasselbe gilt für den mittlerweile zur Internet-Folklore gehörenden Standardspruch, eine Cloud sei nur “der Computer von jemand anderem”, der quasi a priori ausschließt, dass in Clouds so etwas wie digitale Souveränität überhaupt möglich ist.

Da wundert es nicht, dass Beobachter im Hinblick auf den Sovereign Cloud Stack schnell eine Schwachstelle ausfindig gemacht haben. Die Erzählung dahinter funktioniert in etwa so: Wenn der Anbieter eine Plattform auf Basis offener Komponenten betreibt, sei das schön und gut. Der Kunde habe von dieser Information aber eigentlich gar nichts: Einerseits könne er sie ohne Zugriff auf die Hardware kaum sinnvoll verifizieren, und diesen Zugriff werde er in der Regel nicht bekommen. Andererseits schütze selbst quelloffene Software nicht davor, dass sich im Rechenzentrum eines Anbieters jemand Zugriff auf die Hardware der Umgebung verschafft und diese abschnorchelt. Auch bei SCS müsse man als Kunde also dem Anbieter vertrauen, wodurch das gesamte Prinzip ad absurdum geführt würde.

Ganz so leicht ist die Sache allerdings nicht. Wer einem Anbieter von IT-Infrastruktur nicht traut, der tut gut daran, seine Daten dort nicht zu lagern. Eine Geschäftsbeziehung zwischen Lieferant und Kunde ist ohne ein Fundament des Vertrauens schlechterdings undenkbar. Diese Stelle ist auch nicht die einzige, an der Vertrauen unbedingt notwendig ist. Die meisten Admins etwa, die eine spezifische Linux-Distribution auf ihren Systemen betreiben, vertrauen dadurch implizit deren Anbieter. Es wäre kommerziell kaum möglich, dass sich jeder Admin seine eigene Distribution bastelt, weil er Debian, Suse, Red Hat und Konsorten misstraut. Das Argument des notwendigen Vertrauens ist also durchaus valide, griff aber auch schon bei konventionellen Setups.

Dass Vertrauen die Grundlage für die Beziehung zwischen Unternehmen und Kunden ist, weiß man allerdings auch beim Sovereign Cloud Stack – und macht aus der Not kurzerhand eine Tugend: Parallel zu SCS arbeiten einige der Köpfe dahinter nämlich auch am Open-Operating-Projekt mit. Das strebt danach, die Prozesse, die für den Betrieb einer Cloud-Plattform notwendig sind, so effizient und so transparent wie möglich zu machen.

Blameless und transparent

Was bedeutet das jedoch in der Praxis? Ein Blick in das eigene Unternehmen hilft hier vielleicht schon, Klarheit zu bekommen. Wer in einer Firma arbeitet, in der Transparenz und Offenheit, Administration ohne Schuldzuweisungen und effiziente Prozesse etabliert sind, der fühlt sich an seinem Arbeitsplatz vermutlich sehr wohl. Wer hingegen in einem Unternehmen steckt, das nach außen zwar Agilität sowie Transparenz vorspiegelt, intern aber nach den Regeln von vor 20 Jahren spielt, weiß um die toxische Wirkung, die das entfalten kann.

In der Theorie ist das alles längst etliche Male durchgekaut: Dass Transparenz und eine Fehlerkultur ohne Schuldzuweisungen gute Ideen sind, beweist Toyota etwa seit Jahrzehnten. Dass Angst im Unternehmen Innovation verhindert, liegt auf der Hand. Dass Menschen, wenn sie im Falle eines Fehlers mit Schuldzuweisungen und schweren Konsequenzen rechnen müssen, am ehesten gar nichts tun, weiß man ebenfalls. Was zunächst nur wie eine ungute Situation für die Beschäftigten im Unternehmen wirkt, ist in der Realität aber noch viel schlimmer: Prozesse wie die beschriebenen hindern Unternehmen daran, besser zu werden.

In der Praxis haben Firmen also schon deshalb ein gesteigertes Interesse daran, den Grundregeln von Transparenz und Offenheit zu folgen, weil das die Prozesse und Produkte der Firma langfristig verbessert. Dass sich diese Maßnahmen auch noch perfekt eignen, um die Beziehung zwischen einem Unternehmen und seiner Kundschaft zu erleichtern, ist da quasi nur ein angenehmer Nebeneffekt.

Um die Nutzung dieser Verbesserungs- und Vertrauensprozesse geht es beim Open Operating-Projekt im Kern. Aktuell arbeitet man dort am Open Operations Manifesto. Im Stile des Agilen Manifests soll das OOM die Grundregeln definieren, nach denen Firmen vorgehen, die dem Ansatz folgen. Momentan umfasst das OOM fünf Regeln. Demnach bedeutet Open Operating, vorhandenes Wissen weiterzugeben, praktische Problemlösungen innerhalb der Community auszuarbeiten und zu teilen, eine gesunde Fehlerkultur zu etablieren, Probleme mit größtmöglicher Transparenz gegenüber den eigenen Kunden zu behandeln sowie interne Prozesse im Betrieb soweit wie möglich offenzulegen.

Konkret will man etwa interne Dokumentation über das Vorgehen bei technischen Prozessen offenlegen, vorgeschriebene Prozesse veröffentlichen und auch sonst so transparent wie möglich kommunizieren. Ihre Grenzen soll die Transparenz erst dort finden, wo das Veröffentlichen von Daten aus datenschutzrechtlichen oder anderen juristischen Gründen nicht erlaubt ist oder Geschäftsgeheimnisse gefährden würde. Die Unternehmen, die dem Open-Operating-Modell folgen, sind dazu angehalten, ihre Prozesse so zu gestalten, dass die Menge der Geheimnisse so gering bleibt wie möglich.

Wo es hapert

Ein föderierter Stack mit einfacher Migration auf Basis stabiler, offener Standards im Gespann mit einem revolutionären Operationsansatz sind offensichtlich Grundzutaten für eine potenzielle Erfolgsgeschichte. Dass erste Anbieter ihre SCS-Implementation bereits erfolgreich am Markt platziert haben, bestätigt den positiven Grundeindruck.

Zur Wahrheit gehört aber auch, dass das SCS-Projekt relativ jung ist und sich im Augenblick noch mit manch typischer Kinderkrankheit und mit einigen spezifischen Problemen herumschlägt. Ein Evergreen in der F/LOSS-Szene, der auch auf den Sovereign Cloud Stack zutrifft, ist das Thema unzureichende Dokumentation. Zwar berufen sich die Macher des Projekts zu Recht darauf, dass für die genutzten Komponenten des Stacks – OpenStack, Kubernetes und Ceph – viel Herstellerdokumentation in exzellenter Qualität online zur Verfügung steht. Allerdings ist der Sovereign Cloud Stack eben nicht nur eine Sammlung verschiedener Werkzeuge auf dem Papier.

Wer die Plattform so im Rechenzentrum ans Laufen bekommen will, wie es die SCS-Statuten vorsehen, muss beim Deployment verschiedene Faktoren beachten. Bis heute arbeiten an diesem Projekt vor allem Leute, die die genutzten Programme aus dem Effeff beherrschen und daher weniger auf Dokumentation angewiesen sind. Entsprechend begegnet einem an vielen Stellen vor allem Leere, wenn man einen Blick in den Ordner der SCS-Doku [2] wirft. Einzelne Bereiche der Dokumentation, etwa jener Teil, der IAM und Federation beschreibt, sind ausführlich ausgearbeitet. An anderen Stellen fehlt Dokumentation beinahe vollständig, und das nicht nur im Hinblick auf die konkrete Technik.

Wer beispielsweise eine OpenStack-Cloud in seine Racks zimmern möchte, tut gut daran, das Thema Netzwerk von Anfang an zu durchdringen. Leaf-Spine-Architekturen mit EVPN gelten hier im Augenblick als das Mittel der Wahl; ein sinnvolles Netzwerkkonzept für eine OpenStack-Umgebung ist längst kein Hexenwerk mehr. Ganz im Gegenteil: Gerade das Thema Netz ist auf Basis der aktuell zur Verfügung stehenden Technik praktisch abschließend diskutiert. Der Sovereign Cloud Stack könnte hier sogar doppelt punkten, indem er empfiehlt, auf Open-Networking-Hardware wie die Geräte mit ONIE-Bootloader zu setzen, auf denen Linux läuft, zum Beispiel Cumulus Linux. Das würde Herstellerunabhängigkeit und Zukunftssicherheit garantieren. Wühlt man sich jedoch durch das Archiv der SCS-Dokumentation, findet man zum Thema Netzwerk höchstens spärliche Ansätze einer künftigen Dokumentation.

Zum potenziellen Problem kann für SCS außerdem der Umstand werden, dass die genutzten Open-Source-Komponenten in einzelnen Aspekten derzeit nicht mehr konkurrenzfähig zu AWS & Co. sind. Das Beispiel Database as a Service macht das gut deutlich: AWS hat das Thema schon vor Jahren abgefrühstückt. Wer hier eine MariaDB oder PostgreSQL braucht, klickt sich einfach die entsprechenden AWS-Ressourcen zusammen (Abbildung 4). Clustering, Backups und zentrale Verwaltung – DBaaS von AWS bietet das alles.

Abbildung 4: Die Datenbankdienste in AWS erleichtern Administratoren das Leben, sorgen aber auch für einen gehörigen Lock-in-Effekt. Quelle: AWS

Der OpenStack-Stack, der in den meisten Fällen von SCS-Deployments das architektonische Rückgrat einer Plattform bilden dürfte, hat schlicht keine funktionierende DBaaS-Komponente auf der Höhe der Zeit mehr. Trove existierte bis vor ein paar Jahren als aktiv entwickeltes Werkzeug, gilt mittlerweile aber als weitgehend verwaist. Red Hat hat Trove in seiner OpenStack-Plattform bereits vor Jahren als veraltet markiert und liefert für die Komponente auch keinen Support mehr.

Ohne Dienste wie DBaaS wird jedoch der Reiz, der von privaten und öffentlichen SCS-Clouds ausgeht, den Annehmlichkeiten von AWS kaum etwas entgegenzusetzen haben. Digitale Souveränität hin oder her: Wenn SCS in der Breite Fuß fassen will, muss die Plattform auch für Anwender attraktiv sein, denen es nicht primär um die Kontrolle der eigenen Daten geht, sondern die SCS-basierte Clouds ganz einfach als Plattformen innerhalb einer großen Konkurrenz sehen und kommerzielle Use Cases abwägen.

Aus Sicht der SCS-Macher ist das freilich alles andere als angenehm. Es scheint eher unwahrscheinlich, dass SCS selbst die Ressourcen aufbringen kann, Dienste wie Trove (Abbildung 5) zu polieren und andere Dienste wie Route 53 selbst zu initiieren. Zudem müsste es hier gar nicht zwingend so sein, dass eine SCS-Lösung unbedingt auf OpenStack basiert. Geht man davon aus, dass Kubernetes as a Service – wie in der SCS-Beschreibung festgelegt – eigentlich den Kern des Produktangebots darstellt, ließe sich DBaaS auch in Container-Form auf Kubernetes automatisieren.

Abbildung 5: OpenStack Trove existiert als eine mögliche DBaaS-Lösung für den SCS, bräuchte aber noch viel Liebe und Zuwendung. Wie auch immer die Entwickler das Problem fehlender Features lösen wollen – sie werden es lösen müssen. Quelle: OpenStack

Auch hier strotzt der Markt zumindest im Augenblick aber nicht vor fertigen, herstellerunabhängigen Lösungen, die sich einfach in SCS integrieren ließen. Ohne wird es andererseits aber kaum gehen. Es bleibt also spannend zu beobachten, für welchen Ansatz man sich bei SCS entscheidet.

Fazit

Wenn man so will, ist Open Operating – hinter dem nicht zufällig zum Teil dieselben Leute stehen wie hinter dem Sovereign Cloud Stack – eine sinnvolle Ergänzung zu SCS auf der Prozessseite. Wer die Ansätze miteinander kombiniert, dürfte eine viel höhere Transparenz erreichen, als es heute häufig der Fall ist. Gut möglich aber, dass viele Firmen das am Anfang ein bisschen überfordert. Es wird gerade vor diesem Hintergrund interessant sein, den weiteren Werdegang von SCS und Open Operating zu verfolgen. Immerhin: Erste Erfolge konnte man beim Sovereign Cloud Stack bereits verbuchen. PlusServer aus Köln ist seit über einem Jahr mit einer auf SCS basierten Cloud am Start, andere Anbieter evaluieren die Software im Augenblick immerhin. Aus SCS-Sicht bleibt es mithin spannend. (jcb)