© Maren Winter / 123RF.com

Auf den Rausch folgt der Kater, auf den beispiellosen Hype um OpenStack vor zehn Jahren folgt nun die Ernüchterung. Die aber wirkt durchaus positiv: OpenStack entwickelt sich technisch kontinuierlich weiter und kommt heute vor allem dort zum Einsatz, wo es wirklich sinnvoll ist.

Ganz, so schien es, konnten die Verantwortlichen der OpenStack Foundation in der Mitte des letzten Jahrzehnts den Erfolg ihres Produkts selbst kaum fassen. Bis heute zirkulieren in der Community Geschichten von OpenStack-Konferenzen, bei denen zum Beispiel das vegetarische Essen ausging, weil niemand mit so vielen Teilnehmenden gerechnet hatte.

Lange Zeit umgab OpenStack-Messen und allen voran den OpenStack-Summit sogar etwas wie eine mystische Aura: 8000 Teilnehmer und mehr reisten der privaten Cloud-Computing-Umgebung regelmäßig hinterher, um sich auf den neuesten Stand der Technik zu bringen. Selbst regionale OpenStack-Events wie die OpenStack CEE Days produzierten regelmäßig Teilnehmerzahlen, die es mit jenen alteingesessener Open-Source-Veranstaltungen aufnehmen konnten. Kein Zweifel: 2012 fing ein Hype rund um OpenStack an, wie die Industrie ihn bis dahin gerade im Umfeld von Open-Source-Software noch nie erlebt hatte.

Die Zeit war günstig: AWS hatte das Thema Cloud gerade fest im Bewusstsein der Anwender verankert, und jeder wollte am liebsten selbst zum Cloud-Provider werden. Anstelle einer speckigen Vmware-Installation im eigenen Rechenzentrum sollten Automation, völlige Selbstbedienung durch die Nutzer und Skalierbarkeit das Motto der Zukunft sein. Sogar Vmware selbst sprang auf den OpenStack-Zug auf und ermöglichte es, ESXi als Hypervisor für OpenStack zu verwenden. Als die italienische Firma Cloudbase dann auch noch Windows Hyper-V fit für OpenStack machte – manche munkelten, Cloudbase sei in Wirklichkeit eine Microsoft-Ausbuchtung, weil das Politbüro in Redmond sich offiziell nicht zu OpenStack bekennen wollte – war man sich einig: OpenStack gehört die Zukunft!

Der große Kater

Einer großen Sause folgt unweigerlich irgendwann der große Kater, und OpenStack machte da keine Ausnahme. Manche Teilnehmer verließen die OpenStack-Party gar schon wieder, während sie noch in vollem Gange war. Wie Pilze schossen die großen OpenStack-Projekte aus dem Boden, verliefen nach Monaten und Jahren im Sande und ließen außer frustrierten Menschen wenig zurück. Andere orientierten sich bald in Richtung Kubernetes, das im Begriff war, der nächste große Hype zu werden. Danach wurde es medial still um OpenStack.

Auch im Linux-Magazin, das regelmäßig über OpenStack und die angrenzenden Projekte berichtete, tauchte das Thema seither nur noch eher selten auf. Manche glauben bereits, OpenStack sei von der Bildfläche verschwunden, doch sind auch diese Nachrichten frei nach Mark Twain zumindest stark übertrieben. OpenStack ist bis heute ein aktives Projekt, wenn auch mit deutlich kleinerer Community. Doch entwickelt es sich nach wie vor weiter. Grund genug, einen neuen Blick auf OpenStack zu werfen und zu fragen: Was hat sich getan – technisch, organisatorisch und administrativ?

OpenInfra

