Portabilität in der Cloud — aber nicht um jeden Preis

Autor: Weili Gao

Bei Architektur-Diskussionen zu Applikationen in der Cloud ist Portabilität ein beliebtes Thema. Viele Unternehmen möchten einen Lock-in auf einen einzigen Cloud-Anbieter vermeiden, um z. B. aufgrund von regulatorischen Auflagen oder Kosten ihre Applikationen möglichst einfach zu einem anderen Anbieter migrieren zu können. In der Praxis zeigt sich jedoch, dass für eine möglichst hohe Portabilität oft hohe Kosten in Kauf genommen werden, ohne dass der hypothetische Anbieterwechsel jemals zustande kommt.

Nachfolgend möchte ich erläutern, warum ein zu grosser Fokus auf Portabilität nicht sinnvoll ist, und gebe einige konkrete Empfehlungen zur Verringerung von Vendor Lock-in, ohne dass zu viel Upfront-Investment nötig ist.

Portabilität vs. Cloud-Native

Moderne Applikationen von heute sind oft „Cloud-Native“, d. h., sie wurden für den Einsatz in der Cloud entwickelt und nutzen deren Vorteile bestmöglich aus. Durch die Befolgung der Cloud-Native-Prinzipien und Nutzung von Produkten des Cloud-Anbieters erreicht man:

Schnellere Markteinführung (Time-to-Market)
Höhere Skalierbarkeit und Resilienz
Innovationskraft und Business-Agilität

Zum Thema „Cloud-Native Entwicklung“ haben Daniel Albisser und Andreas Pfenninger spannende Blog-Artikel geschrieben, welche ich sehr empfehle (s. Speed in der Entwicklung dank Cloud-native & Cloud-native im Aufwind: der richtige Architektur-Ansatz für mein Unternehmen).

Doch der Cloud-Native-Ansatz steht im Gegensatz zur Portabilität in der Cloud. Denn je mehr Produkte und Features des Cloud-Anbieters man für die Applikation nutzt, desto mehr begibt man sich in einen Lock-in dieses Anbieters.

Speziell bei der Nutzung von Platform-as-a-Service und Serverless-Produkten, deren Betrieb von den Cloud-Anbietern übernommen wird, gilt: Diese Produkte sind oft Anbieter-spezifisch und es kostet mehr Aufwand, Applikation welche diese Produkte verwenden auf eine andere Cloud zu migrieren. Doch dieser Vendor Lock-in kommt mit einer Vielzahl von Vorteilen, wie z. B. geringe Fertigungstiefe, was den Betriebsaufwand und die Einstiegshürde verringert oder gute Integration mit anderen Produkten des gleichen Anbieters, sodass der Entwicklungsaufwand niedriger und die Applikation wartbarer, performanter und sicherer ist.

Der Preis von Portabilität

Es stellt sich die Frage, wie weit man gehen sollte, um die Portabilität von Applikationen in der Cloud zu erhöhen und welchen Preis man dafür zahlt. Wie Gregor Hohpe in seinem Artikel gut beschrieben hat, gibt es verschiedene Arten von Lock-ins. Bei Diskussionen über die Vermeidung von Vendor Lock-in muss beachtet werden, dass man oft andere Arten von Lock-ins einführt. Einige Beispiele sind:

Produkt Lock-in: Um möglichst portabel zu sein, werden häufig Cloud-unabhängige Produkte und Frameworks, meistens in Form von Open-Source-Projekten, eingesetzt. Dadurch tauscht man jedoch einen Lock-in auf einen Cloud-Anbieter gegen ein Lock-in auf ein bestimmtes Produkt. Man ist davon abhängig, dass das Produkt weiterhin aktiv von dessen Anbieter oder Open-Source-Community gepflegt wird, was nicht immer der Fall ist.
Architektur Lock-in: Um Vendor Lock-in zu vermeiden, unterlässt man die Verwendung von Anbieter-spezifischen Produkten und Features. Dies führt jedoch dazu, dass manche Architektur-Möglichkeiten gar nicht mehr möglich sind. So ist z.B. eine Serverless-Architektur wie von Kevin Duss gut erläutert, ohne den Einsatz von Function-as-a-Service und einer engen Integration mit anderen Produkten des Anbieters nicht möglich und man ist darauf beschränkt, andere Optionen zu wählen.
Skill Lock-in: Um den Einsatz von Anbieter-spezifischen Platform-as-a-Service Produkten zu vermeiden, muss man dessen Alternativen oft selbst hosten und betreiben. Dies ist jedoch oftmals nicht nur mit erheblichem Aufwand verbunden, sondern man benötigt dafür auch genügend Mitarbeiter mit passendem Know-how, wie z.B. zum Betrieb eines eigenen Kubernetes-Clusters.

Durch zu viel Fokus auf Portabilität könnte man andere Probleme aus den Augen verlieren.

Zusätzlich zu den oben genannten Lock-Ins fallen weitere Kosten an, die häufig für eine erhöhte Portabilität entstehen:

Entwicklungsaufwand

Eine gesteigerte Portabilität erfordert oft zusätzlichen Einsatz, beispielsweise durch die Implementierung von Abstraktionsschichten. Zudem wird vermieden, anbieterspezifische Funktionen zu nutzen, was häufig die Entwicklung eigener Alternativfunktionen oder Workarounds erforderlich macht.

Komplexität

Mit Verwendung von zusätzlichem Code zur Vermeidung von Vendor Lock-in nimmt die Komplexität zu (Stichwort: Over-Engineering). Dadurch erhöhen sich nicht nur der Wartungsaufwand, sondern auch die Zeitspanne für das Onboarding neuer Entwickler:innen sowie das Risiko von Bugs.

