Was bedeutet Turnkey-Solution?
Große Kubernetes-Plattformen wie IBMs OpenShift, Broadcoms Tanzu oder SUSEs Rancher sind mittlerweile den meisten bekannt. Darüber hinaus gibt es zahlreiche weitere Lösungen. Jeder Hersteller hat bei der Entwicklung seine eigene Zielgruppe im Blick und bietet entsprechend deren Bedürfnissen verschiedene Funktionen an. Die Bandbreite reicht von einfachen Kubernetes-Cluster-Deployments bis hin zu hochkomplexen Plattformen, die neben CI/CD-Komponenten auch vollständige Entwicklungsumgebungen und die notwendigen Supply Chains mitbringen.
Vorarbeit des Herstellers
Ähnlich wie In-House-Plattform-Teams müssen auch Hersteller entscheiden, welche vorhandenen Open-Source-Lösungen sie in ihre Plattform integrieren und welche Funktionen sie selbst entwickeln. Das bedeutet, auch sie müssen im Vorfeld analysieren, welche Funktionen ihre Kunden benötigen.
Ist die Auswahl der zu verbauenden Komponenten getroffen, folgt die Konfiguration und Integration. Das erfordert ein hohes Maß an Fachwissen und nimmt viel Zeit zum Testen in Anspruch, denn die Komplexität der Kompatibilitäts-Matrizen steigt exponentiell mit der Anzahl der Einzelkomponenten.
Sind diese Herausforderungen überwunden, steht final die Erstellung der Installationsroutine an. Niemand möchte für eine „schlüsselfertige“ Lösung bezahlen, die eine Vielzahl an Skripten und manuellen Schritten zur Installation erfordert. Stattdessen soll ein Installations-Assistent zur Verfügung stehen, der im gleichen Maße einfach, wie auch vollautomatisiert durch den Installationsprozess führt.
Obwohl es verlockend erscheint, sich nicht selbst um all diese Aspekte kümmern zu müssen, ist man gleichzeitig an die Entscheidungen des Herstellers gebunden. Die Automatismen sind oft nur schwer anpassbar, sodass einzelne Teile der Plattform nicht ausgetauscht werden können, wenn der Hersteller dies nicht als Option vorsieht.
Das kann dazu führen, dass man sich den Entscheidungen des Herstellers ausgeliefert fühlt. Zudem wurden alle drei zu Beginn genannten Plattformen in den letzten Jahren von größeren Unternehmen übernommen, was jeweils zu erheblichen Unruhen und Unsicherheiten bei den Kunden geführt hat.
Die Auswahl der passenden Lösung
Nichtfunktionale Anforderungen
Wie bereits in Teil 2 dieser Serie, wird auch diesmal davon ausgegangen, dass die Anforderungen der Stakeholder an die Plattform bekannt sind. Neben den technischen Anforderungen werden häufig auch zusätzliche Bedingungen an den Anbieter gestellt. Beispielsweise könnte der Hersteller EU-Recht unterliegen, das Lieferkettensorgfaltspflichtengesetz einhalten, bestimmte Zertifizierungen vorweisen oder strenge Service-Level-Agreements (SLAs) erfüllen müssen.
Natürlich spielt auch der Preis eine zentrale Rolle. Anders als beim Do-it-Yourself-Ansatz entstehen hier klar erkennbare Investitions- und Wartungskosten, die in der Regel in Form von Subscription-Lizenzen anfallen. Darüber hinaus kann die langfristige Strategie des Anbieters entscheidend sein. Entwickelt sich die Lösung in eine Richtung, die mit den eigenen Anforderungen der nächsten Jahre übereinstimmt? Wie hoch ist die Wahrscheinlichkeit, dass der Hersteller in einigen Jahren noch am Markt ist? Besonders bei kleineren Anbietern besteht ein höheres Risiko, dass sie vom Markt verschwinden oder von größeren übernommen werden.
All diese Faktoren können für eine Vorauswahl der geeigneten Anbieter herangezogen werden, denn die Cloud Native Computing Foundation (CNCF) listet allein für On-Premises-Lösungen 64 verschiedene Anbieter (siehe: CNCF Partner-Übersicht).
Funktionale Anforderungen
Auf technischer Ebene gestaltet sich der Vergleich in der Regel einfacher. Man stellt die Liste der Anforderungen den Funktionen der verschiedenen Lösungen gegenüber. Oft ist es sinnvoll, einen Proof-of-Concept (PoC) mit einer oder mehreren Optionen durchzuführen. So lässt sich nicht nur überprüfen, ob die Lösung die Versprechen tatsächlich hält, sondern man sammelt auch erste praktische Erfahrungen im Umgang mit dem Produkt.
Wenn eine Lösung sowohl auf dem Papier als auch im Proof-of-Concept überzeugt, ist die Entscheidung meist gefallen. Dabei sollte jedoch nicht vergessen werden, dass der Zweck eines Proof-of-Concepts darin besteht, das Konzept zu erproben – nicht, es unmittelbar in die Produktion zu überführen. Für den produktiven Einsatz wird stattdessen eine separate, eigens dafür vorbereitete Umgebung aufgebaut. In diese fließen die Erkenntnisse des Proof-of-Concepts mit ein.
Design/Aufbau
Sobald die Entscheidung für eine Lösung gefallen ist, kann mit dem Aufbau von Know-how begonnen werden. Viele Hersteller bieten gezielte Schulungen für ihre Produkte an, was den Einstieg im Vergleich zum Do-it-Yourself-Ansatz erheblich erleichtert, da man sich nicht mühsam in ein neues Themengebiet einarbeiten muss. Zusätzlich existiert in vielen Fällen bereits umfangreiches Fachwissen am Markt, das genutzt werden kann.
Nach diesem Schritt steht der Umsetzung des Designs nichts mehr im Weg. Obwohl sich die angestrebte Plattform oft komplex darstellt, ist die Basis-Installation deutlich unkomplizierter als beim Do-it-Yourself-Ansatz. Das liegt unter anderem daran, dass sich der Hersteller bereits um grundlegende Aspekte wie Betriebssystem, Installationsprozesse und Standardkonfigurationen gekümmert hat. Außerdem gibt es zahlreiche Whitepaper, Best-Practice-Empfehlungen und Erfahrungswerte, an denen man sich orientieren kann.
Es stimmt, dass die Entscheidungen, die der Hersteller bei der Gestaltung des eigenen Produktes trifft, die individuelle Flexibilität einschränken. Gleichzeitig bieten genau diese vorgegebenen Rahmenbedingungen Sicherheit und Stabilität, insbesondere im laufenden Betrieb.
Nach der Installation der Lösung geht es darum, die Plattform für den produktiven Einsatz vorzubereiten. Die dafür notwendigen Maßnahmen sind individuell, beinhalten aber in der Regel mindestens die Anbindung an bestehende Systeme wie Benutzerverzeichnisse, Monitoring- und Logging-Lösungen sowie das Einrichten eines Backup-Systems. Auch hierbei unterstützt der Hersteller meist mit Kompatibilitätsmatrizen und ausführlicher Dokumentation, um eine reibungslose Integration sicherzustellen.
Day-2-Operations
Ist die Produktionsreife erreicht, kann die Plattform in den Regelbetrieb überführt werden. Dies umfasst nicht nur das kontinuierliche Überwachen und Erweitern der Kapazitäten, sondern auch die Fehlerbehebung. Besonders bei letzterem kann der Hersteller von großem Nutzen sein: Wenn die Plattform unerwartetes Verhalten zeigt oder ein Problem auftritt, das aus eigener Kraft nicht gelöst werden kann, besteht die Möglichkeit, einen Service Request beim Hersteller zu öffnen. Das Support-Team des Herstellers kümmert sich dann um die Problembehebung. Im Gegensatz zum Do-it-Yourself-Ansatz muss hier nicht das eigene Team jedes technische Detail der Plattform beherrschen – diese Verantwortung übernimmt der Hersteller.
Das Gleiche gilt für Updates. Der Hersteller stellt regelmäßig Update-Pakete bereit, zusammen mit entsprechenden Installationsroutinen. Diese Updates wurden bereits im Vorfeld auf Kompatibilität und Stabilität getestet, was den Update-Prozess deutlich erleichtert und die Risiken stark verringert.
Auch eine Turnkey-Lösung muss kontinuierlich weiterentwickelt werden, um den Anforderungen der Benutzer gerecht zu bleiben. Eine „One-Fits-All-(Forever)-Lösung“ gibt es leider nicht. Aber auch bei der Weiterentwicklung unterstützt der Hersteller, entweder durch regelmäßige Updates, die neue Funktionen einführen, oder durch die Verbesserung der Kompatibilität mit Drittanbieter-Lösungen.
Fazit
Auch eine Turnkey-Lösung bringt eigene Herausforderungen mit sich. Oftmals sind dies diffuse Ängste, wie die Abhängigkeit oder das Gefühl der Machtlosigkeit gegenüber dem Hersteller. Leider haben einzelne Fälle in der Vergangenheit diese Bedenken auch bestätigt. Dennoch nimmt der Hersteller einen Großteil der Entwicklungsarbeit ab, erleichtert die Umsetzung erheblich und bietet Support – all das in Zeiten des Fachkräftemangels, in denen Unternehmen oft nicht die Kapazitäten haben, diese Aufgaben selbst zu stemmen.
Häufig schreckt der hohe Preis einer Turnkey-Lösung zunächst ab. Doch selten wird der Vergleich zu den Betriebs- und Entwicklungskosten einer Do-it-Yourself-Lösung angestellt – und noch seltener wird die letztendlich erreichte Qualität in die Gegenüberstellung einbezogen.
Bei der Entscheidung zwischen Do-it-Yourself- und Turnkey-Lösung ist es wichtig, die Größe und die Expertise des Teams zu berücksichtigen, das später die Plattform betreiben wird. In den meisten Fällen muss beides erst aufgebaut werden. Oft empfiehlt es sich, einen externen Dienstleister mit spezialisierten Teams hinzuzuziehen, entweder für die Anfangsphase oder auch für den gesamten Prozess. Hierbei sollte unbedingt darauf geachtet werden, dass der Dienstleister unabhängig vom Hersteller agiert. Nur so kann sichergestellt werden, dass die beste Lösung für den Kunden empfohlen wird – und nicht nur diejenige, die der Dienstleister als Einzige vertreibt oder bei der er den größten Gewinn erzielt.