© Yuryy Bezrukov, 123RF

Auf dem Höhepunkt des Hype versprechen die Anbieter von Open-Stack-Produkten potenziellen Kunden eine eierlegende Wollmilchsau – doch geliefert wird meist nur eine lahme Ente.

Seit Jahren hat es nun schon den Anschein, als seien die Begriffe “Cloud Computing” und “Open Stack” so gut wie Synonyme. Während es früher durchaus noch andere Cloudprodukte wie Eucalyptus oder Cloudstack regelmäßig in die Berichterstattung schafften, scheint Open Stack inzwischen die öffentliche Aufmerksamkeit komplett für sich allein gepachtet zu haben. Kein Zweifel: Open Stack befindet sich aktuell auf dem Gipfel eines Hype.

Buchstäblich jede Firma, die etwas auf sich hält, hat Produkte mit Open-Stack-Bezug ins Programm genommen. Da ist es ganz gleich, ob der Storagehersteller mit der guten Anbindung seiner Geräte an die Speicherkomponente Cinder wirbt oder ob VMware erklärt, dass sich sein Vcenter nun auch problemlos als Hypervisor für Open Stack einsetzen lässt – der Tenor ist in allen Fällen der gleiche. Er lautet: Wir sind auch mit dabei! Open Stack ist toll! Für die großen Hersteller von Linux-Distributionen – allen voran Suse, Canonical und Red Hat – ist Open Stack mittlerweile von größter Bedeutung auch für den eigenen Erfolg.

Alle drei Unternehmen haben Produkte im Portfolio, die Admins eine fertige Open-Stack-Wolke in kurzer Zeit und ohne viel Aufwand versprechen. Liest man die Werbeanzeigen für Suse Cloud oder Red Hats Open-Stack-Enterprise-Produkt, entsteht immer der gleiche Eindruck: Nach der Installation legt sich der Admin ruhig in die Sonne und lässt Open Stack die Arbeit erledigen, die er sonst selbst tun müsste. Denn auf diese Art des Betriebs will Open Stack ausgelegt sein.

Der Praxis-Check

Dass mit der Werbung der Anbieter – zu denen mittlerweile auch HP und diverse andere Branchengrößen gehören (Abbildung 1) – irgendetwas nicht stimmen kann, merken Administratoren spätestens dann, wenn sie sich tatsächlich an ein Open-Stack-Setup wagen und damit beginnen, ihre eigenen Erfahrungen zu sammeln.

Abbildung 1: Praktisch kein namhaftes Unternehmen der IT-Szene ist aktuell nicht in Open Stack vertreten.

Bald stellt sich heraus, dass ein Open-Stack-Admin nicht der Raumfahrer ist, der aus seiner Kommandozentrale heraus die Geschicke des Setups leitet, sondern viel mehr der Feuerwehrmann, der die losen Enden seiner Wolke irgendwie zusammenzuhalten versucht. Anders als Open Stack selbst und die diversen Produktanbieter es vorgaukeln, ist das Produkt nämlich weder fertig noch aus der Dose für den Einsatz in jedem beliebigen Unternehmen geeignet. Die Gründe dafür sind vielfältig – einige Faktoren stechen jedoch heraus.

Automatisierung ist ein Muss

Einer der maßgeblichen Unterschiede zwischen konventionellen Setups und Cloudumgebungen ist der Umfang der Automatisierung. Bei klassischen Setups ist es noch die Aufgabe des Admin, auf Zuruf neue VMs anzulegen und sie so einzurichten, dass der Kunde sie nutzen kann. Dabei verbindet der Installateur eine größere Anzahl von Arbeitsschritten miteinander: Zuerst ist Storage zu kommissionieren und an eine virtuelle Maschine anzuhängen, sodass in dieser anschließend die Installation des Betriebssystems möglich ist.

