© Mykola Kokaryev, 123RF

Mirantis stampft seine Open-Stack-Distribution und das Deployment-Werkzeug Fuel ein und platziert in Zukunft einen hybriden Ansatz aus Open Stack und Kubernetes in die Auslage. Das Linux-Magazin hat sich die Mirantis Cloud Platform 1.0 genauer angesehen.

Mirantis ist längst nicht mehr nur den eingefleischten Cloudentwicklern und Admins ein Begriff, das amerikanische Unternehmen kennen mittlerweile selbst jene, die sich mit der Cloud nur am Rande beschäftigen. Schließlich ist es dem Unternehmen gelungen, sich mit seinem Produkt Mirantis Open Stack neben den großen Linux-Anbietern wie Suse, Red Hat oder Canonical am Markt zu etablieren. Selbst Großaufträge wie die Einführung einer Cloud bei Volkswagen hat die Firma den etablierten Herstellern vor der Nase weggeschnappt. Eigentlich, so mag es scheinen, ist in Sunnyvale in Kalifornien alles in Ordnung.

Umso erstaunter war mancher Beobachter, als Mirantis Anfang April ein völlig neues Produkt – Mirantis Cloud Platform – an- und Mirantis Open Stack samt dem Installer Fuel [1] zugleich abkündigte. Was war geschehen? Stimmt Mirantis in den Chor jener ein, die Open Stack schon das Ende seiner Hoch-Zeit voraussagen, und orientiert sich um? Grund genug, sich die Mirantis Cloud Platform (MCP) und ihre Ziele genauer anzuschauen.

Open Stack ist mühsam

Die Ursachen für den vermeintlichen Gesinnungswandel bei Mirantis reichen weit in die Vergangenheit zurück. Lange Zeit hat Mirantis stolz behauptet, als einzige Firma am Markt “Pure Play Open Stack” zu verbreiten. Gemeint war, dass das Open Stack von Mirantis tatsächlich weitestgehend ohne Secret Sauce auskam, während andere Hersteller an ihren Open-Stack-Distributionen nach Belieben herumpatchten. Was vom Linux-Kernel manchem Admin bereits leidlich bekannt ist, fand bei Open Stack nahtlos seine Fortsetzung. Stets ging die Entscheidung für eine fertige Open-Stack-Distribution mit einem klassischen Lock-in beim jeweiligen Hersteller einher.

Zwar waren auch die Mirantis-Pakete zum Teil mit Patches versehen, Fakt ist aber, dass Mirantis’ Open Stack noch am ehesten mit den Vanilla-Quellen des Open-Stack-Projekts vergleichbar war. Weil man sich nicht auf das Deployment-Framework der eigenen Linux-Distribution verlassen konnte, sprang Mirantis obendrein in die Bresche und entwickelte ein Deployment-Werkzeug: Fuel (Abbildung 1). Mirantis stellte das Programm unter eine freie Lizenz, machte es sogar zu einer Komponente im Big Tent der Open Stack Foundation und lud die Community ein, sich an dessen Entwicklung zu beteiligen.

Abbildung 1: In Form von Fuel hat Mirantis ein Setup-Werkzeug für Open Stack am Markt etabliert, das leicht zu bedienen ist. Nun verschwindet es wieder in der Versenkung.

Der Ehrlichkeit halber sei in diesem Zusammenhang aber erwähnt, dass weite Teile der Community Mirantis freilich trotzdem als ganz normalen Open-Stack-Distributor betrachteten. So war das Feedback auf Fuel und Mirantis Open Stack insgesamt eher zurückhaltend: Vereinzelt steuerten externe Entwickler zwar Patches bei, in Summe erledigte Mirantis aber nach wie vor das Gros der Arbeit selbst. Was schade war, denn tatsächlich war Fuel bis zuletzt die bequemste und leichteste Art, an ein grundlegendes Open-Stack-Setup zu kommen.

Zu dem teils ausbleibenden Erfolg bei der Community mit Fuel kommt für Mirantis ein weiterer Faktor erschwerend hinzu: Der Hype rund um Open Stack ebbt seit einiger Zeit offenbar ab.

Absteigender Ast?

Das ist zunächst nicht verwunderlich: Über mehrere Jahre war Open Stack fast der Alleinunterhalter im Blätterwald, wenn es um Public Clouds abseits der großen Anbieter wie Amazon, Microsoft oder Google ging. Die Lösung hat andere Ansätze wie Eucalyptus vom Markt praktisch verdrängt. Eine gar nicht so kurze Weile schien es, als sei für Open Stack praktisch alles möglich.