Die auffälligste Neuerung, die obendrein die stärkste Schlagkraft entfaltet hat, ist die Refokussierung der OpenStack Foundation. Ursprünglich hatte die Foundation sich gegründet, um OpenStack eine nichtkommerzielle Heimat zu geben. Das ist gerade in den USA aus verschiedenen Gründen sinnvoll, denn ein rein virtuelles Projekt könnte etwa keine Rechte an Marken- oder Warenzeichen halten. Obendrein muss schließlich auch irgendwer die OpenStack-Sause bezahlen, und eine Kernaufgabe der Foundation besteht darin, Sponsorengelder aufzutreiben. Das geschieht auf Basis von Firmen- und Einzelmitgliedschaften, und die Gelder dienen unter anderem dazu, die (nicht ganz günstigen) OpenStack-Summits (Abbildung 1) zu finanzieren.

Abbildung 1: Immer noch eine Art Klassentreffen, wenn auch ein deutlich kleineres: der OpenStack Summit 2022 in Berlin, erstmals nach Corona wieder live. Quelle: OpenInfra Foundation

Auf dem Höhepunkt des OpenStack-Hype-Zyklus gelang es der OpenStack-Foundation seinerzeit, erheblichen Einfluss bei großen Herstellern wie Vmware, Intel, Red Hat & Co. zu gewinnen. Mit der abnehmenden Relevanz von OpenStack drohte dieser Einfluss wieder zu schrumpfen, sehr zum Missfallen der Leute bei der Foundation. Flugs beschloss man vor ein paar Jahren eine Umorientierung: Aus der OpenStack Foundation wurde die OpenInfra Foundation, aus dem OpenStack Summit der OpenInfra Summit. Seither ist OpenStack noch immer ein relevantes Thema, aber eben nicht mehr das einzige, mit dem die Foundation sich beschäftigt.

In den vergangenen Monaten beispielsweise hat sie sukzessive viele Werkzeuge und Tools aus der OpenStack-Entwicklung überarbeitet, systematisch unter eine Form von Projektmanagement gestellt und veröffentlicht. Die dabei in Angriff genommenen Themen sind so etwas wie Evergreens des Themas Infrastruktur und Open Source: Zuul etwa, die Entwicklungssuite, die die Foundation für die Entwicklung von OpenStack nutzt, kommt mittlerweile häufig auch außerhalb des Projekts zum Einsatz. Die Foundation steht wie bei OpenStack selbst dafür ein, dass das Projekt nicht irgendwann sang- und klanglos untergeht.

Darüber hinaus hat die OpenInfra Foundation ihre Fühler auch in etliche andere Richtungen ausgestreckt. Ähnlich wie die Linux Foundation bietet sie dabei ein Dach für Open-Source-Projekte, wobei der Fokus freilich auf Software liegt, die irgendwie im Infrastrukturbereich zum Einsatz kommt. Auch der Log-Verwalter Loki (Abbildung 2), eine leichtfüßige Alternative zum klassischen ELK-Stack, ist inzwischen unter das Dach der OpenInfra Foundation geschlüpft. Kritiker begrüßen das ausdrücklich, wurde doch die scheinbare Allmacht der Linux-Foundation für viele allmählich zum Problem. Ob es allerdings der OpenInfra Foundation gelingt, hier zum langfristigen und mächtigen Gegengewicht zu werden, muss sich erst noch zeigen.

Abbildung 2: Loki ist eine leichtfüßige Alternative zum ELK-Stack und zählt mittlerweile zu den Projekten der OpenInfra Foundation. Quelle: Loki

Technischer Fortschritt

Die Binsenweisheit “hinterher weiß man immer mehr” trifft auf OpenStack voll zu. Technisch entwickelt das Projekt sich nach wie vor weiter, und viele Kinderkrankheiten der ersten Jahre verschwinden erst dieser Tage aus der Umgebung. Hier spielen mehrere Faktoren eine Rolle. Einer, der dem Projekt erkennbar guttut, ist das nachlassende Interesse der ganz großen Hersteller.

