Praxis-Check: Wann Multi-Cloud Sinn macht — und wann nicht

Multi-Cloud hat sich in den letzten Jahren bei vielen grösseren CH-Firmen zum nächsten Schritt in ihrer Cloud Journey entwickelt. Die durch Kunden genannten Gründe für diesen Schritt sind mannigfaltig: Regulation, Kostenersparnis, technische Capabilities, Diversifikation, Resilienz, Flexibilität, Unabhängigkeit… Für viele ist es ein notwendiger Schritt, um den regulatorischen Auflagen gerecht zu werden. Doch häufig zeigt sich bei einem ersten Praxis-Check auch, dass der weitgehend erhoffte Nutzen ausbleibt und die genannten Gründe nur die halbe Wahrheit der Geschichte sind.

In diesem Blog beschreibe ich gute und weniger gute Gründe für den Einsatz von Multi-Cloud auf Basis unserer Praxiserfahrungen sowie mögliche Architekturansätze für die Adaption von Multi-Cloud.

Definition Multi-Cloud für diesen Blog: ein Cloud-Setup einer Firma, bestehend aus mehreren Public Clouds, die für den Betrieb von Workloads koexistent zum Einsatz kommen.

Viel Wunschdenken rund um Multi-Cloud

Multi-Cloud ist verlockend. Viele CH-Firmen bewegen sich dorthin, entweder auf Grund regulatorischer Auflagen oder erhofftem Nutzen. Doch auf dem Weg entpuppen sich Wünsche als Utopie, hier ein paar Beispiele aus der Praxis:

Keine Vendor Lock-ins

Keine Vendor Lock-ins durch Multi-Cloud - dafür Abhängigkeiten zu mehreren Hyperscalern oder 3rd-Party Software-Lösungen für die Abstraktion (z.B. OpenShift). In jedem Fall geht man Abhängigkeiten ein und kreiert Lock-ins. Und gleichzeitig kann durch die Abstraktion nicht mehr von den neuesten Entwicklungen der unterliegenden Plattform profitiert werden.

Kostenersparnis

Kostenersparnis durch Multi-Cloud - vielleicht bei einzelnen Services, doch aus Gesamtkostensicht betrachtet wohl eher nicht. Die technische Vielfalt und Redundanz, aber auch die Komplexität steigt dadurch, was auch die IT-Kosten in die Höhe schiessen lässt. Gleichzeitig nimmt der Verhandlungsspielraum mit den einzelnen Hyperscalern ab, da weniger Workload bei jedem einzelnen betrieben wird.

Flexibler Betrieb von Applikationen

Flexibler Betrieb von Applikationen durch Portabilität von Cloud zu Cloud - ein netter Gedanke, doch in der Praxis weniger anwendbar, denn Applikationen umfassen ja nicht nur Container, sondern auch Daten und Zusatzkomponenten. Und oft wäre die Nutzung nativer-Cloud-Dienste zielführender, darauf zu verzichten wäre falsch.

Höhere Resilienz

Höhere Resilienz durch Multi-Cloud - durch die Verteilung der IT-Landschaft über mehrere Cloud-Plattformen steigt die Anzahl Integrationspunkte und die Komplexität. Ob in einem solchen Setup die Resilienz wirklich erhöht werden kann, ist fraglich.

Multi-Cloud im Reality Check

Aber nicht alles ist Fantasie, Multi-Cloud kann Nutzen schaffen. Wir empfehlen, das Ganze auf Vor- und Nachteile hin zu betrachten. Dabei ist es wichtig: 

1. die richtigen Szenarien zu eruieren, bei denen du von Multi-Cloud profitieren willst
2. eine fundierte Kosten-Nutzen-Abwägung durchzuführen

Nachfolgend eine Auflistung verschiedener Pro und Contra Argumente, die man durchspielen kann (die Liste ist nicht abschliessend):

Daraus kann als Schlussfolgerung abgeleitet werden, dass es gute Gründe für den Einsatz von Multi-Cloud gibt. Insbesondere bei der Umsetzung eines Contingency Plan für Cloud-Setups regulierter Unternehmen oder bei Zero-Datacenter-Strategien. Doch es sollte auch beachtet werden, dass die Komplexität stark steigt und die Wirtschaftlichkeit oft nicht gegeben ist. Wenn kein effektiver Grund für Multi-Cloud vorliegt, dann sollte in der Regel von einem Multi-Cloud-Setup abgesehen werden. Bei Exit-Strategien für einen Contingency-Plan sollte nur der Weg beschrieben und das Minimum an Vorarbeiten geleistet werden, so dass man in notwendiger Frist handeln kann.

5 Architekturstile für Multi-Cloud im Vergleich

Falls man nach einer fundierten Kosten-Nutzen-Abwägung zum Schluss kommt, dass Multi-Cloud der richtige Weg ist, dann stellt sich die Frage nach dem Wie. Multi-Cloud ist keine one-size-fits-all Lösung, man muss von den typischen Architekturstilen den passendsten auswählen. Ein oft gemachter Fehler ist die Wahl einer zu komplexen Lösung, welche aus Geschäftssicht nicht benötigt wird, das Vorhaben viel zu teuer macht und somit der Nutzen im Verhältnis ungenügend ist.

