Auf einen Blick: Vendor Lock-in erschwert Cloud-Computing und schränkt die Möglichkeit der Nutzer ein, den Anbieter zu wechseln. Um dieses Risiko zu mindern, umfassen Best Practices die Bewertung von Technologieabhängigkeiten, die Sicherstellung der Anwendungsportabilität, die Einbindung von Stakeholdern und die Einführung einer Multi-Cloud-Strategie.
- Identifizieren und bewerten Sie die Abhängigkeiten des Technologiestacks.
- Machen Sie Anwendungen portabel und an offene Standards angepasst.
- Entwickeln Sie eine klare Ausstiegsstrategie, um eine Vendor-Lock-in zu vermeiden.
In der Cloud-Welt existieren unsere Workloads überall dort, wo wir tätig sind: über hybride Clouds und verschiedene Managed Services. Aber wenn Sie jemals versucht haben, eine Arbeitslast oder einen Datensatz von einer Cloud in eine andere zu verschieben, sind Sie möglicherweise auf schwieriges Terrain gestoßen. Diese Herausforderung – die Workloads von einem Cloud-Anbieter auf einen anderen zu verlagern – nennt man Vendor Lock-in. Vendor Lock-in tritt besonders im Cloud-Computing auf, wo Nutzer dazu ermutigt werden, sich einfach anzumelden, aber verschiedene Praktiken es den Nutzern erschweren, Daten zu "verlassen" oder zu verschieben. Glücklicherweise gibt es Maßnahmen, die Sie unternehmen können, um Cloud-Vendor-Lock-in zu vermeiden. Schauen wir uns das mal an.
Was ist Vendor Lock-in?
Vendor Lock-in bezieht sich auf die Einschränkungen, die Nutzer daran hindern, einen Dienst zu wechseln. In einer idealen offenen IT-Umgebung können Nutzer frei "liften und verschieben", wie sie möchten – sie können Daten und IT-Workloads von einem Technologiestack zum anderen migrieren, zwischen konkurrierenden Anbietern und geografischen Standorten. Die Welt der Unternehmens-IT ist jedoch nicht immer offen. Dies gilt besonders, wenn proprietäre Technologien, starker Marktwettbewerb und regulatorische Einschränkungen betroffen sind. Einige Anbieter machen es ihren Nutzern besonders schwer, IT-Workloads auf den Service Stack eines Konkurrenten zu migrieren. Das Anerkennen des Nutzungsrechts bedeutet verlorene Einnahmequellen, wenn sie sich nicht auf langfristige Geschäftspartnerschaften festlegen. Anbieter verhindern jedoch nie ausdrücklich, dass Nutzer diese Freiheit ausüben; sie setzen lediglich technische, finanzielle und rechtliche Beschränkungen, die Nutzer davon abhalten. Umgekehrt machen Anbieter es den Nutzern leicht, ihrem Dienst beizutreten:
- Die Anfangskosten für den Einstieg in das Rechnen bleiben niedrig. Aber – sie steigen exponentiell, wenn Nutzer den Dienst skalieren müssen.
- Technische Einschränkungen wie Leistung, Sicherheit, Integration und Kompatibilität mit Technologien konkurrierender Anbieter treten erst in einem späteren Stadium auf.
In vielerlei Hinsicht werden diese Einschränkungen entweder als obskure Details im Kleingedruckten in ihren Nutzungsbedingungen (ToS) angegeben oder können nicht vorhergesehen werden, da sich die technischen Anforderungen des Nutzers unvorhersehbar entwickeln.
Tipps zur Vermeidung von Anbieter-Lock-in
Vendor Lock-in ist ein oft genannter Grund gegen Cloud-Migration. Tatsächlich negiert das Konzept des Lock-ins ein zentrales Wertversprechen der Cloud: ihre Flexibilität. Es gibt jedoch Möglichkeiten, das Risiko einer Vendor-Lock-in durch die Anwendung folgender Best Practices zu verringern.
1. Identifizieren Sie komplexe Abhängigkeiten
Überprüfen Sie Ihren bestehenden Technologiestack. Wenn Ihre IT-Workloads auf Alttechnologien ausgelegt sind, wird Ihre Auswahl an Cloud-Plattformen und Infrastruktur wahrscheinlich eingeschränkt sein.
2. Die Gemeinsamkeiten verstehen
Vergleichen Sie, was zwischen Cloud-Anbietern kompatibel ist, Ihren bestehenden Technologiestack und Ihre technischen Anforderungen. Diese Gemeinsamkeiten sind entscheidend, um die besten Cloud-Lösungen für Ihre Geschäftsbedürfnisse zu bestimmen. Wenn es keinen alternativen Service gibt, müssen Sie Ihre IT-Strategie, Ihre Entscheidung zur Migration und die technischen Anforderungen Ihrer IT-Workloads überdenken.
3. Erwägen Sie ein Upgrade vor der Migration
Wenn Ihre Apps nur mit einer begrenzten Anzahl von Technologien kompatibel sind, sollten Sie zunächst in Erwägung ziehen, einen erheblichen Teil Ihrer Apps zu aktualisieren oder neu zu bearbeiten, bevor Sie in die Cloud-Migration migrieren. Wenn Ihre Apps und IT-Workloads nur mit Alttechnologien funktionieren, die von einigen Cloud-Anbietern unterstützt werden, könnten Ihre zukünftigen Anforderungen, den Dienst auf eine wachsende Nutzerbasis zu skalieren, hohe finanzielle Kosten oder technische Herausforderungen mit sich bringen.
4. Aufklärung der Interessengruppen
Schulungen und Einbindung der Stakeholder sind entscheidend, um die besonderen Risiken von Vendor Lock-in in Ihrem Anwendungsfall zu verstehen. Tech-Teams sollten sich der geschäftlichen Auswirkungen ihrer technischen Entscheidungsentscheidungen bewusst sein. Eine funktionierende Lösung in Form von Anwendungen, IT-Workloads oder einer Rechenarchitektur sollte mit den Geschäftsanforderungen und Risiken übereinstimmen. Bevor Sie IT-Workloads auf einen Cloud-Dienst migrieren, sollten Sie die Lieferanten-Lock-in-Bedenken sorgfältig abwägen, die auf den Anbieter und die vertraglichen Verpflichtungen zugeschnitten sind.
5. Apps portabel machen, im Einklang mit offenen Standards
Diese Praxis gewährleistet eine Vielzahl von Cloud-Alternativen. Viele Cloud-Anbieter unterstützen die meisten offenen Standards in verschiedenen Branchenbereichen. Ein einfacher und effektiver Anbieterwechsel ist einfacher, wenn genügend Alternativen zur Verfügung stehen. Damit dies gelingt, müssen Ihre IT-Workloads nicht-proprietäre Alternativen unterstützen. Wenn Ihre Workloads an die APIs, Konfigurationen und Funktionen proprietärer Technologien gebunden sind, die keine offenen Standards unterstützen, ist eine Vendor-Lock-in wahrscheinlich. Das Versäumnis, offene Standards zu unterstützen, kann später umfangreiche Anpassungen erfordern, um einer Vendor-Lock-in-Situation zu entgehen.
6. Anwendung moderner SDLC-Methodologien
Das Design nach modernen SDLC-Methoden verschafft Ihnen Flexibilität. Zum Beispiel fördert DevOps nicht nur die Nutzung von Open-Source-Technologien, sondern konzentriert sich insbesondere auf die technologische Unabhängigkeit von Cloud-Service-Management und -Operationen. Betrachten Sie Infrastructure as Code (IaC), eine gängige DevOps-Praxis zur Bereitstellung, Verwaltung und Betreibung von Infrastrukturen. IaC automatisiert den Prozess, Infrastrukturkonfigurationen und -abhängigkeiten zu beschreiben, die von einer beliebigen Auswahl zu einem wiederholbaren gewünschten Zustand technologieunabhängigen Designs übergehen.
7. Sicherstellung der Portabilität nach der Migration
Die Datenübertragung von einem Dienst zum anderen, solange sie beim selben Anbieter bleiben, ist oft kostenlos. Bei der Migration zu einem konkurrierenden Dienst wird diese Übertragung jedoch stark berechnet. Bewerten und berücksichtigen Sie diese Kosten, bevor Sie in die Cloud migrieren, basierend auf zukünftigen Anforderungen zur Skalierung cloudbasierter Datenspeicherung und zugehöriger Dienste.
8. Entwicklung einer klaren Ausstiegsstrategie
Cloud-Anbieter können pleitegehen oder drastische Änderungen an ihren Nutzungsbedingungen im Rahmen ihrer gesetzlichen Rechte vornehmen – selbst auf Kosten ihrer Nutzer. Dieses Risiko können Sie verringern, indem Sie eine mögliche Ausstiegsstrategie festlegen. Machbare Bedingungen für den Vertragsausstieg sollten von beiden Parteien vereinbart werden, um es den Kunden zu erleichtern, eine Vendor-Lock-in zu vermeiden.
9. Betrachten Sie eine Multi-Cloud-Strategie
Nutzen Sie mehrere Cloud-Dienste und verteilen Sie Ihre Workloads unabhängig von der zugrunde liegenden Anbieterinfrastruktur. Eine Multi-Cloud-Strategie erfordert, dass Organisationen zusätzliche Schritte zur Optimierung von Kosten, Leistung und Risiko ergreifen, wie zum Beispiel Vendor Lock-in. Indem Sie es richtig machen, werden mehrere bereits erwähnte Risiken natürlich adressiert, da Ihre Apps und Daten von Natur aus auf einer hybriden Mischung mehrerer Cloud-Plattformen betrieben werden können.
10. Machen Sie Ihre Hausaufgaben
Die folgenden Punkte sollten Teil Ihrer Due-Diligence-Strategie sein:
- Entwickeln Sie ein gründliches und genaues Verständnis Ihrer Technologie- und Geschäftsanforderungen. Was wird erwartet, sich zu ändern und wie?
- Bewerten Sie den Markt für Cloud-Anbieter. Überprüfen Sie deren Servicehistorie, Marktreputation sowie die Erfahrungen ihrer Geschäftskunden.
- Verstehen Sie Trends im Cloud-Markt, die Geschäftsmodelle und die Zukunft von Cloud-Diensten.
- Verstehen Sie die rechtlichen Einschränkungen, die für Ihre Cloud-Anwendungsfälle gelten. Gibt es einzigartige Vorschriften für die Vertikalität Ihres Geschäftsbereichs und der IT-Workloads?
- Lesen Sie das Kleingedruckte. Akzeptieren Sie Service Level Agreement (SLA)-Bedingungen und vertragliche Verpflichtungen, die die Möglichkeit eines Lieferanten-Lock-in-Szenarios einschränken.
Kein Wundermittel, um Lock-in zu vermeiden
Abschließend ist es wichtig zu verstehen, dass extreme Maßnahmen zur Vermeidung von Vendor Lock-in unerwünschte Folgen haben können. Open-Source-Umstellung beseitigt den vendor lock-in nicht auf magische Weise. In manchen Fällen können proprietäre Technologien die Performance-, Kosten- oder Sicherheitsrisiken für bestimmte Open-Source-Technologien ausgleichen. Oder sie stellen vielleicht eine andere Lock-in-Situation dar, die sich von proprietären Anbietern unterscheidet. Zum Beispiel können Sie von proprietären AWS-Technologien zu Kubernetes als Open-Source-Lösung wechseln. Wenn Ihre Anwendungen wachsen und komplexer werden, kann es für Ihre IT-Teams eine große Herausforderung sein, all diese Konfigurationsabhängigkeiten und YAML-Dateien zu verwalten, um von Kubernetes auf eine andere Open-Source- oder proprietäre Alternative zu wechseln. In diesem Fall geht es vielleicht nur darum, eine Lock-in durch eine andere zu ersetzen.
Zusätzliche Ressourcen
Für weitere Informationen darüber, wie Sie die Cloud für Ihr Unternehmen zum Laufen bringen, besuchen Sie den BMC Cloud Blog oder schauen Sie sich diese Artikel an:
Diese Beiträge sind meine eigenen und spiegeln nicht unbedingt die Position, Strategien oder Meinung von BMC wider.