Red Hat und Canonical haben sich OpenStack bis heute offiziell verschrieben. Suse jedoch, ein OpenStack-Pionier, hat die OpenStack-Entwicklung weitgehend aufgegeben und auch bei der eigenen OpenStack-Distribution Suse Cloud den Stecker gezogen. Entsprechend kommt aus Nürnberg momentan in Sachen OpenStack-Quelltext nur noch wenig. Dabei fällt allerdings auf, dass die Vielzahl der Firmen, die gerade in der Anfangsphase des Projekts auf OpenStack Einfluss nehmen wollten, vermutlich eher Fluch als Segen war. Dafür liefert Cinder ein gutes Beispiel, jene Komponente, die Speicher für OpenStack verwaltet. Wenn sich auf der Cinder-Mailing-Liste die Branchengrößen über Architekturentscheidungen streiten, bleibt als Ausweg stets nur der kleinste gemeinsame Nenner. Seit weniger Stimmen mitmischen, wagen die Entwickler sich gelegentlich auch an größere Änderungen und Funktionen heran, die mit alten Kompatibilitätsvorgaben brechen.

Obendrein hat die OpenInfra Foundation mittlerweile einen stabilen Modus Operandi gefunden, um die einzelnen OpenStack-Komponenten und ihre Entwicklung sinnvoll zu steuern. Für jede Komponente gibt es bis heute eine technisch verantwortliche, von der Community aus ihrer Mitte gewählte Person. Sie verantwortet die Entwicklung inhaltlich und wird für jeden OpenStack-Entwicklungszyklus neu bestimmt.

Wenige Riesenumbauten

Sieht man sich ein OpenStack-Changelog der Gegenwart an, fällt schnell auf, dass die einzelnen Komponenten sich mittlerweile bedächtiger entwickeln. Nicht zuletzt den hohen Erwartungen der Industrie war es in der Pionierzeit der Umgebung mehr oder weniger geschuldet, dass jede neue OpenStack-Version ein Feature-Feuerwerk mit bahnbrechender Innovation abfeuern musste. Derzeit entwickelt OpenStack sich deutlich langsamer. Zwar umfasst eine OpenStack-Version noch immer Tausende Commits und ein ewig langes Changelog. Die Release-Highlights jedoch, die die wichtigsten und tiefgreifendsten Änderungen einer OpenStack-Version beschreiben, passen heute auf wenige Bildschirmseiten. Das liegt nicht zuletzt daran, dass nicht mehr jede OpenStack-Version mit neuen Komponenten daherkommt, von denen zuvor noch keiner gehört hat und die zwei Releases später wieder in der Versenkung verschwinden.

Ende März erschien das letzte große OpenStack-Release “Yoga”, Nummer 25. Ein Blick in dessen Release-Highlights unterstreicht, dass OpenStack jetzt behutsamer zu Werke geht als noch vor ein paar Jahren. OpenStack Blazar etwa ist eine relativ junge OpenStack-Komponente, die Benutzern die Möglichkeit einräumt, Ressourcen für sich zu reservieren, ohne sie zu nutzen. Das schafft Sicherheit für Anwendungen, die zu einem Zeitpunkt X die Garantie besitzen müssen, Ressourcen in einem bestimmten Umfang zur Verfügung zu haben. Blazar gewinnt in OpenStack “Yoga” die Fähigkeit, mehr Details über einzelne virtuelle Instanzen zu hinterlegen, sodass die Auswahl von Hosts durch den Nova-Scheduler von OpenStack zielgerichteter erfolgen kann.

Die großen Sechs

Naturgemäß finden sich bis heute die meisten Änderungen in den sechs Kernkomponenten der Plattform, die zu einer OpenStack-Instanz gehören. Der Speicherverwalter Cinder unterstützt seit “Yoga” zum Beispiel die Möglichkeit, ein virtuelles Volume durch den Inhalt eines Festplattenabbilds zu überschreiben. Bis dato ging das nur zum Zeitpunkt der VM-Erstellung, nun lassen sich auch existierende virtuelle Maschinen neu anlegen, ohne die ganze VM oder den Datenträger zu löschen und neu anzulegen (Reimaging).