Viele der Unternehmen, die sich mit Open Stack beschäftigten, holten sich aber eine blutige Nase – zum Teil auch absehbar. Wer nur ein paar virtuelle Systeme verwalten möchte, braucht dafür nicht zwingend Open Stack und auch keine Public Cloud. Mittlerweile existieren diverse Berichte enttäuschter Unternehmen, die Open Stack für genau solche Zwecke einsetzten wollten – und entnervt aufgegeben haben, als ihnen dessen Komplexität klar wurde (Abbildung 2).

Abbildung 2: Open Stack ist ein komplexes Konstrukt, das aus diversen Komponenten besteht. Fuel von Mirantis half Unternehmen bisher beim Open-Stack-Einstieg.

Am besten lässt sich der aktuelle Open-Stack-Status mit der Theorie des Hype Cycle von Gartner [2] erklären: Nach der Hype-Phase setzt jetzt aktuell die Desillusionierung ein. Insgesamt beschäftigen sich deutlich weniger Firmen mit der Lösung. Jene, die Open Stack die Treue halten oder die heute anfangen, sich mit dem Produkt eingehend zu befassen, wissen – anders als die Unternehmen am Beginn des Hype – jedoch auch, worauf sie sich einlassen.

Die Gefahr, dass sie ihre Open-Stack-Projekte später einstampfen, ist daher deutlich geringer und die Anzahl der gescheiterten Open-Stack-Projekte wird abnehmen.

Vor diesem Hintergrund könnte Mirantis sich eigentlich freuen, weil absehbar Open-Stack-Wissen und -Consulting weiterhin ein begehrtes Gut sein werden. Aber in der Vergangenheit hat der Hersteller eben auch viel Umsatz mit jenen Kunden generiert, die bei Null anfingen und Hilfe beim Open-Stack-Einstieg suchten. Die konnte man mit einer Kombination aus Fuel, Mirantis Open Stack sowie Consulting und Training gut bedienen – fast egal, ob die Projekte später wieder eingestellt wurden.

Weniger neue Open-Stack-Projekte bedeutet für Mirantis also konkret weniger Möglichkeiten, Umsatz zu generieren. Wendet sich Mirantis nun ganz anderen Ansätzen zu, um mit ihnen, wie bei Open Stack, wieder auf der Welle des Hype Cycle zu surfen? Verschwindet das Open-Stack-Engagement von Mirantis in absehbarer Zeit komplett?

Solchen Gedankenspielen erteilt Boris Renski eine Absage. Renski ist einer der Mirantis-Gründer und kümmert sich aktuell um das Marketing. Er stellt klar, dass über 90 Prozent des Mirantis-Umsatzes direkt an das Thema Open Stack gekoppelt sind. Glaubt man ihm, so ist die Mirantis Cloud Platform (MCP) nur eine logische Evolutionsstufe nach Open Stack Mirantis und Fuel, fast schon eine unabdingbare Konsequenz. Um das nachzuvollziehen zu können, ist ein etwas genauerer Blick auf die Mirantis Cloud Platform notwendig.

Eierlegende Wollmilchsau

Beim Scrollen durch die Dokumentation des Produkts taucht regelmäßig ein Name auf, der besonders Docker-Fans längst geläufig sein dürfte: Kubernetes (Abbildung 3). Tatsächlich gilt Kubernetes aktuell gewissermaßen als Nachfolger von Open Stack in Sachen IT-Hype. Frei nach dem Motto: Wer etwas auf sich hält, beschäftigt sich mit Containern, mit Docker und auf jeden Fall mit Kubernetes – Googles Werkzeug, um Docker-Container effizient in einem großen Pool von Servern zu verwalten. Gleichzeitig redet die MCP-Doku aber auch durchweg von Open Stack. Da fragt sich mancher Admin: Ja, was gilt denn jetzt?

Abbildung 3: Kubernetes gehört genauso zur Mirantis Cloud Platform wie Open Stack, das Produkt kann also sowohl VMs als auch Container verwalten. (Grafik: Wikipedia)