Danach spielt auch das Netzwerk eine große Rolle: VMs brauchen selbstverständlich eine Anbindung an das Internet. Die ist in konventionellen Setups meist dadurch herzustellen, dass die VM ein virtuelles Netzwerkinterface bekommt, das an ein virtuelles LAN-Interface geklemmt ist.

In einer Cloud sollen all diese Arbeitsschritte automatisch ablaufen: Der Anbieter stellt die Infrastruktur zur Verfügung, also einen großen Haufen identischer Hardware. Die Cloudplattform übernimmt ihre Verwaltung: Das Netzwerk existiert bloß noch virtuell in Form eines Software-defined Networking. Die gesamte Kontrolle der Paketflüsse erfolgt also nicht mehr in der Switch-Hardware, sondern durch Software innerhalb der Installation. Ähnlich ist es in Sachen Storage: Statt eines zentralen Speichers in typischer SAN-Manier sorgt Software-defined Storage dafür, dass jedem Kunden jederzeit der Speicher zur Verfügung steht, den er braucht.

Dem Admin kommt im Anschluss an das erstmalige Setup eigentlich bloß noch die Aufgabe zu, ein Auge auf die Auslastung der Hardware zu haben und gegebenenfalls die Plattform zu erweitern. Doch keine Panik: Auch dafür bietet Open Stack schon eine Lösung, denn das nachträgliche Anbauen von Hardware ist angeblich kein Problem.

Ihre Erfüllung findet die Idee des Cloud Computing dann, wenn Kunden sich per Webinterface ihre virtuelle Rechenplattform selbst zusammenklicken und die vom Dienstleister aufgesetzte Umgebung sie problemlos betreiben kann.

Storage: Arg!

Open Stacks erstes Problem ist Storage. Die Anforderungen in einer Cloud sind schnell formuliert: Nahtlose Skalierbarkeit und die Möglichkeit, jeden Datensatz auf grundsätzlich jedem Host innerhalb der Cloud nutzen zu können, sind ein Muss. Auch die Performance muss stimmen. Entgegen schlecht informierten Vorhersagen ist lokaler Speicher für die VMs keine Option: In einer Cloud muss jede VM zu jedem Zeitpunkt auf jedem Host laufen können, weil sonst das Skalieren in die Breite für die gesamte Plattform nicht möglich wäre.

All diesen Anforderungen begegnet Open Stack ab Werk, indem es einen zentral angebundenen Speicher über den internen Volume-Dienst Cinder per I-SCSI an die Hypervisor-Knoten exportiert, die die I-SCSI-Geräte dann lokal an die laufenden VMs anbinden. Das ist freilich so langsam, dass sich der Admin über Themen wie Performance oder Latenz schon gar keine Gedanken mehr zu machen braucht.

Als Alternative zum I-SCSI-Wahnsinn vermarkten fast alle großen Unternehmen zurzeit Ceph (Abbildung 2, [1]). Im ersten Moment macht Ceph einen wirklich sehr guten Eindruck: Dezentraler Speicher, der sich absolut flexibel an jeden Host anbinden lässt. Auch die Skalierbarkeit in die Breite ist gegeben, denn geht der Platz aus, hängt der Admin einfach neue Ceph-Knoten hinzu. Garniert wird das Ganze mit einem sehr hohen Datendurchsatz.

Abbildung 2: Ceph ist eine Alternative zum Open-Stack-Standard mit I-SCSI, die aber an Schwächen bei der Latenz leidet.

Alles picobello also? Leider nicht: Was in der Euphorie rund um Ceph regelmäßig untergeht, ist seine völlig indiskutable Latenz-Performance. Beim Ceph Day in Berlin im April wurde deutlich, dass selbst solche Branchengrößen wie Sandisk oder Fujitsu aktuell keine Lösung für das Problem parat haben. Wer MySQL in einer Open-Stack-Instanz betreibt, die im Hintergrund auf Ceph setzt, kommt über 500 I/O-Operationen pro Sekunde (IOPS) nicht hinaus. Für Webshops und viele andere Applikationen reicht das nicht mal annähernd.

