8 Minuten Lesezeit Mit Insights von Peter Bäck Principal Cloud Consultant peter.baeck@zuhlke.com Christian Tschenett Cloud Solutions Architect christian.tschenett@zuehlke.com Basierend auf unserer Erfahrung beim Thema Cloud Transformation befassen wir uns in diesem Artikel zunächst damit, was eine Multi-Cloud eigentlich ist, warum viele Unternehmen zu glauben scheinen, bereits über eine Multi-Cloud-Umgebung zu verfügen, und wie es dazu kam. Danach nehmen wir den Hype genauer unter die Lupe und widmen uns der Frage, wer das Hohelied auf die Multi-Cloud anstimmt. Anschließend untersuchen wir das Konzept der Cloud-Anbieterbindung und diskutieren, inwieweit es sich tatsächlich lohnt, anbieterunabhängig zu werden. Den Abschluss bildet die Frage, ob eine Multi-Cloud für die Business Continuity die beste Lösung oder überhaupt notwendig ist. Alle nutzen heute eine Multi-Cloud, also muss das doch richtig sein, oder? Wahrscheinlich ist Ihnen schon einmal die viel zitierte Statistik begegnet, wonach 87 % der Unternehmen bereits Multi-Cloud-Umgebungen nutzen. Diese Zahl dient oft als Begründung für den Umstieg auf eine solche Umgebung – schließlich kann ja nicht falsch sein, was so viele andere längst praktizieren. Doch was ist unter einer Multi-Cloud eigentlich zu verstehen? Viele Unternehmen bejahen die Frage, ob sie mehrere Clouds verwenden, weil sie beispielsweise mit einem Public-Cloud-Hyperscaler zusammenarbeiten und daneben ein oder zwei weitere Software-as-a-Service-Angebote (SaaS) wie Microsoft O365 oder Salesforce Cloud nutzen. Das ist zwar nicht falsch, aber nicht die Art von Multi-Cloud, die wir hier beleuchten wollen. Uns interessieren vielmehr Szenarien, in denen mehrere Public Clouds für Infrastructure-as-a-Service (IaaS) oder Platform-as-a-Service (PaaS) verwendet werden. Diese Szenarien wollen wir untersuchen, um die Gründe zu verstehen, die Unternehmen zu solchen Ansätzen bewegen. Außerdem wägen wir ab, was dafür oder dagegen spricht. Welche Multi-Cloud-Ansätze nutzen Unternehmen? Kehren wir noch einmal kurz zurück zu der oben genannten Zahl von 87 %: Wie wir gesehen haben, wird sie als Rechtfertigung für Multi-Cloud-Strategien herangezogen, doch dem liegt oft die stillschweigende Annahme zugrunde, dass sich all diese Unternehmen aus wohl durchdachten, strategischen Überlegungen heraus für die Multi-Cloud entschieden haben. Aber wie realistisch ist diese Annahme verglichen mit allen anderen möglichen Szenarien, in denen ein Unternehmen seine Workloads auf mehrere Public Clouds verteilt hat? Unserer Erfahrung nach werden solche Entscheidungen in der Praxis vielfach nicht aufgrund einer klugen übergeordneten Strategie getroffen, sondern haben sich aus verschiedensten Gründen einfach so ergeben. So kommt es beispielsweise vor, dass ein Unternehmen A ein Unternehmen B übernimmt und mit ihm dessen Public-Cloud-Umgebung. Der Aufwand, sämtliche Workloads von Unternehmen B in die Cloud von Unternehmen A zu migrieren, ist jedoch zu groß, da es laufende Verträge, eingespielte Teams usw. gibt. Kurzum, die Investition für eine Homogenisierung der Cloud-Landschaft ist ungerechtfertigt oder nicht gewünscht. Ebenso haben wir beobachtet, dass Abteilungen großer Organisationen einfach ihr eigenes Süppchen kochen. In solchen Fällen mag es zwar eine zentrale IT geben, die eine bestimmte Public Cloud vorgibt, aber eine Abteilung, die ihre IT-Landschaft selbst verwaltet, hat sich vielleicht von ihrem Anbieter zu einer anderen Lösung überreden lassen. Falls also wieder einmal jemand die besagten 87 % für eine Multi-Cloud-Lösung ins Feld führt, sollten Sie kritisch hinterfragen, warum dieser Jemand Sie von dieser Lösung überzeugen möchte. Und damit leiten wir zum nächsten Thema über: Wer bestimmt das Multi-Cloud-Narrativ? Das Multi-Cloud-Narrativ: Fakten und Fiktion Das Narrativ rund um die Multi-Cloud grenzt mitunter fast an Propaganda, die das Publikum zu einer bestimmten Sichtweise verführen will. Aber wer verbreitet eigentlich dieses Narrativ und warum? In seinem sehr unterhaltsamen Artikel „Multi-cloud is the Worst Practice“ (etwa: „Multi-Cloud ist das Schlimmste, was man tun kann“) beschreibt Corey Quinn zwei Arten von Multi-Cloud-Fürsprechern: Angeschlagene Anbieter, denen klar ist, dass sie nur weiterhin etwas verkaufen können, wenn Unternehmen auf Multi-Cloud umsteigen „Nischenanbieter“, also im Grunde jeder, der nicht zum Dreigestirn der Cloud-Provider (AWS, Azure, GCP) gehört Corey Quinns Artikel hält übrigens noch viele weitere interessante Einblicke parat, weshalb wir Ihnen die Lektüre wärmstens empfehlen. Das Multi-Cloud-Narrativ stützt sich auf ganz unterschiedliche Argumente: Manche davon entpuppen sich bei näherem Hinsehen als Strohfeuer, andere hüllen sich in begriffliche Nebelwolken. Nehmen wir ein Beispiel für Letzteres: Was verstehen Sie unter einer „cloud-nativen Anwendung“? Wahrscheinlich denken Sie jetzt, dass es sich um eine Anwendung handelt, die in jeder beliebigen Cloud ausgeführt werden kann. Vor fünf Jahren hätte dieselbe Frage aber wohl zu einer anderen – der richtigen – Antwort geführt, nämlich: Eine cloud-native Anwendung ist eine Anwendung, die für die intensive und vorteilhafte Nutzung cloud-nativer Managed Services entwickelt wurde. Wir überlassen es an dieser Stelle Ihrer Fantasie, wer aus welchen Gründen diese Bedeutungsverschiebung befördert hat. Ein weiteres Beispiel ist die sogenannte „Hybrid-Multi-Cloud“. Wenn Sie nach erfolgreichen Anwendungsfällen für die „Hybrid-Multi-Cloud“ googeln, stoßen Sie mehrheitlich auf Unternehmen, die mit der Automatisierungslösung eines Anbieters virtuelle Maschinen (VMs) von lokalen Hypervisors in eine Public Cloud verschoben haben. Wir haben es hier mit einem Szenario zu tun, in dem einige VMs lokal betrieben werden und andere in einer einzelnen Public Cloud – also ein Szenario, das seit einigen Jahren „Hybrid-Cloud“ heißt. Wann und wieso hat sich darin das Wort „Multi-“ eingeschlichen? Ein lokaler Hypervisor, der VMs ausführt, ist per Definition keine Cloud, folglich hat der Ausdruck „Multi-Cloud“ hier schlicht nichts verloren. Argumente, warum Unternehmen eine Multi-Cloud brauchen, gibt es also viele. Manche davon sind stichhaltiger als andere, und einige der gängigsten finden Sie unten – inklusive unserer Einschätzung dazu. Schon an dieser Stelle dürfte jedoch klar geworden sein, warum Sie Multi-Cloud-Versprechen immer kritisch hinterfragen sollten. Multi-Cloud-Strategie und Anbieterbindung: was wirklich dahintersteckt Viele Unternehmen setzen auf eine Multi-Cloud-Strategie, weil sie dem häufig genannten Argument trauen, mit einer Multi-Cloud-Umgebung ließe sich die feste Bindung (Vendor Lock-in) an einen Einzelanbieter umgehen. Wer die Services mehrerer großer Cloud-Provider nutzt, so das Versprechen, könne die Beschränkungen und Risiken der Anbieterbindung minimieren. Dahinter steckt oft die Sorge vor den Kosten und Betriebsunterbrechungen, die künftig mit einer Migration einhergehen könnten. Doch die Einführung einer Multi-Cloud-Strategie bringt ganz eigene Schwierigkeiten und Kosten mit sich, weshalb einige den vermeintlichen Nutzen infrage stellen. Die führenden Cloud-Provider – AWS, GCP und Azure – bieten zwar ähnliche Dienstleistungen an, unterscheiden sich aber in Bezug auf Betrieb und Verwaltung, vor allem in Bereichen wie Automatisierung, Sicherheit sowie Identitäts- und Zugriffsmanagement. Um nicht von einem Anbieter allein abhängig zu sein, richten viele Unternehmen für jeden großen Cloud-Service Abstraktionsschichten ein. Diese Methode löst zwar das Problem der festen Anbieterbindung, verursacht jedoch erhebliche Kosten. Interessant ist in diesem Zusammenhang ein potenzieller Nebeneffekt: Die Einrichtung anbieterunabhängiger Workloads kann nämlich dazu führen, dass sich die spezialisierten Services der einzelnen Provider nicht mehr vollumfänglich nutzen lassen. Unternehmen hätten dann nur grundlegende Services zur Verfügung und müssten ständig neue Wege finden, die dadurch entstandenen Funktionslücken zu schließen. Dies wirft eine kritische Frage auf: Ist die Multi-Cloud mit all ihren Herausforderungen und Investitionskosten wirklich eine effektive Lösung, um Anbieterbindung zu vermeiden, oder ist sie ein Irrweg? Geht man dieser Frage genauer nach, stellt sich nicht selten heraus, dass der erwartete ROI nicht realisierbar ist – und schon steht der Multi-Cloud-Ansatz zur Disposition. Wer von einem großen Cloud-Anbieter auf einen anderen umsteigt, ist in puncto Kosten mitunter besser beraten, die Workloads in der Umstiegsphase umzustrukturieren oder eine neue Architektur einzurichten. Zusammenfassend lässt sich sagen, dass Multi-Cloud-Strategien Flexibilität und Risikominderung versprechen, bei näherer Betrachtung aber auch Komplexitäten und Herausforderungen mit sich bringen. Oft stellt sich sogar heraus, dass die vermeintliche Anbieterfreiheit mehr Schein als Sein ist. Wenn eine kurze Markteinführungszeit angestrebt wird, kann es sinnvoller sein, auf die Einrichtung komplexer Abstraktionsschichten zu verzichten und stattdessen Workloads schnell in eine andere Produktionsumgebung zu verschieben. Mehr darüber, warum Anbieterunabhängigkeit ein Trugschluss sein kann, erfahren Sie in diesem lesenswerten Artikel von Gregor Hohpe. Die Multi-Cloud-Strategie, die als Lösung für die Vermeidung von Anbieterabhängigkeit angepriesen wird, birgt Herausforderungen und Kosten, die möglicherweise ihre Wirksamkeit in Frage stellen. Multi-Cloud für die Business Continuity aus kritischer Perspektive Der Multi-Cloud-Ansatz wird deshalb so viel diskutiert, weil die strategische Vorbeugung potenzieller Risiken im Bereich des Cloud-Computings eine zentrale Anforderung ist. Dass ein großer Cloud-Anbieter wie AWS, GCP oder Azure sein Geschäft aufgibt, mag zwar unwahrscheinlich sein, stellt aber tatsächlich ein erhebliches Risiko mit potenziell weitreichenden Folgen dar. Für Unternehmen, die kritische Anwendungen in der Cloud ausführen, ist ein Notfallplan daher ratsam oder sogar gesetzlich vorgeschrieben. Für den Fall, dass der primäre Cloud-Anbieter ausfällt, fassen viele Unternehmen zwei Business-Continuity-Strategien ins Auge: Entweder wird auf einen lokalen Backup-Standort oder auf eine Backup-Cloud-Region eines anderen Providers zurückgegriffen. Die letztgenannte Option resultiert meist in einer Multi-Cloud-Umgebung, in der Workloads in Aktiv/Aktiv- oder Aktiv/Passiv-Bereitstellungen bei unterschiedlichen Providern betrieben werden. Dies setzt jedoch voraus, dass die Anwendungsarchitektur in beiden Umgebungen repliziert wird. Noch dazu ist die Nutzung anbieterspezifischer Services, die in der alternativen Cloud nicht verfügbar sind, praktisch ausgeschlossen. Trotz dieser Komplexitäten und der höheren Kosten, die das Nutzenversprechen der Cloud zum Teil relativieren, behaupten Multi-Cloud-Befürworter, dass die Vorteile überwiegen. Um diese Behauptung prüfen zu können, müssen wir einen Schritt zurückgehen. Die Annahme, ein Hyperscale-Cloud-Anbieter könnte urplötzlich den Betrieb einstellen und seine Rechenzentren stilllegen, ist irrig. Selbst bei Insolvenz, Übernahme oder behördlicher Zwangsschließung würde der Anbieter nicht von heute auf morgen vom Markt verschwinden, sondern einen jahrelangen Prozess, wahrscheinlich unter Interimsverwaltung, durchlaufen. Niemand würde eine Stilllegung erzwingen, wenn Kunden, die auf die entsprechenden Cloud-Infrastrukturen angewiesen sind, dadurch gewaltige Kollateralschäden erlitten. Außerdem gäbe es in solchen Fällen sehr wahrscheinlich Vorwarnzeichen, sodass Unternehmen reichlich Zeit hätten – eher Jahre als Wochen –, sich darauf einzustellen. Aus den genannten Gründen sind Aktiv/Aktiv- oder Aktiv/Passiv-Multi-Cloud-Bereitstellungen nicht die einzigen Lösungen, mit denen bei Ausfall eines großen Anbieters der Geschäftsbetrieb gesichert werden könnte. Tragfähiger wäre ein Providerwechsel, bei dem die bisherige Lösung noch eine gewisse Zeit in der ursprünglichen Cloud weiterbesteht. Wer sich besser auf den Eventualfall vorbereiten will, sollte unserer Ansicht nach voll auf Automatisierungs- und Infrastructure-as-Code-Lösungen setzen. Diese ermöglichen eine schnellere Anpassung und erleichtern die Migration in eine andere Cloud-Umgebung. Unser Fazit: Die Multi-Cloud ist weder die einzige noch die zwangsläufig beste Option zur Sicherstellung des Geschäftsbetriebs. Viele Alternativen sind sogar weniger komplex und erfordern weniger Anfangsinvestitionen. Auch die Kosten für die Migration im Ernstfall fallen gegenüber Multi-Cloud-Umgebungen vielfach geringer aus. Die wichtigste Empfehlung lautet daher, alles zu automatisieren, um agiler und resilienter zu werden. PS: Wenn Sie mehr aus Ihrer Cloud herausholen wollen, interessiert es Sie sicherlich, was unser Kollege Mark Venn in seinem Blogpost zum Thema Cloud-Optimierung geschrieben hat. Peter Bäck Principal Cloud Consultant Peter kam 2018 als erster Head Competence Unit in Singapur zu Zühlke, 2021 wechselte er in die Schweiz, um als Principal Business Consultant in die neu gegründete Cloud Practice Unit einzusteigen. Während seiner Zeit bei Sonoport und bei Kaplan Singapore verfügt er über umfangreiche Cloud-Erfahrung mit GCP und AWS. Peter hat einen MSc in Informatik von der Abo Academy University und blickt auf eine mehr als zwei Jahrzehnte lange Karriere als Software-Ingenieur zurück. Kontakt peter.baeck@zuhlke.com +41432166021 Schreiben Sie uns eine Nachricht You must have JavaScript enabled to use this form. Vorname Nachname E-Mail Telefonnummer Message Absenden Bitte dieses Feld leer lassen Schreiben Sie uns eine Nachricht Vielen Dank für Ihre Nachricht.
Industrie – Value Engineering: In drei Schritten zu tieferen Herstellkosten in der industriellen Fertigung Mehr erfahren