OpenStackbietet diverse Möglichkeiten,Cloud-Umgebungen in Verbindung mit vielen anderenOpen-Source-Technologien kosteneffizient zu betreiben. Allerdings steigt die Komplexität damit dramatisch an. Auch wenn CIOs und Infrastruktur-Manager dazu tendieren, OpenStack nur als Cloud-Management-Schicht einzusetzen, entsteht ein hoher Komplexitätsgrad, den es zu verwalten gilt.
IT-Organisationen, die in Eigenregie versuchen, mit dieser Komplexität umzugehen, setzen sich tendenziell dem Risiko aus, anstatt eines industriekonformen Standards eine eigene, nicht beherrschbare Cloud-Infrastruktur zu schaffen. IT-Entscheider sollten sich daher intensiv mit der Frage "Eigenbetrieb versus Managed OpenStack" auseinandersetzen. Als mögliche Optionen haben sich vier Spielarten herauskristallisiert, die sich insbesondere dadurch unterscheiden, wie viel Eigenleistung beim Aufbau und Betrieb der OpenStack-Umgebung investiert werden muss.
OpenStack-ready Infrastructure
In einem "OpenStack-ready Infrastructure"-Szenario stellt ein Anbieter seinem Kunden eine für den OpenStack-Einsatz zertifizierte und somit vorbereitete, "nackte", physikalische Infrastruktur zur Verfügung. Die Rechen- und Speicherplatz-Ressourcen ermöglichen es dem Kunden, seine individuelle OpenStack-Cloud-Infrastruktur aufzubauen. Er profitiert insbesondere davon, dass der Anbieter dafür sorgt, dass nur Hardware verwendet wird, die zu 100 Prozent von den OpenStack-Releases unterstützt wird. Das bedeutet, dass der Kunde sich darauf verlassen kann, dass die notwendigen Compute-, Storage- und Networking-Treiber in den OpenStack-Releases kompatibel zu der bereitgestellten Hardware sind.
Der Anbieter ist für die Wartung der physikalischen Infrastruktur zuständig und tauscht im Fehlerfall die Komponenten aus. Abseits der physikalischen Infrastruktur ist der Kunde hier für alle anderweitigen Aufgaben zuständig. Er besitzt die Freiheit, sich seine höchst individuelle OpenStack-Umgebung aufzubauen. Gleichzeitig ist er aber auch für die Installation, Konfiguration, Wartung, für Updates und Upgrades von OpenStack zuständig - keine leichte Aufgabe. Neben diesem OpenStack-DIY-Ansatz (Do-it-yourself) kann der Kunde auf eine fertige Distribution zurückgreifen, die er komplett in Eigenverantwortung auf der Infrastruktur betreibt. Damit erspart er sich die Konfigurationskosten und je nach Distribution die Aufwände für Updates und Upgrades.
Managed OpenStack-Infrastructure
In einem "Managed OpenStack Infrastructure"-Betrieb agiert der Anbieter als OpenStack Full Service Provider. Er stellt dem Kunden sowohl die physikalische Infrastruktur als auch die OpenStack-Umgebung zur Verfügung. Der Anbieter übernimmt die Verantwortung für den Betrieb der Server- und Storage-Systeme, tauscht im Fehlerfall die Komponenten, sorgt für deren Wartung und übernimmt das Sizing der Infrastruktur. Gleichzeitig ist er für die Basis-OpenStack-Umgebung verantwortlich.
Er installiert, konfiguriert und wartet - zum Teil nach Rücksprache mit dem Kunden - die OpenStack-Infrastruktur und sorgt dafür, dass diese ständig up to date ist. Hierfür setzt er vorwiegend auf eine Distribution, um den Aufwand über eine große Anzahl von Kunden gering zu halten.
Der Anbieter stellt seinen Kunden somit einen Managed Infrastructure-as-a-Service (IaaS) auf Basis von OpenStack zur Verfügung. Der Kunde nutzt die OpenStack-Umgebung und ist weder für die Hardware noch für den eigentlichen Betrieb von OpenStack zuständig. Über ein Self-Service Portal (OpenStack Dashboard) oder die APIs nutzt er das IaaS-Angebot, um sich eine virtuelle Infrastruktur auf Basis von virtuellen Servern und Storage für seine Bedürfnisse zusammenzubauen.
Je nach Anbieter können neben virtuellen Servern auch Bare Metal Server (physikalische Hosts) über OpenStack bereitgestellt werden. Auf dieser OpenStack-Infrastruktur lassen sich dann eigene Applikationen und Systeme betreiben. In diesem Szenario ist es wichtig zu verstehen, dass der Kunde vollständig für den Aufbau und Betrieb der auf OpenStack-basierten virtuellen Infrastruktur sowie den darauf betriebenen Applikationen verantwortlich ist.
OpenStack-Distribution
Die eigene On-Premise-Infrastruktur in Kombination mit einer OpenStack-Distribution ist ein bekanntes Szenario aus dem Linux-Umfeld -mit dem Unterschied, dass dieCloud-Charakteristik von OpenStack einen höheren Komplexitätsgrad mit sich bringt. In diesem Fall übernimmt der Nutzer alle Aufgaben, die ein Anbieter für ihn übernehmen würde. Dazu gehören die Auswahl der für OpenStack kompatiblen Hardwarekomponenten, deren Finanzierung sowie das Sizing, der Betrieb und die Wartung der gesamten Infrastruktur. Ebenso ist der Infrastruktur-Manager für die zukünftige Erweiterung der Infrastruktur mit Rechenleistung, Speicherplatz und Netzwerkkapazitäten verantwortlich
Der Einsatz einer professionellen Distribution verringert den Aufwand für den Betrieb der OpenStack-Umgebung. Die Distribution kapselt die wichtigsten OpenStack-Funktionen wie Compute, Storage und Networking und integriert alles, um eine einfache Installation zu ermöglichen. Der Nutzer muss sich somit nicht mit dem OpenStack-Quellcode auseinandersetzen und kann sich vollständig auf die Einrichtung der OpenStack-Infrastruktur konzentrieren. Trotz dieser Vereinfachung muss sich der Anwender für den Betrieb der OpenStack-Umgebung verantwortlich zeigen und selbst für eine Lösung sorgen, wenn mal etwas knirscht.
Dies passiert vorwiegend im Zusammenspiel von physikalischer Infrastruktur und OpenStack. Ferner darf nicht vernachlässigt werden, dass die Distribution nur für eine Grundinstallation sorgt und die individuelle Feinabstimmung und der Aufbau der OpenStack-Infrastruktur weiterhin im Aufgabenbereich des Nutzers liegt. Zur Private Cloud (IaaS) und dem Self-Service Portal kann es immer noch ein weiter Weg sein.
OpenStack als Do it Yourself
Beim Do-it-yourself-Ansatz (DIY) agiert die IT-Abteilung als interner Full Service Provider. Sie ist somit für den Aufbau und die Wartung der gesamten Infrastruktur und ihrer Komponenten zuständig. Hierzu gehören unter anderem die Auswahl und der Einkauf der geeigneten Hardware für die OpenStack-Umgebung sowie das richtige und zukunftsorientierte Sizing der Infrastruktur.
Neben der Verantwortung für den physikalischen Unterbau setzt der Infrastruktur-Manager im DIY-Modus auf OpenStack aus dem sogenannten "Trunk". Hierbei nutzt er den Quellcode des OpenStack-Projekts, um sich seine individuelle OpenStack-Version zu entwickeln. Mit einem OpenStack-DIY behält der Anwender die für ihn maximal mögliche Flexibilität und kann die OpenStack-Umgebung exakt an die individuellen Bedürfnisse anpassen. Das bietet Vorteile, wenn etwa selbstentwickelte Applikationen betrieben werden sollen, die sehr infrastrukturnah entwickelt sind.
OpenStack Deployment-Varianten: die Qual der Wahl
Welche Variante der OpenStack-Nutzung sich am besten eignet, hängt von unterschiedlichen Faktoren in Bezug auf die Unternehmensgröße und des Unternehmenstyps ab. Den größten Einflussfaktor für oder gegen eine der genannten Nutzungsvarianten stellt die vorhandene Expertise innerhalb der IT- Organisation dar. Das Wissen rund um OpenStack ist eine wertvolle Ressource und derzeit nur schwer am Markt zu finden. Ähnlich verhält es sich mit dem notwendigen Wissen, um skalierbare Cloud-Infrastrukturen und Cloud-fähige Applikationen zu entwickeln. Dieses Skillset ist - unabhängig von OpenStack - ein entscheidender Faktor, um eine Digital Infrastructure Platform (DIP) erfolgreich zu betreiben.
Der vollständige OpenStack-DIY-Ansatz sollte nur absoluten OpenStack- und Cloud-Profis beziehungsweise großen Cloud Service Providern (CSP), Telekommunikationsanbietern oder je nach Skillset Enterprise IT-Abteilungen vorbehalten bleiben. Von diesen ist zu erwarten, dass sie über die notwendigen Mitarbeiterressourcen verfügen, um skalierbare Cloud-Infrastrukturen und OpenStack- Umgebungen maßgeschneidert aufzubauen.
Als Technologie-Unternehmen können CSPs und Telkos zudem anhand eines sehr individuellen Ansatzes (DIY) einen Wettbewerbsvorteil auf Technologie-, Infrastruktur- und OpenStack-Ebene erzielen, um sich damit von anderen Marktteilnehmern zu differenzieren und von neuen OpenStack-Funktionen zu profitieren. Allerdings gleicht der DIY-Ansatz einer Kamikaze-Mission. Die Integration der einzelnen Projekte sowie die Selbstverantwortung für Wartung, Updates und Upgrades der OpenStack-Version sorgen für eine nicht kalkulierbare Komplexität. Gleichzeitig erhöht sich das Gesamtrisiko für den IT-Infrastrukturbetrieb und dessen Management.
Eine weitere bedrohliche Variable ist das notwendige OpenStack-Wissen. OpenStack-Experten sind weiterhin rar gesät. Geeignete Mitarbeiter zu rekrutieren wird somit zu einer Herausforderung. Gleichzeitig kostet der Wissensaufbau und die Schulung vorhandener Mitarbeiter Zeit, Ressourcen und Kapital.
Startups und Entwickler besitzen, je nach technologischem Hintergrund, das notwendige Cloud- und OpenStack-Know-How. Allerdings verfügen sie meistens nicht über die finanziellen Ressourcen zur Sicherstellung der entsprechenden physikalischen Infrastruktur, die für eine massiv-skalierbare Cloud-Umgebung notwendig ist. Für sie kommt dann primär eine OpenStack-ready Infrastructure in Frage, wenn eine OpenStack-DIY-Version einen technologischen Vorsprung ermöglicht.
Für weniger technisch versierte Startups kommt eine Managed-OpenStack-Infrastruktur in Frage, um sich auf das Kerngeschäft konzentrieren zu können. Ähnlich verhält es sich mit der IT-Abteilung eines mittelständischen Unternehmens. Auch wenn hier in manchen Fällen Kapital für die Infrastrukturkomponenten vorhanden ist, sollte stets abhängig von den Personalgegebenheiten und dem verfügbaren Wissen entschieden werden. Auch hier gilt, dass eine Managed OpenStack-Infrastruktur-Variante direkt einen Nutzen bringt, da sich die IT-Abteilung hierbei nur auf die virtuelle Infrastruktur, respektive die darauf betriebenen Anwendungen kümmern muss.
Große Enterprise IT-Abteilungen haben über die letzten Jahrzehnte hinweg genug Erfahrungen gesammelt und sind in den meisten Fällen auf das Design und den Betrieb massiv-skalierbarer Cloud-Infrastrukturen vorbereitet. Zudem benötigen manche zum Teil mehr Individualität und betreiben mehrere Clouds, entweder unabhängig für unterschiedliche Staging-Stufen (Entwicklung, Test, Produktion) oder sie haben diese miteinander integriert.
Ein vollständiger DIY-Ansatz kommt hier ebenso in Frage wie die Nutzung einer OpenStack-ready Infrastructure oder der Einsatz einer eigenen Infrastruktur mit OpenStack-Distribution. Auf Grund des Betriebs mehrerer Clouds bietet sich auch ein Multi-Cloud-Szenario an, bei dem die unterschiedlichen Varianten miteinander kombiniert werden. Beispielsweise ließe sich eine Entwicklung- und Test-Cloud auf Basis von OpenStack idealerweise innerhalb einer Managed OpenStack-Umgebung betreiben und eine produktive Cloud-Umgebung innerhalb eines DIY oder OpenStack-ready Infrastructure-Ansatzes.
OpenStack-Infrastruktur: Distributionen gehören auf die Agenda
Bevor sich Infrastruktur-Manager auf ihre OpenStack-Reise begeben, sollten sie sich die Frage "Eigenbetrieb vs. Managed OpenStack" stellen. Hierbei steht die Risikoaffinität im Vordergrund. Wie viel Komplexität soll intern verwaltet werden? Welche Bedeutung hat der Aufbau einer standardkonformen OpenStack-Umgebung? Solange OpenStack-Kenntnisse als knappes und relativ kostenintensives Gut gelten, handelt es sich bei dieser Diskussion auch um eine Kostenfrage. Die Entwicklung und Wartung einer eigenen OpenStack-Version kann sehr leicht zu einem teuren und unkalkulierbaren Abenteuer werden. Aus Perspektive von Crisp Research sollten sich Infrastruktur-Manager in Zukunft auf die Evaluation und den Einsatz einer standardisierten und professionell unterstützten OpenStack-Distribution konzentrieren.
Der Verzicht auf den Betrieb einer eigenen physikalischen Infrastruktur ist hierbei zudem ein smarter Schachzug. Denn die Auswahl, der Kauf und das Lifecycle Management von Hardwarekomponenten sind schon lange kein Differenzierungsmerkmal mehr. Eine Managed OpenStack-Variante auf einer gehosteten Infrastruktur sorgt für einen direkten Nutzen. Zudem befähigt es die Unternehmens-IT, sich auf die wesentlichen Themen zu konzentrieren und das fehlende OpenStack-Wissen zu kompensieren. (wh)