Obendrein gewinnt Cinder in “Yoga” Unterstützung für neue Hardware-Backends. Es kann seinen Speicher künftig in Form von LightOS über NVMe per TCP ebenso ansprechen wie Netstor-Geräte von Toyou per Fibre Channel. Für NEC-Storages der Baureihe V gibt es zudem künftig Unterstützung sowohl per Fibre Channel als auch per iSCSI.

Der Image-Dienst Glance gehört seit jeher zu den Komponenten mit eher entspannter Entwicklung, und konsequent bietet er in “Yoga” auch nur wenig Neues. Es lassen sich nun Quota-Infos über die hinterlegten Abbilder anzeigen, einige neue API-Operationen etwa für das Bearbeiten von Metadaten-Tags kamen hinzu, und es gibt mehr Details über virtuelle Abbilder, die auf RBD-Geräten in Ceph liegen.

Horizon, Nova, Keystone

Mehr ereignet sich naturgemäß beim grafischen Front-End Horizon. Es wurde von den Leuten hinter OpenStack in den vergangenen zwei Jahren mächtig überarbeitet und unterstützt nun die Übersetzung in andere Sprachen sowie das Theming deutlich besser. Darauf hatten Canonical und Red Hat großen Wert gelegt: Schließlich soll ein Canonical-Ubuntu in Orange (Abbildung 3) erstrahlen und ein Red-Hat-OpenStack in Rot (Abbildung 4). Funktional gewinnt das Dashboard in Horizon die Möglichkeit, QoS-Regeln anzulegen und zu löschen.

Abbildung 3: Die Theming-Möglichkeiten des OpenStack-Dashboards haben die Entwickler sukzessive verbessert. So erstrahlt Horizon auf Ubuntu heute im typischen Canonical-Orange … Quelle: Ubuntu

Abbildung 4: … und unter Red Hat OpenStack Platform (RHOP) stattdessen in der typischen Red-Hat-Optik, wie sie sich auch bei anderen Produkten findet. Quelle: Red Hat

Beim Virtualisierer Nova tut sich ebenfalls einiges. Die wichtigste Neuerung in “Yoga” ist die Möglichkeit, sogenannte SmartNICs über Netzwerk-Backends unmittelbar in eine VM durchzureichen. Traditionell funktioniert Software Defined Networking im OpenStack-Kontext eher so, dass auf dem Host ein virtueller Switch angelegt wird, der sich um das Zustellen von Paketen kümmert.

Der Ansatz hat allerdings den großen Nachteil, dass er die Host-CPU für das Verarbeiten von Paketen heftig in Beschlag nimmt. Praktisch alle großen Netzwerkhersteller haben deshalb mittlerweile NICs im Angebot, deren Chips beispielsweise Open vSwitch selbst verarbeiten können. Dann wandert die Kontrolle der Zustellung von Netzwerkpaketen vom Host auf die NICs, wo sie effizienter erfolgt und dadurch den Host schont.

Auch bisher war es möglich, in Nova über die Wahl des passenden Treibers für den jeweiligen Emulator die jeweiligen NICs zu nutzen. Nun allerdings bietet Nova die Option direkt über die Einstellung des genutzten Backends für die virtuelle Netzwerkkarte. Das Feature ist also jetzt standardisiert und lässt sich theoretisch von jedem Netzwerk-Backend-Treiber in Nova nutzen.

Für wie arriviert OpenStack sich mittlerweile hält, wird erkennbar, wenn man in den OpenStack-Release-Highlights nach Keystone sucht. Die Komponente ist für die Benutzer- und Projektverwaltung zuständig und mithin eine absolut neuralgische Stelle. In “Yoga” hat sich jedoch nichts getan, das die Entwickler als so relevant betrachtet hätten, dass es einen besonderen Changelog-Eintrag rechtfertigt. Als “feature complete” würden die Entwickler Keystone wohl selbst eher nicht betiteln, aber vor allzu großen Umwälzungen bei Keystone dürften Admins in absehbarer Zeit trotzdem geschützt sein.