Tatsächlich gibt es mehrere kommerzielle SDN-Ansätze, die das Thema Latenz deutlich besser im Griff haben und mit denen sich Open Stack so betreiben lässt, dass zumindest 3000 IOPS nicht mehr illusorisch sind. Doch damit gilt leider auch, dass Open Stack dann kein reines Open-Source-Projekt mehr ist. Denn für den sinnvollen Einsatz ist ein kommerzielles, proprietäres Storageprodukt im Augenblick unumgänglich.

Netzwerk: Grmpf!

Während in Sachen Storage schnell klar wird, dass der Standard mit I-SCSI unbrauchbar ist, dauert es bis zu dieser Erkenntnis in Sachen SDN etwas länger. Die SDN-Story von Open Stack basiert in der Standardkonfiguration auf Open Vswitch. Die Grundidee ist einfach: Alle Knoten innerhalb des Netzes sind über GRE-Tunnel miteinander verbunden, im Grunde entsteht also so etwas wie ein Full-Mesh-Netz. Open Vswitch sorgt auf den einzelnen Hosts über virtuelle Switches mit eigenem Tagging dafür, dass die Pakete einzelner Kunden voneinander getrennt sind. Auf zentralen Netzwerkknoten findet die Anbindung nach außen statt; auch diese stehen unter der Fuchtel von Open Vswitch.

Das Gemeine an Open Vswitch ist, dass sich kleine Clouds mit nur wenigen Hypervisor-Knoten und wenigen Kunden problemlos betreiben lassen. Wenn die Zahl der Compute-Nodes aber steigt oder mehr Kunden die Plattform in Beschlag nehmen, wird die Sache schnell ungemütlich. Verschiedene Anbieter geben an, bereits bei 20 Knoten Probleme gehabt zu haben, andere legen die Latte bei 50 Hypervisors oder mehr an.

So oder so: Das Ende der Fahnenstange ist bei Open-Vswitch-basierten Setups absehbar. Das gilt übrigens auch für die Kommunikation nach draußen: Das Konzept eines einzelnen Netzwerkknotens für die Internetanbindung führt ganz automatisch zum Entstehen eines Nadelöhrs und eines Single Point of Failures (SPOF). Aktuelle Open-Stack-Versionen unterstützen zwar den Betrieb mehrerer Netzwerkknoten, doch funktioniert dann das automatische Rebalancing nicht. Fällt ein Netzwerkknoten aus, werden dessen Netze also nicht sofort auf andere Netzwerkknoten umgelegt.

Open Vswitch ist daher als Netzwerkkomponente für Open Stack nur für kleine Schön-Wetter-Setups geeignet. Enterprise-Anforderungen lassen sich in Open Stack so aber nicht umsetzen. Als Alternative bieten sich gleich mehrere Lösungen verschiedener Hersteller an – VMware mischt im SDN-Markt genauso mit wie Midokura oder Cisco. Eine insgesamt überzeugende Lösung ist Contrail, das Juniper sich zwar einverleibt hat, aber nach wie vor als eigenes Team in der Firma bestehen lässt.

The Good, the Bad and the Ugly

Anders als Open Vswitch setzt Contrail – oder, in der offenen Variante, Open Contrail (Abbildung 3, [2]) – auf eine Vielzahl verschiedener Netzwerkprotokolle, die samt und sonders etabliert und gut bekannt sind. Einen speziellen Netzwerkknoten etwa sucht man in einer Open-Contrail-Installation vergebens, denn jeder Hypervisor wird zum eigenständigen Netzwerkknoten für eine Vielzahl von Instanzen.

Abbildung 3: Open Contrail ersetzt das mitgelieferte Open Vswitch sinnvoll, kommt aber mit einigen Einstiegshürden.

