ronstik - stock.adobe.com
So vermeiden Sie Vendor-Lock-in mit diesen vier Methoden
Ohne angemessene Planung kann ein Unternehmen in seiner Beziehung zu einem Cloud-Anbieter in die Falle tappen. Befolgen Sie diese Tipps, um ein Hersteller-Lock-in zu vermeiden.
Die Cloud ist eine großartige Ressource, aber manchmal bietet ein Dienstleister, eine Bereitstellung oder eine Architektur nicht das, was Sie brauchen. Durch frühzeitige Maßnahmen können Sie sicherstellen, dass Sie sich nicht an nur eine Cloud-Plattform binden.
Jeder große Public-Cloud-Anbieter unterscheidet sich von anderen, und Sie müssen auf der Grundlage Ihrer Geschäftsziele die richtige Lösung finden. Wenn sich diese Ziele jedoch ändern oder andere Anwendungen bei einem anderen Anbieter besser aufgehoben sind, sollten Unternehmen in der Lage sein, Arbeitslasten zu verschieben und das beste verfügbare Angebot zu nutzen.
Um die Abhängigkeit von einem Anbieter zu verringern, müssen Sie sich zunächst fragen, ob Ihre Anwendung in die Cloud gehört. Stellen Sie dann sicher, dass Ihre Anwendung portabel ist, wenn Sie zu einem anderen Anbieter wechseln müssen.
Befolgen Sie die hier aufgeführten Best Practices, um das bestmögliche Ergebnis für Ihre Anwendung und Ihre Geschäftsziele zu erzielen. Denken Sie jedoch daran, dass die Bindung an einen bestimmten Anbieter nicht immer schlecht ist, wenn sie eine einzigartige Funktion bietet, mit der Sie sich von der Konkurrenz abheben können.
Anwendungen vor der Migration bewerten
Bevor Sie eine Anwendung in die Cloud migrieren, sollten Sie sich fragen, ob diese Arbeitslast überhaupt dorthin gehört. Die Frage, ob eine Anwendung migriert werden soll, war relevanter, als Unternehmen noch unentschlossen über ihre Cloud-Zukunft waren. Eine Ausstiegsstrategie aus der Cloud ist nicht billig. Führen Sie eine gründliche Analyse des potenziellen Nutzens und der Gesamtkosten durch, um spätere negative Auswirkungen zu vermeiden.
Um den Wechsel in die Cloud zu vollziehen, müssen Sie sich auf die Priorisierung, die Machbarkeit und den Business Case konzentrieren. Während dieses Prozesses werden Sie möglicherweise Arbeitslasten entdecken, die entweder komplex sind, mit gesetzlichen Auflagen verbunden sind oder bei denen eine Migration in die Cloud wirtschaftlich nicht sinnvoll ist.
Sie müssen auch die Kosten für die Komponenten berücksichtigen, mit denen die Anwendung verbunden ist. Es gibt viele Unternehmen, die mehrere Hundert Anwendungen in die Cloud migrieren wollen. Die Migration einiger dieser Anwendungen könnte beispielsweise das Budget für das gesamte Jahr überlasten, weil das Unternehmen nicht prüft, wie groß der Speicherbedarf sein wird.
In einigen Fällen könnten die Mehrkosten akzeptabel sein. Zu den wichtigsten Vorteilen, die gegen diese Kosten abzuwägen sind, gehören IT-Effizienz, schnellere Updates und verbesserte Skalierbarkeit.
Verbessern Sie die Portabilität von Anwendungen
Sie sollten überlegen, wie Sie die Portabilität von Anwendungen sicherstellen können. Portabilität bedeutet, dass so wenig Änderungen wie möglich vorgenommen werden müssen, um eine Anwendung von der Umgebung eines Cloud-Anbieters in eine andere zu verschieben. Um diese Änderungen zu minimieren, sollten Sie Dienste nutzen, die in mehreren Clouds verwendet werden.
Es empfiehlt sich, das Design, die Abhängigkeiten und den Technologie-Stack jedes Workloads zu untersuchen. Anschließend sollten sie prüfen, wie sich dies auf die Portabilität in die Cloud und in Zukunft auch zwischen den Clouds auswirkt. Diese Analyse kann dabei helfen, die Kosten spezifischer Maßnahmen gegen den Nutzen des Zugangs zu Cloud-spezifischen Services abzuwägen.
Darüber hinaus ist es ratsam, sich zu fragen, warum eine Firma überhaupt Portabilität anstreben. Beurteilen Sie, wie oft frühere Anwendungen eine Plattform verlassen haben. Wenn dies nicht der Fall war, sollten Sie sich weniger Sorgen um die Portabilität machen. Es gibt nur sehr wenige Fälle, in denen Unternehmen wichtige Workloads zwischen Clouds verschieben.
Ein weiterer Tipp ist es, die Konfiguration von Nicht-Kubernetes-Ressourcen mit einem Cloud-agnostischen Tool durchzuführen, um die Portabilität zu erhöhen. Terraform beispielsweise richtet die Infrastruktur auf verschiedenen Cloud-Plattformen auf die gleiche Weise ein. Cloud-agnostische Tools können sicherstellen, dass sich die Sicherheits-, Compliance- und Betriebskontrollen nicht ändern, selbst wenn sich der Cloud-Service Ihres Unternehmens ändert. Cloud-agnostische APIs, die von mehreren Clouds verwendet werden, wie bei Amazon S3, können ebenfalls hilfreich sein.
Der Aufbau von Portabilität kann die Cloud-Einführung verlangsamen und verteuern. Eine Szenarioplanung kann Unternehmen helfen, eine pragmatische Einschätzung dessen vorzunehmen, was sie in einem Lock-in-Szenario zu verlieren haben. Auf diese Weise können sie Prioritäten setzen, welche Workloads sie aufbauen oder migrieren wollen, die portabler sein müssen als andere.
Nutzung von Containern untersuchen
Die Containerisierung, die eine Abstraktionsschicht verwendet, kann zu Portabilität führen, da sie auf verschiedenen Cloud-Plattformschichten ausgeführt werden kann. Es kann sinnvoll sein, ein Containermodell für Anwendungen zu verwenden, die von einer Aufteilung in Geschäftsfunktionen profitieren würden, die unabhängig aktualisiert oder skaliert werden können.
Andere Anwendungen profitieren jedoch möglicherweise nicht von dieser Änderung der Bereitstellungsarchitektur. Sie können auf Software laufen, die nicht mit einem Container kompatibel ist. Es kann hilfreich sein, einen Konzeptnachweis zu erbringen, wenn man die Umstellung auf einen Container erwägt.
Es kommt hinzu, dass die zugrundeliegende Container-Orchestrierungstechnologie ihre eigenen Elemente des Lock-in haben könnte. Dies erfordert jedoch einen geringeren Aufwand, um die Container-Orchestrierungsschicht zu ersetzen, anstatt eine eng gekoppelte, monolithische Anwendung neu zu schreiben, um eine Hardware-Lock-in-Situation zu beenden.
Darüber hinaus ist es empfehlenswert, den Aufbau einer Abstraktionsschicht zwischen Ihren Anwendungen und dem Cloud-Service umzusetzen. Das Unternehmen Hippo verwendet zum Beispiel Loggly für die Protokollverwaltung. Da die Anwendungen des Unternehmens eine interne Bibliothek zum Senden von Protokollen verwenden, wäre es einfach, zu einem anderen Protokollierungsanbieter zu wechseln. Dank dieser Abstraktionsschicht würde ein solcher Wechsel nur eine einzige Änderung in der Protokollierungsbibliothek und keine Änderungen am Anwendungscode erfordern.
Berücksichtigung der Daten- und Workflow-Abhängigkeiten
Bedenken Sie die Daten, auf die sich die Anwendung stützt. Daten können teurer und schwieriger zu verlagern sein als die Anwendung. Unternehmen müssen entscheiden, ob sie die Daten immer in mehreren Clouds haben wollen, ob sie sie bei Bedarf migrieren oder ob sie sie dort belassen wollen, wo sie sind, und ob sie aus der Ferne darauf zugreifen wollen.
Außerdem sollten sie die Abhängigkeiten von Arbeitsabläufen dokumentieren. Setzen Sie eine Tagging- und Metadatenkonvention durch und verstehen und dokumentieren Sie die Abhängigkeiten von Arbeitsabläufen vor einer Migration.
