Versteckten Kosten an den Kragen gehen: Neue Technologien machen Multicloud wirtschaftlicher

Die Nutzung von Public-Cloud-Services gilt mittlerweile in den meisten Organisationen als selbstverständlich, und Unternehmen, die sich dieser Technologie verweigern, werden als rückständig, langsam oder zu vorsichtig betrachtet. In der Regel geht man davon aus, dass sie geschäftliche Chancen verpassen und auf die Dauer Wettbewerbsnachteile erleiden werden.

Die meisten Unternehmen entscheiden sich hinsichtlich ihrer Infrastruktur heute für eine hybride Cloud: Sie kombinieren IT-Services, die innerhalb des Unternehmens erbracht werden, mit solchen, die aus der Public Cloud kommen. Eine Weiterentwicklung dieser Architektur ist die Kombination intern erbrachter Services mit Diensten aus unterschiedlichen Public Clouds, die sogenannte Multicloud.

Bei Multiclouds geht es vor allem darum, zwischen unterschiedlichen Cloud-Lieferanten für dieselben Services, beispielsweise Object Storage, wählen und umschalten zu können. Wenn ein Unternehmen die Bezugsquelle eines solchen Dienstes frei wählen kann, lassen sich eventuell ökonomische oder Flexibilitätsvorteile realisieren. Hybride Clouds dagegen zielen vor allem darauf, spezielle, beispielsweise branchenspezifische Applikationen auf Basis der eigenen Infrastruktur zu realisieren, während eher unspezifische Services aus einer Public Cloud bezogen werden. Mit anderen Worten: In diesem Kontext geht es eher um vertikale Integration, bei Multiclouds auch um horizontale.

iele Kostenfaktoren der Public Cloud sind nicht sofort sichtbar

Innerhalb von Cloud-Umgebungen bleiben Anwendungen aber häufig auch in hybriden Umgebungen nicht am selben Ort. Oft wechseln sie im Lauf ihrer Existenz von einer Test- und Entwicklungsphase in der Public Cloud in eine Private Cloud oder sogar in eine dedizierte Umgebung. Das kann mehrere Gründe haben, darunter Sicherheit und Vertraulichkeit der Daten, aber vor allem die Kosten. Denn bei ständig benötigten Applikationen mit vielen Server-, Storage oder sonstigen Ressourceninstanzen, die als IaaS bezogen werden, können die Infrastrukturkosten der Cloud am Ende recht teuer werden. Dazu kommen die gar nicht mehr benötigten Public-Cloud-Ressourcen, etwa Serverinstanzen, die einfach deshalb nicht gelöscht werden, weil es kein ausreichend ausgefeiltes Ressourcenmanagement gibt.

Auch die Schatten-IT trägt zu den versteckten Kosten der Public-Cloud-Services bei. Sie ist weit verbreitet und entsteht, wenn Fachabteilungen unautorisiert durch die zentrale IT Public-Cloud-Services von Providern beanspruchen, die ihrem individuellen Bedarf am besten entsprechen. Solche Ressourcen passen aber architektonisch oder hinsichtlich des Managements möglicherweise nicht zur offiziellen Cloud-Strategie, die sich wahrscheinlich auf einige wenige Cloud-Anbieter fokussiert. Deren Kosten werden aber von der zentralen IT nicht einkalkuliert.

Natürlich bezweifelt niemand heute mehr ernsthaft die Sinnhaftigkeit des Public-Cloud-Einsatzes dort, wo diese Technologie passt, beispielsweise für Anwendungen auf der Kundenseite. Dort erhalten die Kunden einer Organisation über entsprechende Cloud-Apps erheblich schnelleren Zugriff auf Informationen, und die schnelle Entwicklung mittels auf Cloud-native zugeschnittenen DevOps-Methoden sorgt dafür, dass Organisationen blitzschnell auf neue Marktentwicklungen reagieren oder neue Funktionen ausprobieren können. Denn Entwicklungszyklen dauern nicht mehr Monate oder Jahre, sondern nur noch Tage oder Wochen, und oft wird in Umgebungen getestet, die der Betriebsumgebung aufs Haar gleichen (Blue/Green-Umgebung).