Aus unserer Sicht werden im Buch Cloud Strategy von Gregor Hophe die typischen Architekturstile sehr gut veranschaulicht und beschrieben:

1. Arbitrary: Workloads / Applikationen werden in verschiedenen Clouds betrieben, doch ohne besonderen Grund. Die Verteilung passiert eher zufällig.
2. Segmented: Die unterschiedlichen Clouds werden für verschiedene Einsatzzwecke genutzt, z.B. App-Workloads werden in der einen Cloud und Analytics-Workloads in der anderen Cloud betrieben.
3. Choice: Projekte oder Abteilungen können für ihre Workloads / Applikationen den Cloud Provider selbst wählen. Auch besteht die Auswahl einer Primären- und Sekundären-Cloud.
4. Parallel: Einzelne Workloads / Applikationen werden in mehreren Clouds parallel betrieben.
5. Portable: Workloads / Applikationen werden portabel gebaut und können zwischen Clouds verschoben werden.

Aufgrund der Grösse von mittleren und grossen CH-Unternehmen und auch der Kosten-Nutzen-Abschätzung treffen wir bei unseren Kunden die Architekturstile Segmented und Choice in der Praxis am häufigsten an. Oft auch lediglich als Primär-Sekundär-Cloud-Setup, für den Notfall zur Realisierung ihres Exit-Plans. Den anderen Architekturstilen begegnen wir eher nicht.

Bei der Implementation eines Multi-Cloud-Setups sollten Multi-Cloud-fähige Automatisierungs- (z.B. Terraform für IaC und GitHub für CI/CD) und Management-Tools (z.B. Azure Arc) zum Einsatz kommen, welche mit den nativen Services der jeweiligen Cloud-Plattform integrieren. Dies vereinfacht die übergeordnete Handhabung eines Multi-Cloud-Setups stark. Doch auf keinen Fall sollte eine ganzheitliche Cloud-Experience für Dev und Ops angestrebt werden. Das wäre zu aufwändig und gleichzeitig würden native-Fähigkeiten der jeweiligen Plattform verloren gehen, welche klare Vorteile bringen und von Azure-, AWS- oder GCP-Experten nativ genutzt werden wollen.

Multi-Cloud macht Sinn, wenn es sich lohnt

Wenn Multi-Cloud keinen klaren Nutzen erzielt, empfehlen wir, darauf zu verzichten. Mit den wachsenden Public-Cloud-Setups bis hin zu Zero-Datacenter-Strategien wird es jedoch künftig wohl unabdingbar, sich mit Multi-Cloud auseinanderzusetzen und abzuwägen. Denn eine Ja / Nein Antwort ist aus unserer Sicht nicht möglich. Was wir auf jeden Fall sagen können, es muss sich lohnen. Bei einem Entscheid für den Einsatz von Multi-Cloud muss man sich also der steigenden Komplexität, den zunehmenden Integrations- und Security-Herausforderungen und der erhöhten Arbeitslast bewusst sein. Daher sollte eine gründliche Kosten-Nutzen-Abwägung mit einer klaren Strategie zu Grunde liegen.

Folgend unsere Empfehlungen / Anmerkungen, wann der Einsatz von Multi-Cloud sinnvoll ist:

• Grundsätzlich ist «Single Public Cloud» die erste Wahl. Starte mit der Cloud-Adoption möglichst schlank und erziele schnelle Erfolge.
• Falls «Single Public Cloud» nicht ausreicht und gute Gründe für «Multi-Cloud» vorliegen (siehe “Pro”-Argumente weiter oben), dann mache «Multi-Single Public Cloud». Das heisst konkret, mehrere Clouds nebeneinander, doch in keinem Fall mit einer einheitlichen Cloud-Experience über alle Plattformen, das sollte in jedem Fall vermieden werden (siehe am Ende im Kapitel zu den 5 Architekturstilen).
• Falls Multi-Cloud auf Grund einer Exit-Strategien aufgebaut werden soll, dann sollte nur der Weg beschrieben und das Minimum an Vorarbeiten geleistet werden. So kann man in notwendiger Frist handeln.
• Lock-ins können durch Multi-Cloud nicht umgangen werden, man hat in jedem Fall einen Lock-in, einfach auf unterschiedlichen Ebenen. So baut man z.B. auch bei der Verwendung von K8s/Container oder OpenShift als Abstraktionslayer eine Abhängigkeit auf und man verliert die direkte Nutzung von neuen Funktionalitäten der unterliegenden Plattform.
• Die übergeordnete Automatisierung mit IaC und CI/CD sollte auf jeden Fall mit Multi-Cloud-fähigen und nicht proprietären Tools realisiert werden, welche sich mit den jeweiligen nativen Services der jeweiligen Plattform integrieren. Dadurch kann von den neuesten Features profitiert werden.
• Aufgrund der Entwicklungen empfehlen wir für den Einsatz von Multi-Cloud bei den entsprechenden Anwendungsfällen folgende Architekturstile:

Ist Multi-Cloud bei dir auch ein Thema? Dann nehme gerne mit uns Kontakt auf.