In einer Multi-Cloud-Umgebung ist man schneller als man denkt – beispielsweise wenn ein Unternehmen Cloud-Dienste von unterschiedlichen Anbietern bezieht. Dafür gibt es gute Gründe: so kombiniert die Firma etwa die besten Angebote, optimiert Ausfallsicherheit sowie Kosten oder umgeht den Vendor-Lock-in. Dieser treibt viele an, ihre Apps, Rechenleistung und Infrastruktur nicht bei einem einzigen Hyperscaler „einzuschließen“.
Auch andere strategische Überlegungen können in die Multi Cloud führen. Bedingt eine Anwendung beispielsweise den Betrieb in einer spezifischen Region, so empfiehlt es sich dort auf einen lokalen Cloud Provider oder einen Hyperscaler zu setzen, der vor Ort präsent ist. Diese Anbieter schneiden in der Regel in Bezug auf Netzwerklatenzen und Zugriffszeiten besser ab. Zudem können so spezielle Anforderungen des Datenschutzes erfüllt werden.
Cloud-Konzepte durchdringen
Jedoch verfolgt jeder Cloud-Anbieter sein eigenes Konzept, das man zunächst verstehen muss. Unterschiede zeigen sich in den Verfügbarkeiten, Architekturen und höherwertigen Diensten. Auch findet die Verschlüsselung des Datenverkehrs an variierender Stelle statt. Die verschiedenen Plattformen und deren Schnittstellen bringen wiederum bestimmte Abfragelimits und -formate mit sich, die es erschweren, Services von einer in die andere Cloud zu konvertieren.
Lesetipp: Wie aus vielen Cloud Services eine integrierte Lösung wird
Erst das Durchdringen der Cloud-Konzepte schafft die Voraussetzung, Regularien für die Cloud Governance festzulegen sowie Prozesse und Betriebsmodelle aufzusetzen. Außerdem gilt es, sich um den Support zu kümmern. Regelmäßig – was alle zwei, drei Wochen sein kann – informieren Provider über neue Features und Services. Oder Schnittstellen verändern sich oder werden eingestellt. Damit muss sich jemand intern beschäftigen und prüfen, inwieweit sich Neu- und Weiterentwicklungen auf eigene Projekte, das Sicherheitsniveau und Budget auswirken. Für das nötige Monitoring, Backup und die Bereitstellung von Diensten oder Security bieten Cloud Provider zum Teil native Tools. So kann man beispielsweise mit vordefinierten Blueprints Compliance- und Governance-Richtlinien erstellen, die zu einer DSGVO-konformen Umgebung führen. Diese gelten dann allerdings jeweils nur für die eine Cloud, zu der sie nativ gehören.
- Timo Brueggemann, Canonical
„Wer glaubt, es genügt, sich ein Cloud-natives Produkt zu besorgen und es auf die eigene Infrastruktur aufzuspielen, um dann loszulegen, der irrt sich gewaltig. An erster Stelle geht es darum, zentrale Fragen zu beantworten: Wie ist mein Stack, und welche Use-Cases habe ich? Wie sind meine Infrastruktur und meine unternehmensinterne Organisation aufgebaut, und in welchen Bereichen ergibt Cloud-native am ehesten Sinn? Wenn das geklärt ist, beginnt man mit ausgewählten Themen und holt sich externes Wissen für Trainings dazu. Anhand dieser Leuchtturmprojekte lässt sich dann gut zeigen, wie es laufen muss. Man stellt ja nicht von heute auf morgen alles und alle Anwendungen gleichzeitig um.“ - Christian Dörrer, Objektkultur
„Um alle Vorteile von Cloud-native effektiv nutzen zu können, muss das gesamte Change- Management im Unternehmen berücksichtigt werden. Neben der Transformation der Organisation, der Prozesse und der Querschnittsfunktionen ist auch die Qualifizierung der Mitarbeiter entscheidend. Zudem erwarten neue hoch qualifizierte Mitarbeiter, dass der Arbeitgeber in Cloud-native-Technologien investiert. Nur so kann die komplette Innovationskraft eines Unternehmens ausgeschöpft werden.“ - Thorsten Fischer, Open Text Software
„Unternehmen haben unterschiedliche Cloud-Strategien. Die einen bevorzugen Standardisierung Richtung SaaS und Cloud-native, andere erhalten sich eine stärkere Individualität bei maximaler betrieblicher Effizienz. Für Unternehmen und Softwarehersteller ist es wichtig, die richtige Balance zu finden: Wie kann ich vorhandene Software zum Beispiel mittels Containerisierung besser in die Cloud bringen und gleichzeitig einen Cloud-native Stack hochziehen? Für Anwender und Anbieter spielt dabei neben der Technik die Organisationsstruktur eine entscheidende Rolle, es reicht nicht mehr, nur in Produkten zu denken. Die Gesamtbetrachtung muss im Mittelpunkt stehen.“ - Andreas Knols, QSC
„Viele gehen das Thema Cloud-native mit den Technologieabteilungen oder auch nur mit den Fachabteilungen an, aber neben dem Mindset Richtung DevOps oder Continuous Deployment gehören noch viele weitere Dinge dazu. Es ist hauptsächlich ein People- und Prozess-Business und weniger ein Technik-Business. Ich kann nur empfehlen, sich einen erfahrenen Berater zu holen, der die Visibilität für all die Themen schafft, die ebenfalls davon betroffen sind, wie zum Beispiel die Rechnungsfreigabe. Wenn Sie die Public-Cloud-Rechnung nicht rechtzeitig bezahlen, dann wird der Service einfach abgeschaltet. Auch darauf muss man den Kunden hinweisen.“ - Stephan Nies, Deloitte
„Die Entwicklungskosten und die Cost of Opportunity werden gerne unter den Tisch gekehrt. Wenn ich es wegen meiner selbst gehosteten Lösung nicht schaffe, die Projekte in einem halben Jahr umzusetzen, und statt dessen zwei Jahre brauche, dann haben die Wettbewerber in einem halben Jahr schon gehandelt. Von daher kann es durchaus wirtschaftlich sinnvoll sein, ein bisschen mehr Geld für die Cloud auszugeben. Zumal man bedenken muss, dass manche deutschen Unternehmen ohnehin schon im Hintertreffen gegenüber chinesischen und amerikanischen Konkurrenten sind. Da ist dann die Frage, wie viel Selber-Hosten man sich noch leisten kann.“
Für Multi-Cloud-Nutzer bedeutet das: Multi-Management. Setzt das Unternehmen etwa auf drei unterschiedliche Cloud Provider, muss es Änderungen jeweils in drei verschiedenen Tools durchführen oder sich zusätzliche Multi-Cloud-Management-Werkzeuge für Konfiguration, Security und Kosten beschaffen.
"Primär-Public-Cloud" als Basis
Unternehmen sollten sich daher unbedingt an einem Grundsatz orientieren: Multi Cloud so viel wie nötig und so wenig wie möglich. Dieses Prinzip ist am besten mit einer Primär-Public-Cloud vereinbar, die durch passende Services von anderen Cloud Providern ergänzt wird. Auf diese Weise entsteht eine Infrastruktur, die so einfach wie möglich bleibt – und sich managen lässt.
Die Definition einer Primär-Public-Cloud bringt entscheidende Vorteile. In diese sollten daher je nach Geschäftsfokus auch die Hauptinvestition fließen. So kann bei KI-Technologien Google oder bei Suchalgorithmen IBM die erste Wahl sein. Services aus weiteren Clouds werden projektbezogen oder nach Länderaktivitäten konsumiert. Für eine priorisierte Cloud-Nutzung spricht, dass die Infrastruktur verhältnismäßig einfach bleibt und sich die Verhandlungsposition im Einkauf gegenüber dem Provider verbessert. Wird das Budget gleichmäßig auf drei Anbieter verteilt, schwindet die Aussicht auf üppige Nachlässe. Andererseits agiert man so unabhängiger. Wem das wichtiger ist, der lässt seine containerbasierten Apps auf drei Cloud-Plattformen laufen.
Lesetipp: So gestalten Sie die Container-Entwicklung sicher
Allerdings ist die Freiheit, schnell zu einer anderen Cloud-Plattform zu wechseln, nicht bei allen Diensten gegeben. Nehmen wir eine Windows-Server-VM (virtuelle Maschine), die bei Microsoft unter Hyper-V läuft, bei AWS allerdings nicht. Hier entsteht Migrationsaufwand, um den Server von einer Cloud in die nächste zu verschieben. Ähnlich verhält es sich mit IoT- und KI-Lösungen. Ein Chatbot im Kundenservice ist ein spezifischer Dienst, der sein Framework braucht und sich nicht so ohne Weiteres von A nach B umziehen lässt.
Managed Multi Cloud?
Unternehmen, die Infrastruktur und Services bei drei bis vier Plattformen betreiben wollen, hätten oft gern eine zentrale Lösung für ihr Multi-Cloud-Management. Die perfekte Lösung gibt es dabei nicht. Aus dem Grund stehen Firmen vor der Wahl: Entweder sie investieren in Personal und Know-how sowie in Tool-Lizenzen, um sich selbst ein umfassendes Multi-Cloud-Management aufzubauen. Oder sie holen IT-Spezialisten an Bord, die ihre Umgebung Multi-Cloud-fähig machen und – wenn gewollt – im Managed Service betreuen.
Am Anfang sollte stets eine Roadmap stehen, die den Ist-Stand feststellt und aufzeigt, wie sich mehrere Cloud-Plattformen effizient nutzen lassen. Wesentlicher Bestandteil ist hierbei das Etablieren einer Cloud Governance, die in allen Clouds angewendet wird.
Lesetipp: So gestalten Sie die Container-Entwicklung sicher
Bisherige Arbeitsweisen gehören in einem Multi-Cloud-Konzept auf den Prüfstand. Meist ergibt sich dann die Notwendigkeit, Prozesse neuzudenken, aufzusetzen und zu überwachen. An der Stelle empfehlen sich Tools, die mehrere Clouds durchleuchten. Dashboards beispielsweise können einen Überblick zu den Gesamtkosten, die bei Azure und AWS zu den Software-Lizenzen und Cloud-Abonnements auflaufen, geben, und gestatten detaillierte Einblicke in die Technologieplattformen und Handelsvereinbarungen. Andere Lösungen machen Security über plattformübergreifendes Patching, Antivirus und Monitoring transparent. (bw)