Fällt ein Hypervisor-Knoten aus, kümmert sich Contrail zudem darum, dass die Anbindung der betroffenen VMs zur Außenwelt automatisch über andere Knoten hergestellt wird. Die Arbeit mit offiziellen IPs für VMs, die in Open Vswitch ebenfalls über die Netzwerkknoten abgewickelt wird, machen die Hypervisors hier selbst – indem sie ein BGP-Announcement veröffentlichen, das zu sich selbst führt. Untereinander reden die VMs MPLS über GRE.

Contrail besteht aus einer Vielzahl von Komponenten, darunter dem Dienst Analytics, der umfassende Statistiken über die Netzwerknutzung anlegt und so die Ressourcenplanung erlaubt. Auch ein schickes Webinterface gehört dazu, über das sich die wichtigsten Contrail-Einstellungen sinnvoll nutzen lassen. Sogar die Open-Stack-Anbindung steuert Juniper bei: Das Contrail-Plugin (Abbildung 4) lässt die Netzwerkkomponente von Open Stack, also Neutron, problemlos mit dem API von Open Contrail kommunizieren. Contrail wäre also der ideale Ersatz etwa für Open Vswitch, wenn …

Abbildung 4: Das Contrail-Plugin für das Open-Stack-Dashboard lässt sich nur mit vielen Patches überhaupt zur Kooperation bewegen.

Entwicklerchaos

… ja wenn die Software einen etwas weniger chaotischen Eindruck machen würde. Wer auf der Contrail-Entwickler-Mailingliste mitliest, gewinnt bisweilen den Eindruck, Releases seien eher Zufallsprodukte als geplante Vorgänge. Auch die Supportstrategie von Juniper ist wirr. Die fehlende Leitung schlägt sich aber vor allem im Chaos innerhalb von Contrail wieder: So benötigt Contrail etwa für Dienste wie DNSaaS einen eigens gepatchten Bind. Den lädt es sich beim eigenen Kompiliervorgang runter, Monkey-patcht daran herum und verpackt das bei diesem Vorgang erstellte »named« -Binary anschließend in ein eigenes Paket.

Wenig überzeugt auch der Umstand, dass Contrail intern fast maßlos diverse Komponenten sowie Programmier- und Skriptsprachen einsetzt: XML über Thrift, C++, Python, Node.js, Java, Redis, Cassandra, Zookeeper, Kafka sind nur einige der Dinge, mit denen Contrail-Admins sich herumschlagen müssen. Die Lernkurve ist also extrem steil, selbst erfahrene Contrail-Admins bitten bisweilen bei den Entwicklern um Hilfe, weil sie ein bestehendes Problem partout nicht in den Griff bekommen.

Mindestens so verstörend ist zudem die Tatsache, dass bei Contrail häufig der Eindruck von Stümperei entsteht – obgleich der Hersteller das eigentlich nicht als Ziel haben kann. Ein Patch für den »ifmap« -Client für Python, den Contrail als fixen Bestandteil enthält, macht das deutlich [3]: Weil in aktuellen Java-Versionen SSLv3 auf der Liste der verbotenen Algorithmen steht, stellten die Entwickler kurzerhand auf SSLv23 um. Jeden Security-Beauftragten fasst spätestens an dieser Stelle Entsetzen – auch wenn der »ifmap« -Teil von Contrail nicht nach außen exponiert wird, sondern nur intern zur Anwendung kommt.

Auch in Sachen SDN stehen proprietäre Alternativen bereit, die neben guter Technik auch das gute Gefühl verkaufen, das Problem ausgelagert zu haben – nämlich an den Support-Anbieter. Doch einerseits fallen dann in der Folge horrende Supportgebühren an, andererseits verstärkt sich so einmal mehr der Eindruck, dass Open Stack alleine auf der Grundlage quelloffener Software nur bedingt sinnvoll zu betreiben ist.

