Die OpenShift Container Platform (OCP) ist der Platzhirsch unter den selbstgehosteten Enterprise-Kubernetes-Plattformen. Aber welchen Vendor Lock-in gehen Sie mit OpenShift ein?
RedHat selbst bewirbt sein Produkt damit, dass sie zum einen die Flexibilität von Kubernetes aufrechterhalten, gleichzeitig aber die Komplexität reduzieren. Das erreichen sie dadurch, dass sie pro Operator viele Konfigurationen vorgeben, die die Kunden dann schwierig verändern können.
Im Ergebnis führt das dann zu einer vergleichbar einfach zu betreibenden und gleichzeitig mächtigen und sicheren Container Plattform.
Allerdings führt diese vermeintliche Komplexitätsreduktion dazu, dass Sie als Platform Owner Funktionen untergejubelt bekommen, die zwar bequem sind, dabei aber den Vendor Lock-In Effekt erhöhen.
Damit Sie das Risiko einschätzen und sich Ihre Strategie zurechtlegen können, nehmen wir in diesem Artikel zwei exklusive OpenShift-Funktionen unter die Lupe. Beide sind schon lange im Produkt verbaut und äußerst nützlich und beliebt.
Für diese Analyse verwenden wir mein System zur Identifikation und Reduktion des Vendor Lock-Ins.
Die Spezialfunktionen kurz erklärt
OpenShift bietet einige Funktionen, die über die Standardfunktionen hinausgehen oder weitere Möglichkeiten hinzufügen. Zwei sehr beliebte Funktionen sind:
Diese sind exklusiv in OpenShift verbaut. Setzen Sie diese Funktionen ein, dann erhöhen Sie automatisich Ihr Vendor Lock-in-Risiko.
OpenShift Routes vs. Kubernetes Ingress
OpenShift Routes ist die Art, wie OpenShift den Zugriff von außen auf die Services innerhalb des Clusters zulässt. Es ist eine alternative Lösung zum Standard Kubernetes Ingress, der laut RedHat maßgeblich von OpenShift Route beeinflusst wurde.
Inzwischen ist die Nutzung von Ingress in OpenShift adaptiert worden, sodass die Nutzung von OpenShift Routes optional ist. Möchten Sie allerdings beispielsweise erweiterte Security-Features wie Ende-zu-Ende Verschlüsselung durch „re-encrypt“ oder „passthrough“ nutzen, kommen Sie an den OpenShift Routes nicht vorbei.
OpenShift Builds vs. CI/CD-Pipelines
OpenShift Builds erweitert die CI/CD-Möglichkeiten innerhalb von OpenShift. Es steht also auf gleicher Stufe wie
Die Funktion Builds existiert bereits seit der ersten auf Kubernetes basierenden OpenShift Version 3.0. Der Zweck ist es, nativ im Cluster Images zu bauen, die dann verwendet werden können.
In meinem damaligen Projekt 2016 war das etwas Revolutionäres. Vor allem die beliebte Source2Image Funktion half uns damals, schnell und mit wenig Aufwand Container Images unserer Microservices zu erstellen und diese in der Container Registry des OpenShift als Image Streams abzulegen.
Kurz gesagt: OpenShift Builds war zum damaligen Zeitpunkt einer der Faktoren, der unseren Projekterfolg überhaupt erst möglich gemacht hat. Seitdem habe ich viele alternative Lösungen gesehen und verwendet – mit einem eindeutigen Ergebnis: an die Einfachheit und Zuverlässigkeit von der Builds-Funktion kommen die modernen CI/CD-Lösungen kaum heran.
Allerdings hat es eine nicht zu verachtende Kehrseite: Wenn Sie OpenShift Builds einsetzen, sitzen Sie tief in der Vendor Lock-in-Falle. Haben Sie die Nutzung dieser Funktion erst einmal etabliert, dann haben Sie potenziell sehr hohe Kosten, wenn Sie von OpenShift zu einer anderen Kubernetes-Lösung wechseln wollen.
Szenario: Vendor Lock-in durch OpenShift bewerten
Nachdem wir uns mit den beiden Funktionen von OpenShift vertraut gemacht haben, geht es nun ans Eingemachte.
Stellen Sie sich folgendes Szenario vor:
Sie sind der zukünftige Platform Owner des mittelständische Handelsunternehmen Müller & Töchter GmbH.
Gemeinsam mit Ihrem IT-Leiter und dem Geschäftsführer haben Sie erkannt, dass Sie Ihre IT auf den aktuellen Stand bringen müssen, wenn Sie weiterhin am Markt erfolgreich sein wollen.
Für die Weiterentwicklung beauftragt der IT-Leiter ein paar IT-Dienstleister, die die passende Individualsoftware entwickeln sollen. Sie erhalten von Ihm den Auftrag, gemeinsam mit Ihrer IT-Architektin eine Entwicklerplattform auf Basis von Kubernetes aufzubauen und zu betreiben.
Jetzt stehen Sie vor dem Scheideweg – Welche Kubernetes-Distribution darf es denn sein?
Ihr Unternehmen hat drei erfahrene Linux Administratoren und langjährige positive Erfahrung mit RedHat gesammelt. Deshalb entscheiden sie sich, die OpenShift Container Plattform zu evaluieren.
Aus bitterer Erfahrung kennt Ihre IT-Architektin das Problem des Vendor Lock-in Risikos. Deshalb stellen Sie gemeinsam folgende Bewertung an:
Schritt 1: Ihre Chancen und Risiken des Vendor Lock-ins identifizieren
Im ersten Schritt identifizieren Sie mit Ihrer IT-Architektin die Chancen und Risiken bei der Nutzung der proprietären Features von OpenShift. Dabei fokussieren Sie sich auf die beiden Funktionen OpenShift Builds und OpenShift Routes.
| Chancen | Risiken |
|---|---|
| Generell: OpenShift ist ein Enterprise-Produkt mit gutem Support und viel existierendem Know-How. Damit erwarten Sie dass ihr Aufwand im Vergleich zum Eigenbau deutlich geringer ist und die Lernkurve nicht so steil. | Generell: Durch den Einsatz von OpenShift sind Sie bereits sehr eingeschränkt, was den Funktionsumfang angeht. Ein großer Teil der Technologie-Entscheidungen wird von dem Hersteller RedHat getroffen. |
| OpenShift Builds: Wenn Sie OpenShift Builds einsetzen, sparen Sie sich die Komplexität moderner CI/CD-Pipelines. | OpenShift Builds: Sie begeben sich in einen Vendor Lock-in. Sollten Sie einmal von OpenShift weggehen, müssen Sie Ihr gesamtes CI/CD-Konzept umbauen und neue Technologien einführen. |
| OpenShift Routes: Routes bieten im Gegensatz zu Ingress die Möglichkeit einer echten Ende-zu-Ende-Verschlüsselung. Wenn das eine Anforderung ist, dann kommen Sie nicht drumherum. | OpenShift Routes: Sollte Ihnen die einfache Ende-zu-Ende Verschlüsselung bis zum Service ausreichen, dann riskieren Sie eine Sisyphos-Arbeit, wenn sie alle Routen nachträglich durch Ingress ersetzen müssen. |
| … | … |
Schritt 2: Ihre Strategie wählen
Nachdem Sie einen Überblick über die Chancen und Risiken gesammelt haben, entwickeln Sie im zweiten Schritt Ihre konkrete Strategie, mit der Sie sicherstellen werden, dass Sie nicht in die Vendor Lock-in Falle tappen.
Exit-Strategie
Die Exit-Strategie besagt, dass Sie sich einen Flucht-Plan für den Vendor Lock-in zurechtlegen. Ihr IT-Architekt hat durch die Chancen- und Risiko-Bewertung allerdings bereits festgestellt, dass Sie mit Ihrem Unternehmen und Ihren konkreten Anforderungen einfach auf die Vendor Lock-Funktionen verzichten können, ohne sich einschränken zu müssen. Deshalb ist der Flucht-Plan offensichtlich: Sollte es Probleme mit OpenShift geben, lässt sich Ihre zukünftige Plattform einfach mit den verfügbaren Mitteln nachbauen.
Multi-Strategie
Die Multi-Strategie besagt, dass Sie im Zweifel auf mehrere Anbieter setzen. Da die Technologien, die Sie einsetzen werden, frei verfügbar sind und Sie damit keinen nennenswerten Vorteil von dem parallelen Betrieb mehrerer Entwicklerplattformen haben, können sie auf den zusätzlichen Aufwand verzichten.
Offene-Standards-Strategie
Die Offene-Standards-Strategie besagt, dass Sie sich ausschließlich auf offen verfügbare Standards verlassen. Im betrachteten Fall hat sich die Strategie von RedHat mit OpenShift genau in diese Richtung bewegt. OpenShift Builds spielt neben den frei verfügbaren Tekton und ArgoCD keine große Rolle mehr. Auch der Nutzen von OpenShift Routes gegenüber dem freien Standard Ingress ist für die Müller & Töchter GmbH ist nicht ausreichend, um das entstehende Vendor Lock-in Risiko zu tragen.
Ihre IT-Architektin wählt deshalb die Offene-Standards-Strategie, weil sie am besten zur Weiterentwicklungsstrategie von OpenShift passt. Damit können Sie als Platform Owner Ihren IT-Dienstleistern klar umreißen, wie Ihre Ziel-Plattform aussehen wird und welche frei verfügbaren Standard-Technologien sie für ihr jeweiliges Projekt beherrschen müssen.
Schritt 3: Ihre Maßnahmen ableiten und priorisieren
Auf Basis der identifizierten Chancen und Risiken und der gewählten Strategie ist es für den nun einfach, geeignete Maßnahmen abzuleiten und diese zu priorisieren.
Diese Maßnahmen liegen durch die bisherige Analyse auf der Hand:
- Pipeline-Operator in Betrieb nehmen
- OpenShift Builds deaktivieren
- Enablement für Pipeline-Operator aufbauen
- Nutzung von OpenShift Routes untersagen
- Enablement für Ingress aufbauen
- Plattform regelmäßig nach Routes-Objekten durchforsten
Aus dieser priorisierten Liste lassen sich einfach User Stories ableiten und in ein Product Backlog einplanen.
Fazit: OpenShift macht es uns einfach – in zweierlei Hinsicht
Das ist die ganze Magie, mit der Sie verhindern, in die Vendor Lock-in Falle zu tappen. Allerdings unter folgendem Hinweis: OpenShift macht es seinen Kunden seit einiger Zeit leicht, den Vendor Lock-in zu vermeiden und glänzt durch einfachen Aufbau, gute Dokumentation und einem durchdachten Konzept.
Als Platform Owner sollten Sie dennoch gewarnt sein. OpenShift macht viele (gute) Vorgaben, welche Technologien wie kombiniert und konfiguriert werden müssen. Sie haben dort kaum Mitspracherecht. Dafür bekommen Sie einen Enterprise Support und eine gute Dokumentation, mit der Sie mit wenig Risiko eine funktionale Container-Plattform einrichten und betreiben können.
Stehen Sie vor einer Entscheidung, zum Beispiel für den Einsatz einer Container Plattform, bei dem Sie Ihr Vendor Lock-in Risiko bewerten, eine Strategie entwerfen und Maßnahmen ableiten müssen? Dann nutzen Sie gerne dieses Vorgehen – es hat sich seit Jahren in den unterschiedlichsten Unternehmen bewährt!
Möchten Sie diesen Weg nicht allein gehen, kommen Sie gerne auf mich zu. Wir schauen uns Ihre konkrete Situation an und überlegen, ob und wie ich Ihnen zur Seite stehen kann.
Bis dahin wünsche ich Ihnen ein gutes Gelingen!