Kubernetes am Horizont

Kubernetes auf OpenStack (eigentlich Kubernetes auf OpenStack auf Kubernetes) zählt heute zu den durchaus gebräuchlichen Deployment-Szenarien für die freie Cloud-Umgebung. Entsprechend wichtig ist den Entwicklern eine möglichst optimale OpenStack-Integration in Kubernetes. In jüngerer Vergangenheit kamen zu diesem Zweck einige Komponenten zu OpenStack hinzu, darunter Kuryr.

Wie OpenStack bringt auch Kubernetes bekanntermaßen eine eigene SDN-Implementierung mit. Früher war es durchaus üblich, das virtualisierte Netz aus Kubernetes auf dem virtuellen Netz aus OpenStack zu betreiben – sehr zum Leidwesen vieler Admins. Denn wenn in diesem Layer-Cake einmal irgendetwas schiefging, war es schwierig bis unmöglich, auch nur den ungefähren Entstehungsort des Problems zu finden.

Kuryr schafft Abhilfe und legt virtuelle Netzwerk-Ports in OpenStack so an, dass Kubernetes sie nativ verwenden und auf das eigene SDN verzichten kann. Das ermöglicht implizit mehrere Features, die sonst brachlägen, etwa das bereits beschriebene Outsourcing von Aufgaben an NICs mit Offloading-Support oder das nahtlose Integrieren von As-a-Service-Diensten aus OpenStack in Kubernetes-Umgebungen.

Octavia, also Load Balancer as a Service, spielt heute eine prominente Rolle im OpenStack-Universum, lässt sich allerdings erst durch Kuryr sinnvoll für Kubernetes nutzen. Sinnvoll meint in diesem Fall, ohne etliche Balancer-Instanzen übereinander zu stapeln.

Quer durch den Gemüsegarten

Darüber hinaus verteilen sich mittlerweile viele kleine Änderungen bei den diversen OpenStack-Diensten quer durch den Gemüsegarten. Extrem aufgewertet haben die Entwickler in den vergangenen Monaten beispielsweise Designate. DNS as a Service ist für viele Endanwender wichtig, weil eine in OpenStack gehostete Website ja auch unter einem Markennamen erreichbar sein soll und nicht nur per IP-Adresse.

Lange Zeit beherrschte Designate allerdings nur Grundfunktionen und funktionierte je nach gewähltem Netzwerk-Backend obendrein schlecht. Heute präsentiert Designate sich gut in Form, spricht mit allen verfügbaren SDN-Backends und bietet ein Füllhorn an Funktionen. Für “Yoga” haben die Entwickler sich insbesondere auf die Jagd nach Bugs und Fehlern begeben, ihre internen Tests ausgebaut und so diverse Bugs beseitigt. IPv4 sowie IPv6, verteilte Nameserver-Einträge und Sonderformen von DNS-Einträgen wie TXT-Zeilen beherrscht Designate bereits seit einiger Zeit. In Summe zeigt Designate vielleicht wie keine andere OpenStack-Komponente, dass heute der Fokus der Plattform auf Stabilität und Zuverlässigkeit liegt und nicht nur beim “Next Big Thing”.

Paradigmenwechsel

Fast schon eine Art Paradigmenwechsel haben die OpenStack-Entwickler in jüngerer Vergangenheit beim Thema OpenStack-Deployment hingelegt. Lange Zeit betrachtete man das Thema quasi als extern: Werkzeuge etwa auf Basis von Ansible, Puppet oder Chef sollten das OpenStack-Deployment übernehmen. Diese Argumentationslinie bröckelte eigentlich recht früh und spätestens durch OpenStack Ironic.