Doch auch DevOps hat in hybriden und Multicloud-Umgebungen seine Tücken. So ist die Migration einer für die und auf der Public Cloud entwickelten Applikation auf eine private Instanz möglicherweise sehr kompliziert. Denn Cloud-native-Apps bilden aufgrund der Natur der Cloud-Stacks die diversen Infrastrukturschichten im Build-Code ab. In der privat genutzten Umgebung ist das nicht nötig. Die bislang für die Codierung zuständigen Softwarespezialisten wissen oft gar nicht, wie sie Infrastructure as Code realisieren sollen, sie sind dafür schlicht nicht ausgebildet. Und die Infrastrukturspezialisten wissen nicht, wie sie Infrastrukturimplementierungen in den Code von Cloud-native Apps gießen sollen. Hier sind also Investitionen in Weiterbildung erforderlich, oder es entsteht neuer Aufwand, wenn eine Applikation migriert werden muss.
Denn mitnichten sind alle großen Public Clouds hinsichtlich ihrer Protokollarchitekturen gleich.

Protokollumgebungen, Managementumgebungen und funktionale Details unterscheiden sich, zudem erfordert das Abziehen von Daten aus einer Cloud-Umgebung unter Umständen manuelle Prozeduren wie das physische Versenden von Speichereinheiten, weil die verfügbaren Bandbreiten für die vorhandenen Datenmassen schlicht nicht ausreichen und den Migrationsvorgang zu sehr in die Länge ziehen oder zu kostspielig machen würden. Applikationen müssen deshalb häufig stärker verändert werden, wenn sie von Public-Cloud-DevOps-Umgebungen in interne Umgebungen umziehen.

Das gilt auch und sogar besonders für Applikationen, deren Konzeption vorsieht, Services aus mehreren Public Clouds miteinander zu kombinieren, um eine bestimmte Funktionalität zu realisieren. Beispielsweise könnte eine Applikation Serverless Compute-Services aus der einen Cloud nutzen, weil dieser Service dort bestimmte Funktionen aufweist, und Storageservices aus einer anderen Public Cloud, weil dort spezielle Optionen angeboten werden, welche die Organisation braucht. Sind hier die Dienste und ihre Schnittstellen nicht aufeinander abgestimmt, kann ein solches Vorhaben extrem komplex werden oder sich gar in der Praxis als unmöglich herausstellen.

Besonders augenfällig wird dieses Problem in Edge-to-Cloud-Umgebungen, die per se Rechenzentren auf mehreren Zentralisierungsebenen einbeziehen. Denn in den aufkommenden Edge-Infrastrukturen spielt Lokalität eine große Rolle. In den Core-to-Edge-Architekturen des heraufdämmernden IoT- (Internet of Things)-Zeitalters, etwa in Smart-City- oder Smart-Grid-Szenarien, hängt eine einwandfreie Funktion davon ab, dass Rechenressourcen und analytische Kapazitäten im näheren Umfeld der Datenquelle zur Verfügung stehen. Das heißt, entweder muss man einen Public-Cloud-Provider finden, dessen Serviceangebot sowohl architektonisch als auch funktional und wirtschaftlich in die geplante IoT-Umgebung passt, oder aber es bleibt gar nichts anderes übrig, als Edge-nah eigene Ressourcen aufzubauen.

Auch auf der Personalseite zeigen sich negative Auswirkungen der Inkompatibilitäten. Die Administratoren sind es gewohnt, für einen oder sehr wenige Anbieter immer mehr Zertifizierungen zu erwerben und zielen darauf, am Ende zum Spezialisten für diese Plattform mit dadurch steigendem Marktwert zu werden.
Organisationen aber brauchen in einer Multicloud-Welt vor allem Multicloud-Spezialisten. Sie müssen die Technologie und die Funktionen einer einzelnen Cloud vielleicht nicht ganz so genau kennen. Dafür müssen sie aber wissen, worauf es ankommt, wenn man Clouds in Hinblick auf den Nutzen für die Zwecke der eigenen Organisation vergleicht. Sie müssen herausfinden, wo ein Workload im gegebenen Moment am besten läuft und welche Kriterien dafür entscheidend sind, eine Platzierungsentscheidung zu ändern. Sie müssen wissen, wie man Applikationen möglichst reibungslos, schnell und kostengünstig migriert, und entsprechende Tools kennen, ihre Beschaffung motivieren und den Umgang damit erlernen und perfektionieren. Das gibt es heute sehr selten. Zudem kommen die entsprechenden Technologien gerade erst auf den Markt.

Neue Hard- und Softwareinvestitionen für die Public-Cloud-Nutzung?