Bei genauem Hinsehen entpuppt sich die Mirantis Cloud Platform als der klassische Versuch für eine eierlegende Wollmilchsau. Sowohl Open Stack als auch Kubernetes sind Teil der Lösung. Das erklärte Ziel ist, dass Anwender über die immer gleichen Schnittstellen fast nach Belieben virtuelle Maschinen (in Open Stack) oder aber Container (in Kubernetes) per API-Befehl starten können. Damit das funktioniert, kombiniert Mirantis unter der Haube einen Haufen verschiedener Lösungen, um dem potenziellen Nutzer das aus Mirantis-Sicht beste Clouderlebnis zu ermöglichen. Welche Komponenten kommen dabei zum Einsatz?

Open Stack und Kubernetes

Zunächst gehört zum Lieferumfang der Mirantis Cloud Platform eine vollständige Open-Stack-Distribution. Die besteht aus den Kernkomponenten, die für den Betrieb der Cloud zwingend notwendig sind, sowie einigen Zusatzdiensten aus dem Big Tent. Man darf annehmen, dass die technische Basis für diesen Teil der MCP wohl die alte Mirantis-Open-Stack-Distribution gewesen ist.

Mit Kubernetes verhält es sich ganz ähnlich: Auch der von Kubernetes selbst zur Verfügung gestellte Funktionsumfang ist Teil der MCP. Während Kubernetes in sich einigermaßen komplett ist und nur wenige externe Zusatzdienste braucht, sieht die Sache bei Open Stack anders aus: Es lässt sich bekanntlich mit einer Reihe zusätzlicher Komponenten kombinieren. Mirantis macht bei MCP von dieser Möglichkeit regen Gebrauch.

SDN mit Open Contrail

In Sachen Software Defined Networking setzt MCP nicht etwa auf Open Vswitch, das bei der Open-Stack-SDN-Komponente Neutron eigentlich der Standard ist. Wer die MCP benutzt, landet stattdessen bei Open Contrail [3] von Juniper. Das ist durchaus bemerkenswert, denn Open Contrail ist deutlich komplexer als Open Vswitch. Dafür gilt es allerdings auch als deutlich fortgeschrittener hinsichtlich der eigenen Architektur und der unterstützten Protokolle.

Zur Erinnerung: Open Vswitch funktioniert auf Basis eines Kernelmoduls, das auf den Hosts virtuelle Switches unterstützt. Mittels GRE- oder VxLAN-Tunneln führt Open Vswitch die Trennung von Traffic auf der Systemebene durch, sodass Kunden den Traffic anderer Kunden in ihren VMs niemals zu Gesicht bekommen. Weil die Open-Vswitch-Instanzen auf den einzelnen Hosts voneinander aber nichts wissen, produziert Open Vswitch viel Overhead-Traffic, zum Beispiel für ARP zwischen VMs, die auf unterschiedlichen Hosts laufen.

Open Contrail ist effizienter: Auch das Produkt von Juniper hat ein eigenes Kernelmodul. Im Hintergrund werkelt aber eine zentrale Datenbank, die sich den aktuellen Host einzelner VMs merkt. Sucht eine VM eine andere, fängt ein eigens zu diesem Zweck auf jedem Host beheimateter Agent die jeweiligen ARP-Requests ab und beantwortet sie selbst. Den Overhead reduziert das deutlich. Auch die Anbindung an die Außenwelt hat Open Contrail besser gelöst als Open Vswitch: Protokolle wie MPLS und BGP sind in Open Contrail integriert, um externe Konnektivität herzustellen.

Doch hat die Medaille eine zweite Seite: Open Contrail ist viel komplexer als Open Vswitch. Bessere Performance und die Option, besser in die Breite zu skalieren, erkauft man sich letztlich also durch ein deutlich umfassenderes Setup. Contrail selbst besteht aus beinahe genau so vielen Komponenten wie die gesamte Open-Stack-Umgebung.

Dass es Mirantis gelungen ist, Contrail als Werkzeug in seinen Cloud-Werkzeugkoffer zu packen, ist also durchaus eine beachtliche Engineering-Leistung. Hier zahlt sich ein Zukauf der jüngeren Firmengeschichte aus: Im September 2016 übernahm Mirantis nämlich TCP Cloud, das sich auf die Arbeit mit Open Contrail spezialisiert hatte.

SDS mit Ceph

Fast schon zu erwarten war hingegen Mirantis’ Entscheidung, weiterhin auf Ceph [4] als Lösung für Software Defined Storage in MCP zu setzen. Mit Ceph hat man bei Mirantis schließlich Erfahrung: Fuel war bereits in der Lage, einen kompletten Ceph-Cluster per Mausklick einzurichten. Hinzu kommt, dass sich Ceph mittlerweile zum Quasi-Standard in Sachen Objektspeicher mit verteilter Ablage entwickelt hat: Kaum eine Open-Stack-Cloud setzt nicht darauf. Nicht ohne Grund: In Sachen Robustheit gehört Ceph zur Gruppe der zuverlässigsten Storage-Lösungen überhaupt.

