Diese drei gängigen Fehler können Ihr Multi-Cloud-Deployment nachhaltig sabotieren.
Diese drei Fehler führen Sie möglicherweise geradewegs in die Multi-Cloud-Hölle. Foto: IgorZh - shutterstock.com
Hier könnte eine Statistik stehen, die belegt, dass Multi-Cloud inzwischen das Gros der Cloud-Implementierung vereinnahmt. Das können Sie an anderer Stellen nachlesen - wir wissen schließlich alle, dass es für Unternehmen inzwischen einen gängigen Ansatz darstellt, auf mehrere Clouds - statt nur auf eine einzige - zu setzen.
Dennoch werden weiterhin Fehler gemacht, wenn es um Multi-Cloud-Implementierungen geht. Und die hängen weniger damit zusammen, dass komplexe Technologie falsch eingesetzt wird. Vielmehr sind sie Teil simpler, lange bekannter Probleme - die meiner Meinung nach in erster Linie einem Mangel an fundierter Erfahrung geschuldet sind.
Wir werfen einen Blick auf die drei häufigsten Fehler, die Sie potenziell in die Multi-Cloud-(Deployment)-Hölle führen können.
1. Unzureichend planen
Mit dem Aufkommen von Supercloud und Metacloud sollte eigentlich klar sein, dass es ein ungünstiger Fehler ist, auf gemeinsam genutzte und logisch zusammengestellte Public-Cloud-Services zu verzichten. Der kostet Unternehmen regelmäßig Millionen.
Wenn Sie eine Multi-Cloud-Architektur planen, aufbauen und implementieren wollen, brauchen Sie einen von den Cloud-Anbietern unabhängigen Layer mit gängigen Cloud-Services (wie etwa Security, Finops, Observability). Ein natives Tool zu nutzen, das nur mit einem einzigen Cloud-Anbieter funktioniert, würde viel zu viel Redundanz, Heterogenität und Komplexität mit sich bringen.
Unternehmen die sich dennoch für diesen Weg entscheiden, müssen am am Ende im Schnitt 2,5 mal mehr in ihre Multi-Cloud-Architektur investieren - die dann allerdings nicht besonders gut funktioniert.
2. Kosten fixieren
Der größte Irrtum im Zusammenhang mit Multi-Cloud ist, dass man damit Lock-In-Effekte vermeiden und Geld sparen kann. Beides ist nicht wahr:
Vendor-Lock-In: Wenn Sie nachrechnen, werden Sie zum Ergebnis kommen, dass Sie die besten nativen Funktionen und Services eines Cloud-Anbieters nutzen, wenn Sie eine Anwendung bei diesem erstellen. Ihnen bleibt im Grunde auch gar keine andere Wahl, anderenfalls nehmen Sie eine hohe Cloud-Rechnung in Kauf - und, dass Ihre Anwendung in Sachen Performance, Funktionalität und Zuverlässigkeit nicht mithalten kann. Der Preis dafür ist eine gewisse Abhängigkeit, denn wenn Sie Ihre Anwendungen von einer Cloud in eine andere verschieben, müssen Sie einen Großteil des Codes ändern.
Kosten: Multi-Cloud-Implementierungen sind in keinem Fall günstiger als ihre Single-Cloud-Pendants. Schließlich müssen im ersteren Fall wesentlich mehr Cloud-Services mit unterschiedlichen Features gemanagt und konfiguriert werden. Auch die Kosten für Support und Security fallen höher aus.
Das Argument, dass der Umgang mit mehreren Public-Cloud-Anbietern Sie in eine bessere Verhandlungsposition bringen kann, greift in meinen Augen nicht. Jeder hat heutzutage Beziehungen zu mehr als einem Cloud-Anbieter - das ist nichts Besonderes mehr.
3. Menschen vernachlässigen
Bevor Sie auf Multi-Cloud (oder eine andere Technologie) umsteigen, sollte Ihr Unternehmen die Kultur und Fähigkeiten vorweisen können, die für den Erfolg vonnöten sind. Viele IT-Teams haben die Planung und Architektur von Multi-Cloud nahezu perfektioniert - liefern sie dann jedoch in eine Umgebung aus, in der ihr Sinn nicht verstanden wird und die Skills fehlen, um sie sich zunutze zu machen.
Zur Wahrheit gehört auch, dass Technologie-Experten am liebsten technische Probleme lösen. "People-Probleme" werden hingegen gerne einfach umgangen oder schlicht ignoriert. Diese Fehler sollten Sie dringend vermeiden (ich spreche aus eigener Erfahrung): Bereiten Sie Ihre Mitarbeiter auf Veränderungen vor, indem Sie ihnen neue Skills und Herangehensweisen vermitteln - zum Beispiel, wenn es um Cloud-Betriebsmodelle geht. (fm)
Virtueller Round Table "Multi-Cloud-Management"
Mohammad Reza Gashtil, adesso „Multi-Cloud-Umgebungen sind heute so komplex und vielschichtig, dass sie sich nicht selten über mehrere große Plattformen hinweg erstrecken. Für eine moderne Interpretation der DevSecOps gilt: You built it, you run it. Eine nahtlose und sichere Verzahnung zwischen Dev und Ops ist dafür essenziell. Die Praktiken, Werkzeuge, Architekturen und Sicherheit für eine Cloud-Native-App müssen nun in einer Multi-Cloud-Umgebung adressiert werden. Teilweise herrschen andere Prämissen in einer Multi-Cloud-Umgebung, welche ein Umdenken erfordert. <br /><br /> Um die End-zu-End Sicherheit einer Multi-Cloud-App gewährleisten zu können, wird hybrides Netzwerk ein Erfordernis. Für ein erfolgreiches Multi-Cloud-Management nimmt Automatisierung eine zentrale Stellung ein. Die selbstheilenden (Self-Healing) IT-Systeme, welche fehlertolerant und hochverfügbar betrieben werden, hat das Cloud Computing versprochen und geliefert. Auch das Monitoring und die Behebung der Schwachstellen folgen dieser Entwicklung. Die sogenannten Detection- & Response-Prozesse werden weitgehend KI-gestützt sein, weil Menschen oft gar nicht mehr in der Lage sind, auf eine Schwachstelle zu reagieren.<br /><br /> Das ‚Everything as Code‘-Leitbild erweitert die bereits etablierter ‚Infrastructure as Code‘ (IaC) um weitere Paradigmen, wie bespielsweise Security. Im Falle vom Governance sprechen wir von ‚Policy as Code‘.“
Dr. Stephan Michard, Dell Technologies „Das Mantra ‚Cloud first‘ ändert sich gerade hin zu ‚Application first‘. Die gegenwärtige Multi-Cloud-Nutzung ist bei vielen Unternehmen mit der Zeit zufällig gewachsen, das bringt oftmals einen gewissen Grad an Komplexität mit sich. Gleichzeitig entstehen jedoch auch viele neue Chancen. Wir müssen in der Diskussion an einen Punkt kommen, an dem Multi-Cloud-Management strategisch, an den Unternehmenszielen ausgerichtet, eingesetzt wird. Allein beim Beispiel Google Cloud fallen mir ad hoc fünf Möglichkeiten ein, Container zu hosten. Eine gute Strategie berücksichtigt diese Optionen.<br /><br />Am Anfang gilt es, im Rahmen eines Application Assessments zu beantworten, welche Applikation zu welcher Landing Zone passt. Dann erst kann entschieden werden, ob es Sinn ergibt, eine Applikation mittels Lift-and-Shift in einer Cloud-Umgebung zu betreiben, oder ob ein Refactoring vielleicht der bessere Ansatz ist.“
Andreas Kopf, microfin „Bei Nutzung von Cloud-Services ist die IT der zwei Geschwindigkeiten besonders spürbar. Bei Datenschutz und Compliance stehen kleinere Unternehmen vor großen Herausforderungen, die sie nicht ohne weiteres allein meistern können.<br /><br /> Statt Multi-Cloud trifft es vielleicht der Begriff “Multi-Provider” besser. Unternehmen müssen einen ganzen Zoo an Anbietern inkl. der eigenen IT orchestrieren können, wenn sie die Potenziale wirklich nutzen wollen.<br /> Am Ende bekommt man immer den Provider, den man verdient. Als kleines Unternehmen kann es schwer sein, alleine mit Hyperscalern zu verhandeln. Der Markt für Managed Services ist in den vergangenen Jahren stark gewachsen und es lohnt sich, Partner zu suchen, die die Vielzahl an Providern entsprechend steuern können.<br /> Die Steuerungs- und Compliance-Ebene ändert sich in einem Multi-Cloud-Umfeld kontinuierlich. Dieser Umstand sollte auch in SLA und Verträgen reflektiert sein, um nicht ständig neu verhandeln zu müssen. Dafür braucht es Augenhöhe und Vertrauen zwischen Provider und Kunde.“
Stefan Walter, minnosphere, ein Mitglied der msg-Gruppe „Lift-and-Shift-Szenarien haben in den vergangenen Jahren zugenommen. In der Praxis sind immer noch sehr viele Unternehmen dahingehend gezwungen, neben einer Standard SaaS-Anwendung auch weiterhin ihre eigene Private Cloud zu betreiben. Multi-Cloud bleibt damit auch in Zukunft eine Notwendigkeit.<br /><br /> Der Zuschnitt meiner IT-Infrastruktur ist nicht nur ein Sicherheits- oder Betriebsthema, sondern rührt auch an die Identität eines Unternehmens. Anwendungen und Systeme müssen letztlich auch zur Unternehmenskultur passen.<br /> Aus Sicht des ‚Innovators‘ gesprochen: Es muss auch in hochregulierten Branchen möglich sein, schnell einen Prototypen hochzuziehen und Neues auszuprobieren, trotzdem aber beim Datenschutz auf der sicheren Seite zu sein.“
Florian Weigmann, plusserver „Die Abrechnungsmodelle der Hyperscaler sind oft sehr komplex, sodass sie ohne Erfahrung nur schwer zu verstehen sind.<br /><br /> Applikation ist nicht gleich Applikation. Startups müssen sich zum Beispiel keine Gedanken über Altsoftware machen und können sofort auf DevOps setzen. Sie profitieren gleich von einer schlankeren Architektur mit erleichtertem Betrieb. Doch so ein ‚Big Bang‘ ist bei ‚gewachsenen‘ Unternehmen illusorisch. Der Monolith bleibt auch nach der Migration ein Monolith.<br /><br /> Wunsch und Ziel einer Multi Cloud ist schlicht, sich nicht mehr um die eigene Infrastruktur kümmern zu müssen. Die Komplexität ‚unter der Haube‘ sollte an der Oberfläche in Einfachheit umgemünzt werden. Workloads werden dorthin verlagert, wo sie den größten Benefit bringen.“
Bernd Gill, Rackspace „Wenn ein Kunde aus dem klassischen Outsourcing kommt, fehlen meistens Skills und Ressourcen, um den Betrieb selbst sicherzustellen. Insourcing wird bei Multi-Cloud so zum unternehmenskritischen Thema und erfordert die Ausbildung der eigenen IT als Teil des Transformationsprojektes.<br /><br /> Hyperscaler liefern hochstandardisierte Services. Um daraus überhaupt vernünftige Business Cases zu schöpfen braucht es Dienstleister, die die Lücke zwischen Standardtechnologie und Customizing schließen. Nur so wird die Public Cloud auch zum ‚Business Enabler‘.<br /><br /> Als Berater müssen wir die gesamte Organisation unserer Kunden mit auf die Reise nehmen. Schließlich geht es darum, alle Workloads so zu transformieren, dass sie in der Cloud zukunftsfähig werden. Dazu gehört: Aufräumen mit Altlasten, Hinzufügen neuer Funktionalitätsbausteine, Anbindung von neuen Technologien und Services wie künstlicher Intelligenz.“
Nicholas Hamblin, Tietoevry „Es beginnt doch schon bei der Zielsetzung. Betreibe ich eine Multi-Cloud, um einen Vendor-Lock-In zu vermeiden, oder geht es darum, zusätzliche Prozesse an eine bestehende Infrastruktur anzudocken? <br />Hauptimpuls für eine bestimmte Cloud-Strategie ist fast immer ein konkreter Use Case, der die Entscheidung für oder gegen Automatisierung, Kubernetes oder die Wahl eines Hyperscalers bedingt.<br /><br />In Multi-Cloud-Szenarien steigt die Gefahr, dass die Governance unter die Räder kommt – zum Beispiel in Form mehrfach gebuchter Subscriptions oder unnötiger Workloads. Das alles verursacht Kosten- und Sicherheitsrisiken. Es ist also wichtig, Security, Access Control und alle anderen Governance-Belange in meiner Multi-Cloud-Strategie von Anfang an mitzudenken.“