Die Analyse jedenfalls ergibt: Ganz so düster wie beim Thema Storage sieht es in Sachen SDN bei Open Stack zwar nicht aus, die Versprechungen der Anbieter, nur mit Open Vswitch ein funktionierendes Cloud-Networking zu realisieren, lassen sich in der Realität aber nicht durch Fakten untermauern.

Und noch mehr Probleme

Neben den beiden großen Baustellen SDN und SDS gibt es bei Open Stack mehr als genug kleinere, die technisch aber nicht minder problematisch sind. Ab Werk würde man von einer Open-Stack-Installation verschiedene Funktionen erwarten, einfach weil sie State of the Art sind: NTP-Unterstützung etwa oder zentrales Logging und zentrales Monitoring. Oder dass alle im Setup vorhandenen Komponenten die eigene Funktionalität testen können, bevor sich die jeweilige Komponente überhaupt im Cluster anmeldet.

Verschlüsselung in allen Teilen des Setups wäre zum Beispiel genauso sinnvoll wie die Fähigkeit, innerhalb eines verteilten Systems rollende Upgrades zu erlauben – also das Upgrade von einer Open-Stack-Version auf die nächste. Schließlich ist funktionierendes Billing für den Betrieb oft unabdingbar, denn ein Anbieter will seinen Kunden die erbrachte Dienstleistung auch berechnen.

All diese Features liefert Open Stack selbst schlicht nicht mit. Und dann ist da noch das Thema QA: Programmiersünden sollten in einem System mit etlichen Entwicklern und mit eigener CI-Architektur eigentlich nur in begrenztem Umfang vorkommen. Doch bei Open Stack und den angrenzenden Projekten verhallt die Forderung ungehört.

Ein konkretes Beispiel ist Keystone. Die Komponente ist in Open Stack für die Authentifizierung von Nutzern wie der Dienste untereinander zuständig. Wie fast alle Open-Stack-Dienste hat Keystone Metadaten, die es in einer MySQL-Datenbank ablegt. Für den Zugriff auf ihre Metadaten-Datenbank nutzen die Dienste nicht direkt MySQL, sondern den Python-SQL-Wrapper SQL Alchemy.

Offenbar trauten die Entwickler dem Braten aber nicht und implementierten rund um SQL Alchemy noch eine Art zweiten Wrapper – also einen Wrapper um den Wrapper –, der allerlei nutzlose Funktionalität nachrüstet. Darunter beispielsweise eine Ping-Funktion, die jede Sekunde testet, ob die Datenbank noch antwortet. Um im Rahmen eines Performance-Tests 250 Anmelde-Token pro Sekunde zu erstellen, prasseln schließlich mehrere Tausend Queries auf die MySQL-Datenbank nieder, die so unfreiwillig zum Flaschenhals wird.

Für dieses spezielle Problem immerhin ist in Kilo eine Lösung vorhanden. Die Keystone-Lightweight-Tokens sind nicht mehr beständig, sodass der Zugriff auf MySQL gar nicht erst notwendig ist. Doch leider ist das nicht das einzige Beispiel für Code, der einem die Tränen in die Augen treibt.

Funktioniere ich? Egal!

Nova, die Computing-Komponente von Open Stack, ist in mehrere Subkomponenten gespalten – jede davon ist für eine eigene Aufgabe zuständig. So läuft etwa »nova-compute« auf den Hypervisor-Knoten und startet dort VMs, wenn der Controller der Cloud sie entsprechend anweist.

Leider übersieht das Programm dabei, dass es einen Pre-Flight-Check durchführen sollte, bevor es einen Computing-Knoten in Nova als “bereit” anmeldet. Wenn sich per KVM keine VMs starten lassen, weil etwa das Kernelmodul dafür nicht geladen ist, wird das »nova-compute« nicht davon abhalten, den Rechner im Cluster zu registrieren. Das Ende vom Lied sind Nutzer, die statt einer laufenden VM nur krude Fehlermeldungen sehen.

