On-Premise / Off-Premise oder Hauptsache Cloud?
Bei der Entscheidung für den optimalen Betrieb der eigenen IT sollten nicht nur die Cloud-Spielarten genau geprüft werden sondern auch ein Requirement-Engineering ist wichtig. Wir leisten dabei Hilfestellung, die richtigen Aspekte zu finden.
Save to Folio
Es gibt vielfältige Möglichkeiten eine Cloud aufzusetzen und zu betreiben. Anwenderunternehmen können zwischen dem Einsatz einer On-Premise-Lösung oder verschiedenen Tonarten von Private Clouds sowie der Nutzung einer oder mehrerer Public Clouds wählen. Allerdings gilt es, bei der eigenen Strategie, nicht nur die Cloud-Spielarten genau zu prüfen sondern auch ein eigenes Requirement-Engineering zu betreiben.
Private Clouds - selbst gebaut, selbst betrieben, wenig genutzt
Private Clouds gehören zu einem Trend, der anscheinend mehr und mehr aus der Mode kommt. Man beschafft sich die notwendigen Zutaten in Form von Hard- und Software, modelliert ein Prozess- und Portfolio-Management sowie ein Service Lifecycle Framework und startet mit dem Aufbau einer Private Cloud. Allzu häufig werden zu Beginn solcher Projekte nur die Technologen eines Unternehmens mit diesem Ziel beauftragt, und die Ergebnisse sind aus technischer Sicht „hübsch“ anzusehen, bringen aber trotz hoher zeitlicher und finanzieller Investments keinen direkten Mehrwert für das Geschäft. Die IT hat also die Gelegenheit genutzt, sich selbst weiter zu optimieren und nervige Prozesse zu automatisieren. Doch ob dies die Erwartungshaltung des Geschäfts war, ist fraglich. „Stellt euch vor, ihr baut eine Cloud und keiner will hin.“ Diese Art der Plattformprojekte sieht man im privaten und auch im öffentlichen Sektor immer wieder.
Die „Fehler“ lassen sich mit einem breiter angelegten Projekt mit Marketing der Lösung und viel Requirement-Engineering auch außerhalb der Technologieabteilung vermeiden. So haben Kunden erfahrungsgemäß schließlich ihre Umgebungen tatsächlich genutzt, auch wenn es ein harter Weg dahin war.
Immerhin helfen die vorhandenen Technologien dabei, diese Clouds deutlich schneller aufzubauen. Bei der Auswahl des Herstellers und der Produkte gilt es aber, immer gezielt nach dem eigenen Bedarf zu schauen. In punkto Betreibbarkeit ist bei voller Lizensierung sicherlich kaum mehr eine Grenze gesetzt. Die Kosten explodieren aber. Automatisieren und VMs in schönen Portalen bereitstellen können eigentlich auch alle. Mandantenfähigkeit? Ein Punkt, den man betrachten muss. Häufig wird dies sogar ein A-Kriterium, obwohl in der Produktion gar nicht benötigt... Interessanter wird es aber bei den Betrachtungen zur Skalierungs-, Business-Continuity / Disaster-Recovery-Fähigkeit, denn hier gibt es essenzielle Unterschiede in den Angeboten. Auch die Kompatibilität zur heutigen IST-Umgebung muss überprüft werden. Kann man beispielsweise bestehende VMware Cluster einbinden? Wie bringe ich dann die VMs in die Cloud-Verwaltung? Wie mache ich aus VMs entsprechende Services, deren Lifecycle durch den Endbenutzer gemanaged werden kann?
Häufig stellt ein Re-Deployment den besten Weg dar, ist aber ein großer Zeitaufwand dafür, dass das es keinen spürbaren Vorher-Nachher-Effekt für den betroffenen Business User gibt (außer der Service-Downtime im Migrationsfenster).
Private Clouds – eingekauft, fremd betrieben, Pay-per-Use
Ein modernerer Trend kommt von den „The cloud, that comes to you“-Geschichten der Hersteller. Zwei große Pluspunkte dieser Variante sind die kurze Time-to-Value, da der künftige Betreiber seine standardisierte Lösung mitbringt und aufbaut, sowie die Pay-per-Use-Regelung. Mit einer kapazitätsbasierten Abrechnung können Endkunden in ihrem eigenen Tempo in die Lösung hineinwachsen. Die Großzügigkeit der Anbieter hält sich in Grenzen und somit wird ein hoher Commit- / Reservation-Level belohnt. Das heißt, auch die Technologieanbieter können unbezahlte Hardware als Puffer nur bedingt auf eigene Kosten bei ihren Kunden „parken“. Ein Großteil der Plattform soll also ohnehin finanziert werden, damit sich das Modell dieser Private Clouds auch für beide Seiten rentiert.
Damit wird aber wieder nur das technologische Problem gelöst. Sie sind als IT schneller und effizienter. Die Mehrwerte für das Business gilt es also noch zu identifizieren und dann zu heben. Glücklicherweise wird durch einen Managed-Service für diese Umgebung auch Zeit frei, die nicht in den Betrieb der Plattform, sondern eben in solche Aktivitäten fliessen kann. Migration von Altumgebungen auf die neue Plattform, Enablement und Onboarding von Fachabteilungen, internes Marketing und Change-Management sind nur ein paar Vorschläge dafür, wie sie diese freie Zeit einsetzen können.
Eine Empfehlung für beide Arten von Private Clouds: Rationalisieren und Standardisieren, wo immer es geht. Nicht wenige große Unternehmen haben über die Zeit mehr als einmal eine neue Private Cloud aufgebaut, immer mit dem Anspruch, dass die neue Lösung die alten Projekte ablösen und Private Cloud und Datacenter standardisieren und effizienter gestaltet. Diese Unterfangen führen auch heute noch in immer wieder neue „Cloud, jetzt aber diesmal richtig!“-Projekte. Die alten Clouds vegetieren nebenher weiter, denn offenbar gibt es Anwendungen, die dann doch lieber dort ihr Dasein fristen sollen.
Public Clouds – Services von der Stange
Das wohl angesagteste Modell ist die Public Cloud. Aber welche? Sicher gibt es die bekannten Hyperscaler mit AWS, Azure und GCP, gefolgt von Alibaba – aber auch Hersteller-Clouds, wie die von SAP, IBM, Oracle und Co. Hinzu kommen die diversen deutschen Angebote führender lokaler Systemhäuser und Service-Provider, sowie Bestrebungen für lokale „datensouveräne“ Lösungen einer EU-Cloud und weitere Projekte für lokal betriebene Dependancen der Hyperscaler.
Die Auswahl ist hier sehr groß, so dass es gilt, klares Requirement-Engineering zu betreiben. Was ist wichtig, was ist Nice-to-Have? Neben Technologien gilt es auch das für uns geltende Recht zu betrachten, Datenklassifizierungen einzuhalten und klare Anforderungen an Business-Continuity / Disaster-Recovery Fähigkeiten, sowie Data-Retention Themen zu berücksichtigen. Wer sich nach dieser Auflistung im eigenen Rechenzentrum „sicher“ fühlt, sollte sich dennoch fragen, warum so viele Unternehmen nach außen drängen.
Stichwort ist und bleibt „Shared Responsibility Modelle”. Dabei lautet eine Empfehlung, auf Partnerschaften zu setzen und die Verantwortung dort abzugeben, wo es nicht um geschäftskritische Prozesse handelt.
Community Clouds – nur etwas für postmoderne Hippies?
Community Clouds sind eine tolle Idee: Universitäten teilen sich eine gleichberechtigte Forschungs-Cloud, oder alle Automobilhersteller nutzen in einer eigens für sie geschaffenen Cloud Datenbestände und Forschungsergebnisse für sicheres bzw. autonomes Fahren. Kommunen und Länder nutzen eine gemeinsame, sichere Bundes-Cloud, auf die alle zugreifen können und die sicher erstellt ist. So gut die Idee der Community Clouds ist, so wenig wird sie umgesetzt. Zu groß ist das Interesse einzelner Parteien in der „gleichberechtigten Community“ eine Stimme mehr zu haben, vielleicht eher ein gesellschaftlich-wirtschaftliches Problem.
Hybrid Clouds – der einzig wahre Weg?
Der wohl optimale Weg liegt heute darin, eine effiziente lokale IT zu gestalten unter dem Motto: „dort, wo notwendig“ und „so effizient, wie möglich“. Eine Public Clouds würde sich für die „dort wo möglich“-Herangehensweise anbieten. Härtefälle bleiben On-Premise, während das Unternehmen einen Hyperscaler und auch lokalen Cloud-Service-Provider nutzt, wann immer es der IT und dem Unternehmen hilft, effizienter und agiler zu werden, oder das zu schaffen, was dem jeweiligen Geschäft hilft.
Ein Phänomen, von dem man immer wieder hört, ist „Cloud Bursting“. Dann heißt es: „Zur Weihnachtszeit nehmen Sie einfach weitere Instanzen in der Public Cloud dazu, damit Sie die Last auf das Datacenter reduzieren.“ Aber wenn so ein System in der Public Cloud laufen kann und darf, dann soll es im Ganzen dorthin verschoben werden und dieser Footprint wird ganzjährig im eigenen Datacenter auf Null reduziert – so und nicht anders lebt man das 6-R Modell. Auch Nachhaltigkeit kann mal im Vordergrund stehen.
Multi-Cloud Management Plattformen – braucht man sie?
Hier kommt wieder das Schlagwort der letzten Jahre: Abstraction Layer. Wenn sich ein Unternehmen so viel IT angeschafft hat, dass es den Überblick verliert, kommt der Ruf nach einer zentrale Multi-Cloud Managementplattform. Verschiedene Hersteller versuchen sich immer wieder daran. Teilaspekte lassen sich sicher „Multi-Cloud-fähig“ abstrahieren. So gibt es mit Terraform eine gute Möglichkeit, das Deployment zu abstrahieren, oder auch mit Cloud One Conformity, der Multi-Cloud Lösung, die Konformität zu überprüfen. Dies sind aber Lösungen, die auf bestimmte Anwendungsfälle zutreffen.
Das Ziel beim Aufbau einer Multi-Cloud Management Plattform (CMP) ist eine Abstrahierung aller Portale, die man für den Konsum und das Management der Plattformen benötigt. Doch diese Abstrahierung zwangsläufig lückenhaft, denn man programmiert stets gegen die Entwicklungen der unterliegenden Plattformen, die sich in schnellen Zyklen immer mehr weiterentwickeln. Die Anbieter einer CMP haben immer einen „kleinsten gemeinsamen Nenner“ an Funktionen zuzüglich einiger Funktionen, die sie vom jeweiligen Wettbewerb anderer CMPs differenziert.
Fazit
Die Vielfalt an Möglichkeiten ist vorhanden, man muss sie nur nutzen. Daher lautet die Empfehlung, je Services zu entscheiden, ob sie ganzheitlich an einem Ort On- oder Off-Premise betrieben werden oder gar von einem Provider. Es muss kein ganzheitliches Outsourcing sein, aber wir müssen unsere Fertigungstiefe optimieren und Ressourcen effizient und nachhaltig einsetzen.