Vendor Lock-In oder was kostet die Freiheit?

Dieser Artikel ist inspiriert von einem Artikel von Gregor Hohpe, der im September 2019 auf dem Blog von Martin Fowler erschienen ist.

Als Experte für Public Cloud berate ich meine Kunden auf strategischer und technischer Ebene zu ihren Cloud-Vorhaben. Dabei taucht immer wieder das Thema vom Cloud-Anbieter-Lock-In auf. Beim Anbieter-Lock-In kann ein Kunde den genutzten Cloud-Service nicht ohne Weiteres durch eine gleichwertige Lösung eines anderen Anbieters austauschen. Oder salopp ausgedrückt: Wir machen uns von Tech-Giganten wie Microsoft, Amazon oder Google abhängig.

Die Software-Architekten meiner Kunden wollen diesen Lock-In wenn immer möglich vermeiden, was grundsätzlich eine gute Idee ist. Ich möchte aber in diesem Artikel den folgenden Fragen nachgehen:

• Ist ein Lock-In überhaupt vermeidbar?
• Was kostet mich das Vermeiden von einem Cloud-Anbieter-Lock-In?
• Wie schlimm ist denn so ein Cloud-Anbieter-Lock-In?

Ist ein Lock-In überhaupt vermeidbar?

Zunächst muss man feststellen, dass es neben dem technischen Lock-In noch weitere Arten von Lock-Ins gibt, beispielsweise einen vertraglichen Lock-In: Ich sehe es häufig, dass sich Software-Architekten noch Gedanken zur Vermeidung des technischen Lock-Ins machen, während der CIO bereits einen 3-Jahres-Vertrag mit dem Cloud-Anbieter abschliesst, um von günstigen Konditionen profitieren zu können. Oder einen Skills-Lock-In aufgrund des Wissens im Unternehmen in den Bereichen Entwicklung, Betrieb und Security. Im Microsoft-Umfeld gibt es zudem den Platform-Lock-In, da man bei einer Microsoft-Cloud-Strategie nicht nur Azure isoliert betrachtet kann, sondern auch Office 365, Azure Active Directory und die Power-Plattform berücksichtigen muss.

Gregor Hohpe führt in seinem Artikel noch einige weitere Arten von Lock-Ins aus, aber zurück zum technischen Lock-In: Hohpe diskutiert in seinem Artikel das Beispiel von Kubernetes, vermutlich das am meisten verwendete Produkt, um einen Cloud-Anbieter-Lock-In zu vermeiden. Kubernetes hat den Vorteil, dass es Open-Source ist und auf allen gängigen Plattformen läuft, inklusive On-Premises. Das Problem dabei ist, dass ich mit der Verwendung von Kubernetes jetzt einen Lock-In auf Kubernetes habe und wenn ich die Managed Kubernetes Services von Azure, AWS oder Google verwende, habe ich am Ende einen doppelten Lock-In, nämlich auf die spezifische Kubernetes-Version des jeweiligen Cloud-Anbieters und dessen proprietären Erweiterungen.

Ich möchte das an zwei weiteren Beispielen aus meinem Berater-Alltag ausführen. Ich bin häufig in industriellen IoT-Projekten unterwegs. In diesen Projekten wird Cloud-seitig immer ein proprietärer Service für die Schnittstelle zu den Devices verwendet: der Azure-IoT-Hub, Cumulocity IoT Core, AWS IoT Core, etc. Diese Services sind in der Lage, mit Millionen von Devices bidirektional zu kommunizieren und bieten alle gewünschten Eigenschaften bezüglich Sicherheit, Verfügbarkeit und Skalierbarkeit. Kaum jemand würde auf die Idee kommen, einen solchen Service für sein IoT-Projekt selbst zu bauen, zumal das keinen Business Value generiert. Wenn es dann aber um die restlichen Komponenten der Cloud-Architektur geht, versuchen manche Software-Architekten einen Lock-In zu vermeiden, obschon sie ihn bereits eingegangen sind und ihre IoT-Devices für immer am entsprechenden IoT Hub hängen werden.