Opportunitätskosten

Man verzichtet auf die vielen Vorteile, welche Cloud-Native-Entwicklung bietet und im vorherigen Abschnitt erwähnt wurden und was oft die Hauptmotivation für den Umstieg in die Cloud ist.

Lohnt sich die Investition in Portabilität?

Zusammengefasst ist der Preis, den man für eine hochgradig portable Applikation zahlt, beträchtlich. Um diese anfängliche Investition zu rechtfertigen, sollte der Nutzen oder die Wahrscheinlichkeit eines künftigen Wechsels des Cloud-Anbieters ebenso im Verhältnis stehen.

Basierend auf unseren Erfahrungen, welche wir bei ipt auf unseren Kundenprojekten gesammelt haben, wird in den seltensten Fällen der Cloud-Anbieter gewechselt und Applikationen von einer Cloud zu einer anderen migriert. Wie Daniel Albisser in seinem Artikel über Multi-Cloud verdeutlicht, begegnen wir bei Kunden mit einem Multi-Cloud-Setup am häufigsten den Architekturstilen "Segmented" und "Choice". In diesen beiden Architekturen werden zwar verschiedene Cloud-Anbieter genutzt, aber die betriebenen Applikationen müssen nicht zwingend so portabel sein, dass sie mit allen Cloud-Anbietern gleichermassen kompatibel sind. Vielmehr bleiben sie über ihre gesamte Lebensdauer beim gleichen Cloud-Anbieter.

Kurzum: Es lohnt sich nicht, beim Design von Applikationen rein basierend auf Portabilität zu entscheiden, da das Kosten/Nutzen-Verhältnis oft sehr schlecht ist.

Meine Empfehlung zur Cloud-Portabilität

Welche Aspekte sollte man bei Architekturentscheidungen während der Entwicklung einer Applikation hinsichtlich ihrer Portabilität berücksichtigen? Hier sind meine drei konkreten Empfehlungen:

Gewichtung der Portabilität: Portabilität sollte bei Architekturentscheidungen mit Bedacht berücksichtigt werden. Anstatt sich nur auf die Vermeidung von Vendor-Lock-In zu fokussieren, sollte man darauf achten, ob man mit der gewählten Lösung andere Arten von Lock-ins einführt. Oft lohnt es sich sogar, kalkuliert Vendor Lock-in einzugehen, sofern dadurch viele andere Lock-ins reduziert werden oder andere Vorteile erzielt werden (z.B. Platform-as-a-Service Produkte, um Architektur- oder Skill Lock-in zu reduzieren und kürzere Time-to-Market zu ermöglichen).
Clean Architecture-Prinzipien anwenden: Die Portabilität einer Applikation lässt sich durch den Einsatz von Clean Architecture-Prinzipien verbessern. Dies umfasst die klare Trennung der äusseren, Cloud-abhängigen Schicht im Code von der inneren, Cloud-unabhängigen Schicht sowie die Anwendung der Dependency Rule. Auf diese Weise ist die äussere Schicht von der inneren abhängig, jedoch nicht umgekehrt. Im Falle eines Cloud-Wechsels muss lediglich die entsprechende Stelle in der äusseren Schicht angepasst werden. Zusätzliche Vorteile von Clean Architecture sind eine verbesserte Wartbarkeit und Testbarkeit der Applikation.
Nutzung bewährter Produkte und Standards: Man sollte gut dosiert auf bewährte, von grossen Open-Source-Communities unterstützte Produkte, Frameworks und Standards setzen, welche mit mehreren Cloud-Anbietern kompatibel sind. Es ist dabei besonders wichtig, dass diese Produkte eine breite Benutzerschaft aufweisen und aktiv gewartet werden, da andernfalls, wie bereits erwähnt, ein teurer zusätzlicher Lock-in entstehen kann. Ein gutes Beispiel ist z. B. Terraform (trotz dessen Lizenzänderung vor Kurzem), welche von allen grossen Cloud-Anbieter unterstützt wird, zeitnahe Updates erfährt und viel Erfahrung und Dokumentation damit vorhanden ist.

Die Grafik illustriert, wie eine Anwendung gemäss den Prinzipien der Clean Architecture aufgebaut werden sollte, um eine optimale Cloud-Portabilität zu gewährleisten.

Fazit

Die Praxis hat gezeigt, dass Portabilität in der Cloud oft überbewertet wird. Die Kosten zur Vermeidung von Lock-ins auf einen bestimmten Cloud-Anbieter stehen häufig in keinem Verhältnis zur Wahrscheinlichkeit, dass man eine Applikation tatsächlich zu einem anderen Anbieter migriert. Ich empfehle deshalb, bei Architekturentscheidungen beim Thema Vendor Lock-in auch auf andere Formen von Lock-in und Kosten zu achten, Clean Architecture Prinzipien zu befolgen sowie wohlüberlegt gut unterstützte Open-Source-Produkte einzusetzen. So kann man die vielen Vorteile der Cloud-Native-Entwicklung voll ausschöpfen und dennoch im sehr seltenen Fall, dass man den Cloud-Anbieter wechselt, die Applikation mit relativ wenig Aufwand migrieren.

Über mich

«Mich begeistern alle Themen rund um die Cloud und ich bin leidenschaftlich daran interessiert, meinen Kunden zu helfen, das volle Potential der Cloud auszuschöpfen.»

Weili Gao