Extrawürste auch bei Kubernetes

Ganz ohne externe Komponenten belässt es Mirantis auch bei Kubernetes nicht. Auch hier ergänzt der Hersteller eine externe SDN-Lösung: Calico [5] kümmert sich im Container-Teil der Plattform darum, dass Container auf Wunsch mit anderen Containern sowie mit der Außenwelt Daten austauschen können. Calico erweitert Kubernetes um eine Vielzahl von Features: Neben der Möglichkeit, BGP mit der Außenwelt ohne Overlay-Netzwerk zu sprechen, gehört dazu auch eine Policy-Engine, über die der Admin Netzwerkregeln definiert und erzwingt. Salopp ließe sich die Policy-Engine von Calico als Gegenstück zu den in Open Stack zum Lieferumfang gehörenden Security Groups auffassen.

Für die Mirantis Cloud Platform weicht der Hersteller von einem Mantra ab, das ihm früher noch heilig war: In der MCP finden sich sehr wohl Mirantis-eigene Komponenten. Nur zum Besten der Nutzer, wie man eifrig beteuert: Drivetrain und Stacklight sollen lediglich dem Admin das Leben erleichtern.

Drivetrain

In Form von Drivetrain nimmt Mirantis das leidige Thema Deployment sowie Lifecycle-Management ins Visier. Wer Open Stack schon mal ausgerollt hat, weiß um dessen Komplexität. Die Probleme gehen bereits los, bevor eine Open-Stack-Komponente überhaupt irgendwo installiert ist: Wie lässt sich ein – bei Clouds naturgemäß riesiger – Park von Servern verwalten? Wie erhalten die einzelnen Systeme ihr Betriebssystem und wer kümmert sich darum, dass wichtige (Security-)Updates den Weg auf die Systeme finden? Drivetrain nimmt sich dieser Aufgaben in MCP an.

Warum Mirantis hier das Rad unbedingt neu erfinden musste, statt auf eines der bestehenden Deployment-Systeme für Open Stack und Kubernetes zu setzen, erschließt sich erst bei genauerem Hinsehen: Auf Basis von Salt und Reclass hat der Hersteller nämlich ein Framework gebaut, das zusätzlich zum typischen Lifecycle-Management auch ein Change-Management bietet. Salt Stack sorgt einerseits für das Deployment der Dienste auf der Hardware. Auf der anderen Seite kümmert sich ein Gespann aus Git, Gerrit sowie Jenkins darum, dass Änderungen an der Plattform in protokollierter, überprüfter Weise möglich sind.

Sogar an die Optik hat man gedacht: Dem Admin steht ein GUI zur Seite, über das er Änderungen selektiv genehmigen oder zurückweisen darf. Weil die gesamte Konfiguration der Umgebung in Form von Code vorliegt, lässt sich so jede beliebige Änderung durchführen.

Der Blick fürs Detail

Laufende Installationen von Open Stack oder Kubernetes sind zwar schön, sie sind aber nur die halbe Miete. Wenn das Setup einmal steht, ist der Admin auf fortlaufende Metrikdaten angewiesen, die Auskunft über den Zustand der Plattform geben. Für den Betreiber der Plattform ist etwa die Information elementar, wann die nächste Ausbaustufe der Hardware ansteht. Gleichzeitig will der Admin auch erfahren, wenn auf einem Host des Setups etwas schiefgeht, das händisches Eingreifen erfordert.

Besonders das Thema Logging ist ein neuralgischer Punkt: Bei Dutzenden oder Hunderten Hosts ist die Menge der anfallenden Logmeldungen pro Sekunde – und gerade bei Open Stack – so groß, dass sie manuell nicht mehr zu bewältigen ist. Lösungen wie Logstash und Kibana lösen in Kombination das Problem. Ihr Setup ist aber aufwändig.

Ähnliches gilt für den Themenkomplex Monitoring, Alerting und Trending (MAT): Lösungen wie Prometheus oder Influx DB mit Sensu und Grafana existieren, sind in der Handhabung aber recht kompliziert (Abbildung 4).

Abbildung 4: Grafana im Gespann mit der Influx DB bietet eine große Vielzahl an verschiedenen Metriken und Graphen, die alle visuell Auskunft über den Zustand und die Performance der Cloud geben.