Verrechnung geht auch nicht

Ein Beispiel für einen Totalausfall ist Ceilometer: Das Werkzeug war ganz am Anfang seiner Entwicklung als Parkuhr gedacht. Diese sollte sich einfach an die sowieso vorhandenen Notification Queues von Rabbit MQ hängen und dort mitschreiben, was sich im Cluster tut. Verschiedene Agents waren außerdem auf den Hypervisor-Hosts dafür zuständig, Aufzeichnungen hinsichtlich verschiedener Verbrauchsparameter anzufertigen.

Praktisch ist Ceilometer nie auch nur ein ernsthaftes Projekt geworden. Ihm haftet der Ruf an, langsam und behäbig sowie instabil zu sein. Der erste Project Technical Lead (PTL) von Ceilometer und Quasi-Miterfinder Julien Danjou gab in einem Blogposting letztes Jahr bekannt, woran Ceilometer seiner Meinung nach gescheitert sei. Dabei erklärte er sich mitschuldig und legte kurz danach sein PTL-Amt nieder. Aus den Rewrite-Plänen, die Danjou damals öffentlich machte, ist bis auf den heutigen Tag nicht viel mehr entstanden als ein paar Proof of Concepts (Abbildung 5).

Abbildung 5: Ceilometer gilt mit seiner aktuellen Architektur als erledigt, doch die Arbeit am Rewrite kommt nicht voran.

Was ist hier eigentlich los?

Die Liste von Was-zum-Teufel-Momenten im Leben eines Open-Stack-Admin ließe sich fast beliebig fortsetzen, doch ist damit niemandem geholfen. Wichtiger als die Feststellung, dass etwas nicht stimmt, ist die Frage nach dem Warum. Wie kann ein Projekt, das mit hinreichend viel Geld und sehr viel Manpower durch diverse große Unternehmen ausgestattet ist, derart chaotisch organisiert sein und so miese Resultate abliefern? Was läuft schief bei Open Stack? Die Antwort ist eigentlich denkbar simpel: Wer kein Ziel hat, der weiß auch nicht, wohin er fahren soll. Genau so präsentiert sich das Open Stack-Projekt aktuell: Wie ein Projekt, das kein konkretes Ziel hat.

Ein Ansatz, um die nötigen Ziele zu schaffen, könnte dabei die obligatorische Frage nach dem Produkt sein, das Open Stack sein will. Dazu müsste die Open Stack Foundation, die quasi die oberste Hüterin über das Wohlergehen des Projekts ist, allerdings die eigene Perspektive um ganze 180 Grad drehen. Denn aktuell erfolgt Entwicklung in Open Stack stets im Sinne der Hersteller: Die großen Unternehmen fragen sich, welche Art von Funktionalität in Open Stack nützlich wäre, um die eigenen Produkte so gut wie möglich zu unterstützen. Genau diese Funktionalität entwickeln sie dann für den Open-Stack-Einsatz in ihrer kleinen Nische.

Doch müsste es genau umgekehrt sein: Open Stack müsste sich die Frage stellen, welches Produkt ein ISP braucht, wenn er eine sinnvolle Cloudplattform betreiben will, und auf das Resultat dieser Überlegungen hinarbeiten. Gegenwärtig geht die Entwicklung aber andere Wege: Die Kilo-Release ist die erste Release nach dem Big-Tent-Schema. Vereinfacht ausgedrückt ist die Idee hinter dem “großen Zelt”, dass so ziemlich jede Komponente Teil von Open Stack sein kann, solange sich deren Entwickler zur Einhaltung von wenigen grundsätzlichen Regeln verpflichten.

