Ein Heilsversprechen der Cloud ist die Konsolidierung der IT-Landschaften in Unternehmen. Die Praxis zeigt aber, dass Unternehmen schnell für verschiedene Anwendungen unterschiedliche Clouds und deren spezifische APIs nutzen. Multi-Cloud-Landschaften entstehen manchmal absichtlich, oft aber ungeplant. Ohne Strategie und entsprechende Tools droht IT-Verantwortlichen mittelfristig ein ähnliches Konsolidierungschaos wie bei der klassischen IT.
Unter Multi-Cloud versteht man die parallele Nutzung mehrerer Cloud-Anbieter und Umgebungen also beispielsweise Azure, AWS, Rackspace, IBM Cloud, Google Cloud etc. Warum werden in Unternehmen verschiedene Cloud-Computing-Angebote genutzt?
Spontaner Wildwuchs. Das kann unterschiedliche Gründe haben. Ein für die IT-Verantwortlichen eher unerfreulicher Grund ist die sogenannte Schatten-IT. Hier preschen Führungskräfte einzelner Abteilungen und dezentrale Entwicklerteams vor, entwickeln ohne übergeordnete Plattformstrategie neue Cloud-Applikationen. Je nach vorhandenem Know-how im Entwicklerteam und ohne echten Auswahlprozess werden diese Applikationen dann auf verschiedenen Cloud-Plattformen implementiert. Das unternehmensweite Ergebnis ist das Nebeneinander von Applikationen in verschiedenen Clouds – also Multi-Cloud.
Dieser Schatten-IT im Bereich Cloud-Applikationen ist für die Verantwortlichen aktuell schwer zu begegnen. Cloud-Applikationen gelten als fortschrittlich, Abteilungen protzen gern mit ihnen. Jeder Cloud-erfahrene Entwickler wird in Zeiten des Fachkräftemangels gern genommen und man gesteht diesen bereitwillig die Auswahl der Plattform zu. Kritik der IT-Verantwortlichen an diesem Wildwuchs dringt zumindest anfangs nur schwer durch, denn für die Endanwender sieht das Ergebnis gleich aus.
Gerade vorhandene Cloud-Tools sind in den Abteilungen der Geschwindigkeit oft extrem zuträglich und »Wir wollen doch flexible Cloud-Lösungen – oder? Und wenn man dann mal proaktiv, flexibel und agil handelt, ist es den IT-Herren da oben schon wieder nicht recht.« Ungeduld und Cloud-Begeisterung haben so bereits in vielen Unternehmen Tatsachen geschaffen. Wie man gegebenenfalls den Anbieter wechseln kann oder seine Daten wieder aus der jeweiligen Cloud zurückholt, wurde bei diesen dezentralen Entscheidungen meist nicht durchdacht.
Geplante Redundanz. Eine Multi-Cloud-Umgebung kann aber auch das Ergebnis strategischer Entscheidungen sein. Unternehmen beauftragen ganz bewusst verschiedene Anbieter, um sich nicht von einem abhängig zu machen. Auch kann es sein, dass für einzelne Anforderungen oder Regionen eine bestimmte Cloud die bessere Lösung darstellt – so bilden sich bereits unterschiedliche Plattformen für Office-IT-Anwendungen und -Applikationen im Bereich Industrial Internet of Things aus.
Ob nun geplante und ungeplante Multi-Cloud, die Herausforderung für die IT-Verantwortlichen bleibt gleich: Unabhängigkeit und Flexibilität beim Betrieb der Cloud-Applikationen sind nur dann gegeben, wenn problemlos zwischen Anbieter und Plattformen gewechselt werden kann – beispielsweise um durch Redundanz die Verfügbarkeit zu erhöhen oder um regionale Stärken oder die Kostenunterschiede bei einzelnen Cloud-Anbietern effizient nutzen zu können.
Unterschiedliche APIs führen schnell zum Vendor-Lock-in. Aber Cloud ist eben nicht Cloud und der Teufel steckt auch bei softwaregetriebenen IT-Infrastrukturen im Detail. Wie der automatisierte Betrieb der Applikationen, wie die automatisierte Bereitstellung von Ressourcen und das Fehler- und Redundanzmanagement aussehen, das haben die Cloud-Anbieter in ihren APIs unterschiedlich – also proprietär – verankert und geregelt. Das Ergebnis: Schon kleine Unterschiede in der API können erhebliche Umstellungen in den Applikationen erforderlich machen und den Plattformwechsel zu einem aufwendigeren IT-Projekt machen. Auch parallele Entwicklungen für mehrere Cloud-Plattformen sind daher ohne Strategie und Tools nicht so einfach und so effizient zu machen. Erfahrene IT-Fachleute erinnern sich: Das klingt wie der Anfang der langen Konsolidierungslieder aus der klassischen IT – nur, dass Bare-Metal-Server durch Cloud-Plattformen ersetzt werden.
Die Frage ist also: Wie lässt sich professionell und effizient mit der Multi-Cloud umgehen?
Multi-Cloud-Managementsysteme? Eine erste Lösungsmöglichkeit sind Multi-Cloud-Managementsysteme, die von einigen Herstellern propagiert werden. Stark vereinfacht stellen diese Systeme eine weitere API zu Verfügung und interpretieren diese dann in die API der verschiedenen Zielplattformen (API-to-API). Das klingt aber nur anfangs wirklich befreiend, denn letztlich tauschen die Unternehmen die Abhängigkeit von den APIs der Cloud-Plattformen gegen die Abhängigkeit einer neuen API ohne einen leistungsbezogenen Mehrwert. Was passiert, wenn der Anbieter des Multi-Cloud-Managementsystems die Entwicklung einstellt? Wie reagiert man, wenn die vom Unternehmen präferierte Cloud-Plattform nicht (mehr) oder nur unzuverlässig und fehlerhaft unterstützt wird?
Kurzum: Der Einsatz eines Multi-Cloud-Managementsystems löst das Problem des Vendor-Lock-ins nicht wirklich, addiert sogar eine weitere proprietäre Ebene.
Die native Lösung: ab in den Container. Als Rechenzentrumsdienstleister, der selbst eine Cloud auf Basis von OpenStack betreibt und Unternehmen bei der schrittweisen Cloud-Migration mit der Pflege hybrider Konstellationen aus Cloud, Virtualisierungsplattformen wie beispielsweise VMware und physischen Systemen unterstützt, hat noris network intensiv alternative technische Optionen evaluiert.
Das Ergebnis: Unabhängigkeit von einzelnen Cloud-Computing-Systemen und -Anbietern lässt sich durch eine konsequente Containerisierung erreichen. Wer Multi-Cloud aus strategischen Erwägungen heraus pflegen oder eine ererbte Multi-Cloud-Situation in ein beherrschbares Gesamtkonzept überführen will, sollte Cloud-Applikationen in Container packen. Alle aktuellen Cloud-Plattformen unterstützen Container-Services, erlauben diese Form der Vereinheitlichung und Abstraktion. So lässt sich beispielsweise über Kubernetes die automatisierte Bereitstellung, Skalierung und Verwaltung der Container steuern. Die Orchestrierung der sogenannten »Pods«, das sind Arbeitsprozesse, die aus einem oder mehreren Containern inklusive Redundanz und Ressourcen bestehen, erfolgt im Rahmen eines Clusters aus beliebigen physischen oder virtuellen Maschinen (»Nodes«).
Der zentrale Einstiegspunkt für das Management von Kubernetes Clustern ist der API-Server. Hier sind alle Informationen zugreifbar, die nötig sind, damit interne und externe Dienste mit dem Kubernetes-Cluster kommunizieren können. Der Effekt: Dank des »Steuermannes« (griechisch: Kubernetes) ist es völlig gleichgültig, in welcher Umgebung die Prozesse laufen. Und es ist ohne weiteren Aufwand möglich, Hochverfügbarkeit zu erreichen, weil Kubernetes ausgefallene Nodes durch identische Nodes ersetzt. So erreicht die Abstraktion durch Kubernetes nicht nur eine Vereinheitlichung der Art wie Applikationen in einer Multi-Cloud-Umgebung technisch realisiert werden, sondern bekommt quasi »umsonst« auch noch eine größere Zuverlässigkeit, Fehlertoleranz und Hochverfügbarkeit als Zugabe.
In Container verpackte Cloud-Applikationen erlauben den Unternehmen, ihre Anwendungen auf verschiedenen Cloud-Plattformen – auch parallel – laufen zu lassen. Die Anpassung verlangt etwas Know-how, aber die damit geschaffenen Freiräume für die Multi-Cloud sind den Aufwand wert.
Dr. Thomas Fischer,
Principal IT Architect
bei noris network
www.noris.de
Illustration: © Mr Aesthetics /shutterstock.com
Top-Themen der Digitalwirtschaft 2018: IT-Sicherheit, Cloud Computing und Internet der Dinge