Bare Metal as a Service ist die Beschreibung jenes Diensts, der in OpenStack ein Lifecycle Management für Hardware fast jeder Provenienz etabliert. Der Clou: Ironic erlaubt es, OpenStack-Hosts wie OpenStack-VMs zu verwalten. TripleO heißt das Konstrukt dann – OpenStack on OpenStack. Ein mit einem Basis-OS betankter Server allein ist für OpenStack noch einigermaßen sinnlos, es gehören auch die zu OpenStack zählenden Komponenten dazu. Die kommen mittlerweile zwar samt und sonders in Form von Containern daher, ausrollen und konfigurieren muss man sie aber trotzdem.

Auch deshalb gehört heute OpenStack-Ansible als eigene Komponente zu OpenStack. Es übernimmt im TripleO-Kontext Aufgaben, lässt sich aber ebenso gut in Standalone-Manier nutzen, um Hosts fit für den Einsatz mit OpenStack zu machen. Dass die strikte Trennung zwischen Komponente und Deployment aus der Anfangszeit so nicht mehr praktiziert wird, ist gut und wichtig. Es wertet das OpenStack-Deployment in Summe auf.

Was nicht besser wird

Bei allem Lob für die richtigen Entscheidungen der Community in der jüngeren und jüngsten Vergangenheit gibt es bei OpenStack noch immer Dinge, die nicht zuverlässig oder gar nicht funktionieren. Manche davon lassen sich verschmerzen, andere fallen jedoch schwer ins Gewicht.

Zum guten Ton bei Cloud-Umgebungen gehört es heute, der eigenen Nutzerschaft As-a-Service-Dienste anzubieten. Da längst nicht mehr jeder, der einen Webshop betreibt, IT-Kraft mit Kommandozeilenhintergrund ist, müssen Dienste wie Datenbanken auch für weniger versierte Nutzer verfügbar sein. Amazon macht das etwa mit seinem Database-as-a-Service-Angebot vor, und auch bei OpenStack existieren verschiedene As-a-Service-Komponenten. Bekannt ist mittlerweile zum Beispiel NFS-as-a-Service alias Manila.

Allerdings scheint sich bei OpenStack in Sachen Database-as-a-Service partout keine Innovation einzustellen. Eine Komponente dafür hatte OpenStack sogar schon einmal an Bord, in Form vom OpenStack Trove. Dessen Entwicklung allerdings liegt seit über zwei Jahren brach, wohl auch, weil der letzte aktive Maintainer inzwischen von einem Konkurrenten geschluckt wurde, der das OpenStack-Thema kurz danach aus dem neuen, gemeinsamen Portfolio strich. OpenStack-Nutzer schauen in die Röhre und bauen ihre Datenbanken bis heute mühsam zu Fuß – falls sie nicht gleich zu aberwitzigen Eigenkreationen ansetzen, wie es ebenfalls vielerorts zu begutachten oder zu beklagen sind.

Und an einer weiteren Stelle glänzt OpenStack seit vielen Jahren mit der Abwesenheit fast jeglicher nötiger Funktionalität: beim Thema Billing. Es gibt zwar eine Komponente, die Nutzdaten mitschreibt und in eine Datenbank namens Gnocchi speichert, nämlich Ceilometer. Das versteht sich allerdings als reiner Metrikdatenmesser und bietet keinerlei Möglichkeit, aus den gewonnen Daten Rechnungen zu erstellen.

Zugegeben, OpenStack hat es an dieser Stelle nicht leicht. Die Komplexität des Themas Rechnungswesen sorgt quasi implizit dafür, dass es nicht genügt, nur Daten zu sammeln und eine Rechnung als PDF zu generieren. Stattdessen gilt es, auf diverse Aspekte zu achten. So muss aus Kundensicht etwa penibel nachvollziehbar sein, was überhaupt verrechnet wird. Behauptet der Anbieter auf seiner Rechnung, von 05:35 bis 06:35 morgens sei eine VM gelaufen, muss er das im Falle einer Nachfrage plausibel belegen können. Obendrein gelten diverse formale Anforderungen an Rechnungen, etwa die Pflicht zur fortlaufenden Nummerierung, die korrekte Ausweisung von Umsatzsteuer je nach Empfängerland und so weiter. Dass sich OpenStack-Entwickler mit solchen Details eher ungern abgeben, liegt auf der Hand. Daher lautete die Devise bisher stets, OpenStack solle das Billing nicht selbst in die Hand nehmen, sondern dazu einen externen Dienst verwenden.