Bei der Mirantis Cloud Platform bekommt der Admin das Wunschlos-glücklich-Paket: Stacklight heißt die Komponente, die unter der Haube viele Lösungen zum perfekten Helfer für das Operationsteam machen soll. Ein eigener Dienst holt von den Hosts die relevanten Logdateien ab und kippt sie danach in die Kombi aus Elasticsearch und Kibana (Abbildung 5), wo der Admin auf sie zugreift.

Abbildung 5: Die gut eingespielte Kombination aus Kibana und Elasticsearch ermöglicht es unter anderem, die Logs von Open-Stack-Diensten effizient zu verwalten.

Influx DB sowie Grafana kümmern sich im Gespann um das Sammeln und Anzeigen von Metrikdaten, sodass das Operationsteam weiß, was auf der eigenen Plattform gerade los ist. Und falls mal was schiefgeht, steht Sensu bereit: Es überwacht auf Basis einer Standardkonfiguration die Komponenten der MCP und schlägt Alarm.

De facto befreit Mirantis den Admin also von drei elementaren Problemen mit einem Schlag. Hier bietet das Produkt echten Mehrwert: Wollte der Admin nämlich ein vergleichbares Setup händisch bauen, wäre er damit einige Zeit beschäftigt.

Lieber in kleinen Schritten

Gebetsmühlenartig weist Mirantis darauf hin, dass sich MCP in einem sehr zentralen Punkt von anderen Cloudprodukten unterscheidet: Anstelle der großen Updates will Mirantis die MCP-Installationen kontinuierlich mit kleinen Updates versorgen, die regelmäßig einzuspielen sind.

Bei erfahrenen Open-Stack-Admins löst dieser Ansatz sicherlich Interesse aus, denn große Updates, bei denen die Open-Stack-Komponenten auf die nächste Major-Version gehoben werden, sind oft genug ein Horrorszenario. Nicht selten gehen diese Updates zumindest teilweise schief: Am Ende steht dann eine halb kaputte Cloud, die nur noch durch mühsame Handarbeit zu reanimieren ist.

Andere Unternehmen wählen gleich einen anderen Ansatz und bauen eine zweite Cloud mit neuer Software zur ersten Cloud parallel auf, um anschließend die Daten mühsam zu migrieren. Viel besser als das erste Szenario ist das allerdings auch nicht.

Bis Redaktionsschluss war allerdings nicht nachvollziehbar, ob das System, das Mirantis sich ausgedacht hat, zuverlässig funktioniert. Wenn es der Firma aber gelingt, Open-Stack- und (in deutlich kleinerem Umfang) Kubernetes-Updates den Schrecken zu nehmen, wäre auch das eine beachtliche technische Leistung.

Das Vertriebsmodell: Mieten statt kaufen

Klar scheint bisher: Mirantis gelingt in Form der Mirantis Cloud Platform ein Meisterstück. Die Kombination vieler verschiedener Dienste unter einer Haube, auf die Nutzer über definierte APIs zugreifen, nötigt auch den in der Community vorhandenen Mirantis-Kritikern Respekt ab. Dabei soll nicht in Vergessenheit geraten, dass der ausführende Admin es noch immer mit einer großen Anzahl loser Teile zu tun hat, die viel Fachwissen voraussetzen.

Auch für dieses Problem hat Mirantis allerdings eine Lösung, denn anders als noch Mirantis Open Stack und Fuel kann man die Mirantis Cloud Platform nicht einfach kaufen und selbst installieren. Mirantis hat sich ein besonderes Vertriebsmodell für die MCP überlegt.

Die Marschrichtung gibt erneut Boris Renski vor: Dieser hatte bei der Vorstellung der MCP die nicht ganz abwegige These aufgestellt, dass die meisten Unternehmen in einer Open-Stack- oder Kubernetes-Installation nur ein notwendiges Übel sehen, ein Mittel zum Zweck. Eigentlich sei ja die große Flexibilität das Objekt der Begierde, die Open Stack und Kubernetes hin zur Nutzer-Seite böten. Wenn ein Unternehmen diese Vorteile an die Kundschaft durchreichen wolle, müsse es einfach eine eigene Plattform betreiben – obwohl es das eigentlich gar nicht will.