Ein anderes Beispiel ist Infrastructure-as-Code. Es gibt gute Gründe, ein IaC-Framework wie beispielsweise Terraform einzusetzen: Es hat einen grossen Funktionsumfang, eine hohe Maturität und eine gute Unterstützung für gängige DevOps Prozesse. Die Tatsache, dass Terraform plattformunabhängig ist, heisst aber nicht, dass ich heute mit meiner IaC-Pipeline auf Azure und morgen auf Amazon deployen kann. Das ist Utopie, zu unterschiedlich sind die Schnittstellen, die Zugriffskonzepte, das Governance-Framework und die einzelnen Services, selbst wenn es sich um dasselbe Open-Source-Produkt handelt.

Wenn ich solche Dinge anspreche, höre ich oft das Gegenargument: «Es kostet mich ja nichts, wenn ich auf Cloud-agnostische Komponenten setze, anstelle von proprietären Services. Wenn die nicht-proprietäre Lösung mindestens gleich gut ist wie der proprietäre Service, können wir ja nur gewinnen.»

Was kostet mich das Vermeiden von einem Cloud-Anbieter-Lock-In?

So einfach ist es aber nicht. Zunächst ist es so, dass proprietäre Cloud-Services in der Regel deutlich günstiger sind als ihre Cloud-agnostische Alternativen. Die Cloud-Provider können ihre eigenen Services sehr stark optimieren und automatisieren, sie sind in der Regel serverless und damit schnell skalierbar, und die Ressourcen dieser Services sind nicht dediziert, sondern werden gepooled. Damit profitieren die eigenen Cloud Services (aka PaaS) der Public-Cloud-Anbieter sehr stark von Skaleneffekten (Economies of Scale). Das klingt nach sehr vielen Buzzwords, aber das sind alles zentrale Eigenschaften von Cloud Computing, die oft vergessen gehen. Es mag erstaunen, aber auch Kubernetes hat bis heute Mühe damit, diese fundamentalen Mechanismen von Cloud Computing abzubilden und muss häufig über-provisioniert betrieben werden (das heisst die Server des Clusters sind nicht ausgelastet und wir bezahlen daher für Ressourcen, die wir nicht nutzen). Genauso wie beispielsweise die meisten Big-Data-Frameworks zunächst nicht für die Elastizität der Cloud konzipiert waren. Auch Datenbanken, Web-Server oder Integrations-Lösungen können nur bedingt von der Cloud profitieren und sind damit insgesamt teurer als ihre PaaS-Pendants. Um das anhand eines einfachen Zahlenbeispiels zu veranschaulichen: Ein virtueller Server ist durchschnittlich zu 6% bis 10% der maximalen Prozessor-Leistung ausgelastet (je nach Studie, der man vertrauen will). In Serverless-Infrastrukturen können die Instanzen problemlos zu 80% ausgelastet werden.

Wenn ich proprietäre Services vermeiden will, habe ich aber weitere, indirekte Kosten. Zum Beispiel kann ich einen Grossteil der Innovation des Cloud-Providers nicht nutzen. Von den jeweils 200-300 PaaS-Services, die AWS, Google oder Microsoft auf ihren Cloud-Plattformen anbieten, sind die allermeisten proprietär – auch wenn sie ein Open-Source-Produkt adaptieren, siehe das Kubernetes Beispiel von oben. Wenn ich einen Lock-In vermeiden will, kann ich also schätzungsweise 90% der Services eines Providers nicht nutzen. Das bedeutet am Beispiel von Microsoft Azure, dass ich ein Grossteil der Innovation von Microsoft der vergangenen 10 Jahre nicht nutzen kann. Man muss kein Microsoft-Fan sein, um zu erkennen, dass das ein gewaltiger Lock-In (respektive Lock-Out) ist.

Neben den eigentlichen Cloud-Kosten gibt es noch weitere Aufwände, die es zu beachten gibt. Der erste sind die Entwicklungskosten. In den letzten 10 Jahren habe ich es immer wieder erlebt: Software-Entwicklung auf PaaS ist schneller: Wenn ich beispielsweise die Entwicklung einer Komponente auf Basis von Azure Functions mit einer Container-basierten Umsetzung vergleiche, sind wir auf den serverless Functions schneller, weil wir deutlich weniger Code schreiben, debuggen, testen und warten müssen. Solche «Functions» sind viel kleiner als «Container»-Komponenten. Kleine Komponenten kann ich auch schneller ersetzen, wenn ich meine Architektur ändern muss oder erweitern will.