Damit das aber effizient gelingt, bräuchte OpenStack zumindest eine Art generische Schnittstelle für das Auslesen etwaiger Daten in aufbereiteter Form. Viele Firmen setzen ohnehin auf proprietäre Buchhaltungswerkzeuge, an die OpenStack dann freilich anzubinden wäre. Praktisch hapert es allerdings schon an der Stelle, an der OpenStack Daten für andere Dienste bereitstellen soll. Hier gab es zwar etliche Ansätze, etwa CloudKitty, das selbst auf die Daten aus Ceilometer zugreift. Durchschlagenden Erfolg hatte allerdings keine der Lösungen, und bis heute existieren nur proprietäre Produkte, die auf spezifische Clouds auf OpenStack-Basis hingeschustert sind. Eine Handvoll kommerzielle Anbieter hat OpenStack in ihren Verrechnungswerkzeugen bedacht. Doch Unternehmen, die nicht zufällig eines dieser Werkzeuge einsetzen, gucken weiter in die Röhre.

Bis heute gilt: Wer OpenStack nicht nur technisch, sondern auch kommerziell sinnvoll betreiben will, der muss sich die komplette Abrechnungsprozedur mehr oder minder selbst bauen. Hier wäre es längst an der Zeit, dass die Entwickler mit einer generischen Schnittstelle um die Ecke kommen, an die Abrechnungsdienstleister dann andocken können.

Fazit

Viel erreicht, viel zu tun – so muss das Fazit im Hinblick auf OpenStack nach etwas mehr als 12 Jahren Projektgeschichte lauten. Was einst als Kooperation der NASA mit Rackspace begann, hat sich zur umfassenden Plattform für private Clouds mit hohem Qualitätsanspruch gemausert und schafft es inzwischen auch, diesen Anspruch selbst zu erfüllen.

Allerdings hat sich nicht nur OpenStack verändert, sondern auch die Sicht der Industrie auf das Projekt. Längst nicht mehr jeder kleine Dienstleister versucht heute, im OpenStack-Zirkus mitzumachen, weil die Lösung mittlerweile als Profiwerkzeug für große Umgebungen gilt. Sorgen bereitet manchen, dass dadurch auch die Zahl der Anbieter mit OpenStack-Produkten im Portfolio deutlich zurückgegangen ist. Außer Canonical und Red Hat bietet heute keiner der Großen mehr eine ernst zu nehmende OpenStack-Distribution als Hersteller an.

Abbildung 5: Der Sovereign Cloud Stack gibt eine Referenzarchitektur für Clouds vor, in deren Kern OpenStack steckt. Quelle: Sovereign Cloud Stack

Ausgerechnet in Deutschland braut sich dagegen aber Widerstand zusammen. Der in der Open-Source- und OpenStack-Szene bestens vernetzte Kurt Garloff tüftelt seit geraumer Zeit an seinem Sovereign Cloud Stack (SCS [1]), der im Kern auf OpenStack fußt (Abbildung 5) und Unternehmen Datensouveränität durch den Betrieb einer eigenen Cloud ermöglichen soll. Erste Mitstreiter hat Garloff bereits gefunden, und die technische Entwicklung des SCS macht durchaus Lust auf mehr. Konkurrenz und Vielfalt schaden bekanntlich nicht, und so bleibt zu hoffen, dass SCS sich als Alternative zu den großen Zwei etablieren und OpenStack zu neuem Aufwind verhelfen kann. (jcb/jlu)