Die meisten Unternehmen, die auf dem Markt für Open-Stack-Lösungen aktiv sind, unterstützen dieses Ansinnen. Das klingt absurd, ist aber nur folgerichtig: Wenn am Markt etliche Open-Stack-Produkte aktiv sind, brauchen die einzelnen Produkte Alleinstellungsmerkmale, um sich vom “Vanilla Open Stack” abzugrenzen. Red Hat, Suse, Canonical, HP und all die anderen Firmen haben also gar kein gesteigertes Interesse daran, eine solide Basisdistribution von Open-Stack-Komponenten zu haben – denn damit würden sie sich das Leben selbst nur schwerer machen.

Licht am Ende des Tunnels

Bei allen negativen Eigenschaften, die Open Stack aktuell ausmachen, ist eines unbestritten: Der Begriff der Open Source Cloud wird auf lange Zeit mit Open Stack verbunden bleiben, weil das Projekt die ganze PR seiner ehemaligen Konkurrenten praktisch aufgesogen hat. Keine andere Software hat aktuell ein mit Open Stack vergleichbares Momentum. Alles Weinen hilft nicht, Open Stack ist aktuell ohne Alternative, wenn es um wirklich große ISPs geht.

Doch ist noch nicht alle Hoffnung verloren. Folgt man dem Hype Cycle des IT-Analyse-Unternehmens Gartner [4], dann befindet sich Open Stack aktuell auf dem Gipfelpunkt seines eigenen Hype: Anbieter schüren demnach Erwartungen und Hoffnungen, die irrational sind. Dem Hype folgt meist ein eher unsanfter Absturz in die Realität, also in den schnöden Alltag von IT-Firmen.

Tatsächlich gibt es so manches Licht am Ende des Tunnels: Ceph löst zwar nicht alle Probleme in Sachen Storage, ist aber dennoch ein guter Ansatz. Wer sich beharrlich durch Open Contrail beißt, bekommt auch ein funktionierendes Netzwerk für die eigene Cloud. Der amerikanische Cloudanbieter Rackspace bietet in Form von Stacktach [5] eine Alternative zu Ceilometer, die diesem haushoch überlegen ist.

Mit der Zeit wird sich bei den einzelnen Open-Stack-Komponenten überdies auch die Erkenntnis durchsetzen, dass eine Kiste mit Schrauben und Ösen für ISPs nur von begrenztem Nutzen ist. Sie wollen nicht mit einem Bausatz experimentieren, sondern brauchen ein fertiges Produkt.

Auch das Thema Ausbildung spielt hier eine Rolle: Angesichts des Umfangs der einzelnen Open-Stack-Komponenten scheint es aktuell nur schwer möglich, das eigene Personal für Open Stack auszubilden. Stattdessen orientiert sich die Ausbildung stets an der eigenen, meist hochspezifischen Open-Stack-Installation. Das Finden neuer Mitarbeiter mit entsprechender Vorerfahrung ist so aber fast unmöglich.

Im Moment gilt für Unternehmen jedenfalls, dass Open Stack kein fertiges Produkt ist – und ganz sicher nichts, das sich als Produkt eines Herstellers ohne großen Aufwand einfach so installieren ließe. Wenn Unternehmen für sich beschließen, die Einführung von Open Stack in Betracht zu ziehen, führt das in jedem Fall zu vielen Tests, viel Evaluation und sehr viel Lernerei. Genau hier liegt die große Herausforderung, der Open Stack sich in nächster Zeit stellen muss. Das Problem ist die fehlende Produktdefinition und erst in zweiter Linie ein zu kleines Feature-Set aufgrund fehlender Komponenten.

Festzustehen scheint: Open Stack wird eine dominierende Cloudlösung mit hohem Entwicklungsbedarf bleiben. Langweilig wird es nicht.

Der Autor

Martin Gerhard Loschwitz arbeitet als Cloud Architect bei Sys Eleven. Er beschäftigt sich dort intensiv mit den Themen Open Stack, Distributed Storage und Puppet. Außerdem pflegt er in seiner Freizeit Pacemaker für Debian.