Was bedeutet „DIY-Solution“
Technische Lösungen komplett selbst zu entwickeln – der Traum vieler Techniker. Software ohne Lizenzkosten zu verwenden – der Traum vieler Budgetverantwortlicher. Doch ist das wirklich alles, was es im Bezug auf Open-Source zu beachten gilt? Sollte es wirklich so simpel sein? Die Realität ist wie immer komplexer.
Open-Source-Lizenzen und ihre Kosten
Open-Source kommt ohne Lizenzkosten. So ist zumindest die Vorstellung Vieler. Doch Open-Source ist nicht gleich Open-Source. Prinzipiell sagt die Open Source Initiative, dass Open-Source-Software für jeden verfügbar sein soll, unabhängig davon, ob es sich um private oder kommerzielle Nutzer handelt. Dennoch gibt es eine Vielzahl an verschiedenen Lizenzen, z. B. GNU General Public License (GPL), Mozilla Public License (MPL) oder Apache License. Und während z. B. die GPL erfordert, dass eventuelle Anpassungen bzw. abgeleitete Lösungen ebenfalls unter GPL veröffentlich werden müssen, so ist das bei anderen Lizenzen nicht zwingend der Fall. Und das machen sich Hersteller zu Nutzen. So kommt es vor, dass es zu einer frei verfügbaren Open-Source-Lösung zusätzlich eine bezahlpflichtige Enterprise Version eines Herstellers gibt. Die Version beinhaltet oft einen erweiterten Funktionsumfang, welcher nicht selten für Schlüsselfunktionen (z. B. Security oder Compliance) zwingend erforderlich ist. Gleichzeitig bietet der Hersteller in diesem Fall Support für die Lösung.
Reicht jedoch die kostenfreie Variante, so senkt die Wahl das Investitionsvolumen erheblich. Gleichzeitig steigen jedoch die Betriebskosten und ggf. die Entwicklungskosten an. Es ist ein erheblicher Aufwand erforderlich, um eine Plattform aus verschiedenen Open-Source-Lösungen selbst zu bauen. Gleiches gilt für den Betrieb, denn in diesem Fall gibt es keinen Herstellersupport, falls Probleme auftreten.
Open-Source-Entwicklung
Die Entwicklung von Open-Source-Projekten wird zwar oft von großen Unternehmen gefördert, die eigentlichen Entwickler setzen diese jedoch nicht selten in ihrer Freizeit um. Keine der Parteien – Unternehmen oder Entwickler – kann dann zur Verantwortung gezogen werden, wenn Fehler auftreten. Es kommt auch vor, dass Open-Source-Projekte überraschend eingestellt werden oder langsam einschlafen, weil sich die Entwickler anderen Dingen widmen. Darüber hinaus werden weit verbreitete Lösungen beinahe von Einzelpersonen entwickelt (z.B. Log4j). Dieser Umstand macht eventuell auftretende Sicherheitslücken für Unternehmen besonders gefährlich (z.B. Log4Shell).
Auf der anderen Seite steht im Entwicklungspfad von Open-Source-Lösungen das technische Interesse im Vordergrund, die unternehmerische Profitorientierung ist hier meist nachgelagert.
Für jede Person besteht die Möglichkeit, sich selbst direkt in die Weiterentwicklung mit einzubringen und Funktionen selbst zu implementieren, Fehler zu beheben oder Sicherheitslücken zu schließen. Es ist sogar möglich, die Lösung individuell auf die eigenen Gegebenheiten anzupassen. Das kann für ein Unternehmen großes Potential bieten.
All das erfordert jedoch entsprechendes Personal im Unternehmen, welches sowohl die nötigen zeitlichen Ressourcen als auch sehr tiefe Kenntnisse im Umgang mit den jeweiligen Open-Source-Lösungen und deren Entwicklung besitzen muss. Nur dann kann den Risiken begegnet und das Potential ausgeschöpft werden.
Funktionale Anforderungen & Herausforderungen beim Design/Aufbau
In Part eins dieser Serie haben wir bereits die Bedeutung einer guten Bedarfsanalyse beleuchtet. Nehmen wir also an, wir kennen bereits alle Anforderungen, die an unsere Kubernetes-Plattform gestellt werden. Um den Fokus weiterhin auf der Kubernetes-Plattform zu halten, nehmen wir zudem an, dass die notwendige Hardware vorhanden ist und ein Standardbetriebssystem-Template zur Verfügung steht, das alle Anforderungen erfüllt, die im weiteren Verlauf aufkommen würden. Wir können uns nun also der Auswahl der Komponenten widmen.
Die Cloud Native Computing Foundation (CNCF) listet etwa 1.300 verschiedene Softwarelösungen, von denen nicht alle Open Source sind.
Doch was wird davon wirklich benötigt? Offensichtlich Kubernetes selbst. Wer es bereits manuell installiert hat, weiß, dass das nur der Anfang ist. Als Herzstück ist es eine essenzielle Komponente, aber wie jedes Herz ist es allein nicht funktionsfähig.
Kubernetes wurde dazu entwickelt, erweiterbar zu sein und stellt selbst diverse, standardisierte Schnittstellen zur Verfügung. Das bedeutet, dass sehr viele Funktionen, die wir für eine IT-Plattform als selbstverständlich betrachten, nicht als Teil von Kubernetes „in tree“ entwickelt werden, sondern eigenständige Projekte darstellen. Dazu zählen z. B. ein persistenter Speicher, Netzwerk, Userverwaltung und das Layer 3 bis Layer 7 Loadbalancing – allein damit der Kubernetes-Cluster lauffähig ist. Dadurch ist die Produktionsreife jedoch noch nicht erreicht. Hier kommen weitere Plugins bzw. sogenannte Operatoren, z. B. rund um Monitoring, Logging, Security und Backup, ins Spiel.
Für jeden der genannten Bereiche gibt es typischerweise mehrere Optionen: Allein für das clusterinterne Netzwerk existieren 27 verschiedene Plugins. Davon sind 21 Open-Source-Lösungen und eine Mehrfachwahl ist durchaus möglich.
Jede gewählte Komponente muss dabei auf Abhängigkeiten und Kompatibilitäten bzw. Wechselwirkungen mit den anderen Komponenten geprüft werden. Schlussendlich ist es erforderlich, jede gewählte Lösung, inklusive Kubernetes selbst, zu konfigurieren, zu härten und zu automatisieren.
Nicht-funktionale Anforderungen
Neben den funktionalen spielen auch nicht-funktionale Anforderungen für die Auswahl der verschiedenen Operatoren eine Rolle. Einer der Vorteile von Open-Source-Projekten ist es, dass die Entwicklung sehr transparent ist. So lässt sich leicht erkennen, wie viele Entwickler an der Lösung beteiligt sind oder wie aktiv sie weiterentwickelt wird. Für größere, etablierte Open-Source-Projekte gibt es bei der CNCF sogenannte Special-Interest-Groups (SIG), bei denen es Gremien und regelmäßige Meetings gibt, an denen sich jeder beteiligen kann. Auch ist es ersichtlich, ob Projekte von bestimmten Firmen verwaltet werden. Und daraus ist ableitbar, ob eher technische oder firmenspezifische Interessen im Vordergrund stehen.
Hier zeigt sich die Komplexität: Um qualifizierte Entscheidungen treffen zu können, benötigt es bereits vor Beginn der Design- und Auswahlphase umfangreiches Fachwissen. Nur so lässt sich beurteilen, welche Lösungen die Anforderungen wirklich erfüllen.
Dieses Fachwissen aufzubauen, benötigt Zeit und ist neben dem eigentlichen Job kaum zu bewältigen. Ist das Wissen nicht vorhanden, besteht auch die Option einen Hersteller-unabhängigen Dienstleister damit zu beauftragen. Hierbei sollte darauf geachtet werden, dass der Dienstleister das Wissen und die Fähigkeiten auch an das Team im Unternehmen vermittelt und kein Wissensmonopol betreibt, da sonst eine dauerhafte Abhängigkeit zum Dienstleister entsteht.
Schlusswort
Der Bau einer Kubernetes-Plattform in Eigenregie hat etwas von Lego oder IKEA ohne Anleitung. Uns stehen alle möglichen Teile zur Verfügung, allerdings müssen wir selbst herausfinden, wie sie funktionieren und wie wir sie kombinieren. Dies birgt das Potential, am Ende eine maßgeschneiderte, perfekt angepasste Plattform für die eigenen Anforderungen zu haben. Gleichzeitig besteht das Risiko, sehr viel Zeit und somit Geld bei dem Versuch zu verschwenden. Wie man Kubernetes-Plattformen mit Hilfe von Hersteller-Mitteln aufbaut, wird im dritten, noch folgenden Teil unserer Blogserie behandelt.