Die Folgen dieser Situation sind teilweise absurd. So investieren Anwender sogar in spezielle Hard- und Software auf der privaten Seite ihrer hybriden Infrastruktur. So wollen sie die interne IT-Infrastruktur an das Angebot des gewählten Public-Cloud-Anbieters anpassen, um möglichst einfach Applikationen von der privaten auf die öffentliche Seite und umgekehrt migrieren zu können. Das ist besonders dann naheliegend, wenn ein Unternehmen schon viele Dienste eines bestimmten Anbieters nutzt, Personalressourcen und Know-how mit Bezug zu diesem Anbieter aufgebaut hat oder hinsichtlich der Abwicklung seines Kerngeschäftes vital von den Ressourcen dieses Cloud-Anbieters abhängt, mit anderen Worten: Wenn ein Unternehmen gar nicht mehr ohne große wirtschaftliche Risiken zu einem neuen Cloud-Provider wechseln könnte.

Durch solche Konstellationen kehrt sich die eigentlich mit der Public-Cloud-Nutzung angestrebte Situation geradezu um: Public-Cloud-Ressourcen sind ja eigentlich als Ablösung oder – häufiger – Ergänzung von On-Premises-Infrastrukturen gedacht, als eine Chance, teure Investitionen in eigene Hard- und Software durch flexible nutzungsbezogene Kosten zu ersetzen.

Hybrid- und Multicloud-Infrastrukturen können sich also bei näherem Hinsehen unter den heute üblichen technischen Umständen komplizierter und ökonomisch komplexer darstellen, als viele Anwender anfangs erwarten.

Eine Middleware für Multicloud

Einen großen Teil der skizzierten Probleme, die den Aufbau kosteneffizienter und offener Hybrid- und Multicloud-Umgebungen erschweren, könnten neue Technologien bewältigen. Nötig wären eigentlich allseits offene und möglichst standardisierte Schnittstellen der Provider, sich aneinander angleichende Protokollarchitekturen oder Emulationsmechanismen und umfassende Managementfunktionen für die Multicloud. Doch darauf zu warten, bis die dominanten, im scharfen Wettbewerb miteinander stehenden Anbieter sich hier umfassend einigen, sprengt wohl den Zeitrahmen der meisten Firmen.

Sinnvoll ist daher eine providerneutrale Softwareschicht, die in alle Richtungen die nötige Offenheit bietet und sich wie ein Puffer zwischen die unterschiedlichen in einer Infrastruktur vereinigten Clouds und aufgelagerte Apps oder Services schiebt. Über diese Schicht sollten Applikationen schnell, möglichst weitgehend automatisiert und günstig installiert und zwischen diversen Serviceanbietern verschoben werden können, wie es die individuelle Situation des Anwenderunternehmens sowie die sich stetig verändernden Angebote der Cloud-Provider nahelegen. Eine solche Managementsoftware sollte alle verfügbaren Clouds, alle genutzten Apps und Dienste sowie sämtliche verwendeten Ressourcen und ihre Kosten kennen und auflisten. Ideal ist es, wenn sie über einen App-Store ermöglicht, mit einem oder sehr wenigen Klicks Applikationen oder Ressourcen am gewünschten Ort hoch- und wieder herunterzufahren, zu verschieben, ihre Sicherheit, Compliance oder andere wichtige Funktionen zu überwachen und ihre Kosten zu kontrollieren. Dabei muss dieser Store sowie die gesamte Softwareschicht, die ihn mit umfasst, auf jeden Fall vollständig unabhängig von den Infrastrukturen der einzelnen Cloud-Anbieter sein, gleichwohl aber in der Lage, sich mit jeder von ihnen über Schnittstellen zu verbinden.

Eine solche Softwareschicht ist beispielsweise Nutanix CALM. Nutanix hat den Startup CALM, der eine Control-Plane auf der Applikationsebene für Multicloud-Umgebungen entwickelt hat, im Jahr 2016 aufgekauft. CALM arbeitet komplett providerneutral und ermöglicht die schnelle Bereitstellung und Migration von Applikationen auf die gewünschte Infrastruktur. Aus einem App-Store lassen sich alle verfügbaren Apps und Services mit einem Klick installieren. Zudem liefert CALM Funktionen wie Kontinuität, Compliance, Kostenkontrolle und vieles mehr. Letztlich verwaltet die Lösung den gesamten Lebenszyklus von Apps. Damit verliert das App-Lifecycle-Management in Multicloud-Umgebungen viel von seiner Komplexität. CALM, das sich unabhängig von anderen Nutanix-Produkten implementieren lässt, legt damit das Fundament für ein erfolgreiches Multicloud-Management, wie es die IT-Infrastruktur der meisten Unternehmen in Zukunft prägen wird.