Nobel wie man im Hause Mirantis nun mal ist, springt man mit der MCP den gebeutelten Firmen zur Seite: In den ersten zwölf Monaten nach dem Setup einer MCP-Plattform betreibt Mirantis diese quasi im Kundenauftrag selbst – ob der Kunde das will oder nicht. Nach frühestens zwölf Monaten besteht die Option, das Setup an den Kunden mit allen Komponenten zu übergeben.

Süffisant merkt man bei Mirantis an, dass man die zwölf Monate auch abseits der Plattform sehr sinnvoll nutze: So könne man das Operationsteam, das die Umgebung irgendwann selbst betreiben soll, in Sachen Devops schulen, um dort so viel Wissen wie nötig aufzubauen.

Doch lässt sich diese Vertriebsart auch aus einer anderen Perspektive betrachten: Dann stellt man deutlich weniger charmant fest, dass Mirantis Cloud Platform in erster Linie wohl als Produkt konzipiert ist, das die Professional Services von Mirantis unters Volk bringen soll. Denn die zwölf Monate Händchenhalten lässt Mirantis sich ebenso bezahlen wie etwaige Schulungen in dieser Zeit.

Das muss nicht automatisch und unter allen Umständen schlecht sein. Wer die Vorteile von Open Stack und Kubernetes nutzen möchte, ohne sich den Betrieb der Plattform dafür aufzubürden, der ist mit der Cloud Platform sicher nicht schlecht bedient. Leider rückt Mirantis Preise für seine Software und Dienstleistungen nur auf konkrete Anfragen heraus. Aus diesem Grund muss diese Information jeder selbst einholen.

Die Abkündigung von Mirantis Open Stack und Fuel führt naturgemäß dazu, dass Plattformen, die jene Komponenten aktuell nutzen, sich Alternativen überlegen müssen. Das Unternehmen verspricht diesen Kunden einen Migrationspfad von Mirantis Open Stack hin zur MCP – auch dabei dürfte es sich allerdings um kundenspezifische Projekte handeln, die zusätzliche Kosten hervorrufen. Ein Jahr Galgenfrist hat Mirantis Open Stack ohnehin noch, bevor die Firma ihm das Licht ganz abdreht.

Fazit

Technisch ist die Mirantis Cloud Platform bemerkenswert. Der Hersteller hat alle relevanten Werkzeuge in einen Koffer gepackt: Open Stack bildet mit Kubernetes den Kern der Plattform und ermöglicht es Unternehmen, virtuelle Maschinen und Container über offene, sauber dokumentierte APIs zu kombinieren.

Weil ein Open Stack oder ein Kubernetes allein noch nicht glücklich machen, enthält der Werkzeugkoffer zusätzliche Komponenten: Ceph als Allroundlösung für verteilten Storage, Open Contrail als fortschrittliche SDN-Lösung für Open Stack und Calico als Netzwerk-Allzweckwaffe bei Kubernetes.

Auch die alltäglichen Sorgen der Administratoren nimmt man in Sunnyvale ernst: Der auf Salt basierende und direkt mit einem Kommandozeilen-Interface versehene Deployment-Mechanismus deckt das Thema Lifecycle-Management gut ab. Dank Kibana, Elasticsearch, Influx DB und vielen weiteren Komponenten weiß der ausführende Admin außerdem zu jeder Zeit, was in seiner Cloud gerade los ist. Hätte Mirantis diesen Werkzeugkoffer samt Dokumentation in dieser Form zum Kauf angeboten, hätte das so manchem Manager von Red Hat oder Suse möglicherweise den Angstschweiß auf die Stirn getrieben.

Stattdessen bedingt Mirantis es sich aus, den Werkzeugkoffer selbst zu liefern und Arbeiten mit den darin vorhandenen Werkzeugen zumindest am Anfang selbst zu erledigen – gegen Aufpreis. Das kann funktionieren: Gelingt es dem Unternehmen, genug Kunden zu finden, die eine Cloud wollen, ohne sich um deren Administration zu kümmern, dürfte das Produkt zum Erfolg werden.

Weniger erfreut sind vermutlich jene Kunden, die bisher Mirantis Open Stack nutzen. Ihnen steht eine Migration noch völlig unbekannten Ausmaßes ins Haus, bei der Mirantis natürlich gerne behilflich ist – vorausgesetzt die Kohle stimmt, versteht sich. Als einziger Anbieter einer freien Open-Stack-Distribution mit funktionierenden Open-Stack-Paketen, die ohne Aufpreis zu beziehen sind, verbleibt damit nach heutigem Stand nur noch Canonical.