Cloud Compute Lock-In: Wahrheit und Fiktion
Container sind eine fantastische Möglichkeit, um alles vom Betriebssystem an aufwärts in einem Bereitstellungsartefakt zu erstellen und dieses dann in die Umgebung eines (oder mehrerer) Cloud Partner einzubringen.
Weniger Code mit Higher Level Services
Das identische Artefakt, der Container, wird sequenziell in Entwicklungs-, Test-, Stagingstufen ausgerollt. Nachdem sämtliche Tests, Sicherheitsprüfungen und Validierungen erfolgreich abgeschlossen sind, wird er in die Produktionsumgebung übertragen und den Kunden/Anwendern zur Verfügung gestellt. Darüber hinaus sind wir in der Lage, das Artefakt nach eigenem Ermessen zu aktualisieren, indem wir den neuen Container pushen und die Bereitstellung nahtlos in einem einzigen, zusammenhängenden Vorgang von Test- bis in die Produktionsebene durchführen.
Fokus auf Geschäftslogik
Zusammen mit Functions-as-a-Service (FaaS) und anderen Higher-Level Services hat dies die Menge an Code, welche uns an eine bestimmte Cloud oder Dienstanbieter bindet, drastisch verringert. Während Cloud-Anbieter die Anzahl und Komplexität ihrer Service-Angebote drastisch erhöht haben, bedeuten diese Higher-Level Services oft auch, dass weniger direkte Integration notwendig ist, was zu einer geringeren Bindung an die Datenverarbeitung führt.
Container vereinen Betriebssystem und Anwendungscode in einem Code-Artefakt
Auf der Datenseite ergibt sich nun ein völlig anderes Bild. Da immer mehr Daten erstellt, berechnet, analysiert, übersetzt und integriert werden, sind wir mit einer größeren Verantwortung konfrontiert, wenn es darum geht den Anbieter zu wechseln oder neue Dienste auszuprobieren.
Bis auf wenige Ausnahmen haben Daten beim Wechsel zwischen Anbietern stets eine zentrale Rolle gespielt. Dies gilt insbesondere für die aktuelle Situation, in der der Einfluss von maschinellem Lernen und datenbezogenen Produkten und Diensten, die von Cloud-Anbietern angeboten werden, diese Herausforderung immer weiter vergrößert.
Das bedeutet nicht, dass es einfacher ist, die Datenverarbeitungsschicht durch einen anderen Anbieter zu ersetzen. Für die meisten Unternehmen stellt dies immer noch einen großen Aufwand dar, da umfassende Kenntnisse über die einzelnen Cloud-Anbieter und ihre Dienste erforderlich sind.
Compute Lock-in: kein großes Problem
Eine große Herausforderung, auf die wir bei der Planung vor der Migration häufig stoßen, ist der Versuch, Kubernetes, EKS oder ähnliche Lösungen von anderen Cloud-Anbietern zu implementieren. Obwohl dies zunächst den Anschein erweckt, dass der Wechsel zwischen Anbietern dadurch erleichtert wird, haben wir oft festgestellt, dass das Onboarding beim ersten Anbieter um einiges komplizierter ausfällt.
Der mit der Verwaltung eines Kubernetes-Clusters verbundene Aufwand ist alles andere als minimal, insbesondere bei einfacheren Webanwendungen, bei denen dies möglicherweise nicht erforderlich ist. In der Praxis finden nur selten umfassende Migrationen statt, und wenn, dann betreffen sie in der Regel nur bestimmte Teile des Systems, was zu suboptimalen Setups bei beiden Anbietern führt. Dies behindert oft die Nutzung der besten Kostenoptimierungsstrategien und führt zu erhöhten Ausgaben nicht nur in Bezug auf den Verwaltungsaufwand, sondern auch auf die Infrastrukturkosten.
Fazit
Es gibt zahlreiche Tools wie CDK und Terraform, die beim Aufbau der Recheninfrastruktur helfen, und es gibt kompetente Unternehmen, die Sie bei der optimalen Konfiguration für einen bestimmten Anbieter unterstützen können. Sie zielen darauf ab, den Overhead zu minimieren und bieten die Flexibilität, Rechenlasten bei Bedarf oder wenn es sinnvoll ist, zu migrieren. Falls Sie noch Fragen haben, zögern Sie bitte nicht uns zu kontaktieren - wir beraten Sie gerne.