Der zweite Kostenpunkt sind die Betriebskosten, insbesondere die wiederkehrenden Personenstunden, die ich für den Betrieb der Lösung aufwenden muss. Diese Aufwände fallen auch bei einer PaaS-Lösung nicht ganz weg. In meinem Booklet zeige ich die Betriebsaufwände einer Managed-PaaS-Lösung auf. Wenn ich mich in meiner Architektur für Cloud-Anbieter-unabhängige Komponenten entscheide, muss ich deutlich mehr Infrastruktur selbst aufsetzen, konfigurieren, betreiben und warten sowie deren Sicherheit und Governance sicherstellen.

Ein dritter Kostenpunkt, der bei der initialen Architekturdiskussion häufig vergessen geht, sind die Kosten für Compliance. In den meisten Projekten kommt nach der PoC-Phase die Frage auf, nach welchem Cyber-Security-Standard man die Lösung auditieren oder zertifizieren will. Es ist einfacher, wenn ich auf Komponenten aufsetze, die bereits die nötigen Audits oder Zertifizierungen mitbringen. Als Beispiel sei Azure Active Directory genannt, welches bereits GDPR-Compliant ist. Oder Services wie der Azure Key-Vault, die notwendig sind, um gewisse Anforderungen aus Sicherheitsaudits überhaupt erfüllen zu können. Oder Managed Identities, eine Funktionalität, die es mir ermöglicht, dass meine Applikation nicht einen Schlüssel verwalten muss, um auf die Datenbank oder die Messaging Middleware zugreifen zu können. Der entsprechende Zugriff wird zwischen den beteiligten Cloud-Services konfiguriert, inklusive feingranularem Rechte-Management. Diese Funktionalität steht mir aber nur bei den proprietären PaaS-Services zur Verfügung.

Der vierte Kostenpunkt bei der Vermeidung eines Cloud-Anbieter-Lock-In: Keine Rabatte. Auf der Microsoft Azure Plattform kann ich beispielsweise für die meistens Services Rabatte aushandeln. Das funktioniert so, dass ich eine Abschätzung mache, wieviel Ressourcen ich mindestens von einem bestimmten Service über die nächsten Jahre konstant nutzen werde. Wenn ich bereit bin, für diese Ressourcen im Voraus zu bezahlen (ob ich sie nutze oder nicht) kann ich Rabatte von bis zu 50 % auf die Listenpreise aushandeln, je nach Umfang meiner Verpflichtung. Das heisst, um von Rabatten profitieren zu können, muss ich einen Lock-In eingehen.

Wie schlimm ist denn so ein Cloud-Anbieter-Lock-In?

Hier gibt es eine gute und gleichzeitig eine schlechte Nachricht: Ein Cloud-Lock-In ist nicht schlimm, weil sich die Cloud ohnehin sehr schnell weiterentwickelt. Eine Cloud-Architektur, egal ob mit PaaS oder mit Cloud-agnostischen Komponenten, die vor vier Jahren entworfen und implementiert wurde, ist heute bereits wieder veraltet und muss modernisiert werden. Die Innovationsgeschwindigkeit ist im Moment noch so hoch, dass Applikationen und System-Landschaften stetig angepasst werden müssen. Für die Architekten bedeutet das, dass sie sich weniger Gedanken zu einem Anbieter-Lock-In machen sollten und vielmehr die Architektur für ständige Änderungen auslegen müssen.

Obschon ich in diesem Artikel eine Lanze für die PaaS-Services der Public-Cloud-Anbieter gebrochen habe, heisst das weder, dass ich diese uneingeschränkt empfehle, noch, dass ich Cloud-Anbieter-unabhängige Produkte für schlecht halte. In einigen Szenarien empfehle ich die Evaluation von nicht-proprietären Komponenten, etwa Lösungen aus der Cloud Native Computing Foundation (CNCF) wie Kubernetes oder der Apache Software Foundation wie Apache Kafka. Die Begründung, dass durch den Einsatz solcher Komponenten ein Lock-In reduziert wird, lasse ich aber nicht generell gelten. Dafür muss erst nachgewiesen werden, dass der Lock-In nicht ohnehin schon besteht, durch die Vermeidung des Lock-Ins nicht ein anderer, grösserer Lock-In (oder Lock-Out) eingegangen wird und es muss dargelegt werden, warum der zu vermeidende Lock-In im konkreten Fall schlecht ist.