Foto: Robert Mandel | shutterstock.com
Ich sage es jetzt einfach ganz direkt: Wenn man sich die Total Cost of Ownership (TCO) von Kubernetes einmal genauer ansieht, bieten traditionellere Entwicklungsmethoden immer noch überzeugende Vorteile. Wenn Sie sich jetzt eventuell fragen: "Was läuft mit dem Linthicum nur falsch?" - lassen Sie mich erklären (wie ich zur anfänglichen Behauptung komme).
Ich nutze Container und Kubernetes schon, seitdem sie vor etlichen Jahren erstmals auf der Bildfläche der Cloud-Computing-Szene erschienen sind. Ich habe zudem mit der Technologie zahlreiche skalierbare Systeme in Public Clouds entwickelt. Von daher weiß ich, dass sie funktioniert - und zwar gut. Zu gut, denn das führt leider dazu, dass sie im Übermaß eingesetzt wird. Das kommt (unter anderem) davon, dass sich Systementwickler lieber davon inspirieren lassen, was gerade "cool" ist, anstatt die Lösung zu finden, die den größten Mehrwert für das Business liefert. Das Resultat: Millionenbeträge werden durch architektonische Fehler verbrannt. Höchste Zeit, es besser zu machen.
Kubernetes - worauf es ankommt
Die folgenden Punkte können auf Sie, respektive Ihr Unternehmen zutreffen - oder auch nicht. "Es kommt darauf an", mag vielen wie eine allgemeingültige Ausrede erscheinen, ist mit Blick auf Kubernetes aber eben oft die richtige Antwort: Sie sollten jeden Workload und jeden Datensatz evaluieren - egal, ob Sie in die Cloud migrieren oder neue Systeme aufbauen. Es kommt darauf an, die besten technologischen Lösungen für Ihre individuellen Bedürfnisse einzusetzen. Dabei sollten Sie bedenken:
Kubernetes bringt ein Komplexitäts-Level mit sich, der sich von dem herkömmlicher Entwicklungs-Tools abhebt. Ein Kubernetes-Cluster zu managen, erfordert ein tiefgehendes Verständnis der zugrundeliegenden Architektur und seiner Komponenten - von Networking über Storage bis hin zu Security. Diese Komplexität erfordert entsprechend qualifiziertes Personal. Im Kontrast dazu beruhen traditionelle Entwicklungsansätze und -Tools oft auf simpleren Architekturen, die oft mit bereits vorhandenen Kompetenzen gemanagt werden können. Die Kosten, um Kubernetes-Knowhow einzukaufen oder die vorhandene Belegschaft entsprechend zu schulen, übersteigen den Nutzen der Technologie in der Regel deutlich.
Ein Kubernetes-Cluster braucht massiven Overhead - obwohl die Versprechung eigentlich lautet, dass die Infrastrukturkosten durch effiziente Container-Orchestrierung sinken. Ursächlich dafür sind die Knoten, aus denen die Cluster bestehen und die Ressourcen, die in Sachen Failover-Management benötigt werden. Eine Infrastruktur, um Redundanz und Skalierbarkeit zu managen, wäre außerdem hilfreich. Am Ende bezahlen Sie möglicherweise für deutlich mehr Ressourcen, als Sie überhaupt benötigen. Traditionelle Entwicklungsansätze verwenden möglicherweise eher monolithische Architekturen. Die resultierende, geringere Flexibilität kann zu geringeren Anfangsinvestitionen und niedrigeren laufenden Kosten führen. Natürlich kann es auch andere Gründe dafür geben, auf Kubernetes zu setzen - abgesehen von der Tatsache, dass es sich gut im Lebenslauf macht.
Eine Kubernetes-Umgebung zu warten, ist aus betrieblicher Perspektive eine Herausforderung. Continuous Monitoring, Feintuning und Updates sind erforderlich, um sicherzustellen, dass diese sicher, effizient und zuverlässig ist. Auch für die fortlaufende Wartung sind qualifizierte Mitarbeiter und moderne Tools erforderlich, was die TCO in die Höhe treibt.
Kubernetes initial einzurichten und zu konfigurieren, kann einen enorm zeitaufwändigen und komplexen Task darstellen - trotzdem die Orchestrierungslösung Deployment-Prozesse automatisieren und rationalisieren kann. Das kann dazu führen, dass die Bereitstellungszeit und die Time-to-Market für viele Systeme steigt. Zudem erhöht sich die Wahrscheinlichkeit, dass Fehler auftreten. Herkömmliche Entwicklungs- und Bereitstellungsmethoden können zwar in Sachen Automatisierung und Skalierbarkeit nicht mithalten, sind für bestimmte Applikationen allerdings oft einfacher und schneller zu implementieren.
Verteilte Systeme bringen neue Risiken und Fehlerquellen mit sich. Kubernetes und Container-basierte Deployments sind hochskalierbar und bieten eine hohe Fehlertoleranz. Aber sie werfen auch Probleme auf, die es bei der traditionellen Softwareentwicklung nicht gibt. "Container Sprawl" beispielsweise oder Schwachstellen im Container-Ökosystem. Aus meiner Erfahrung kann ich nur sagen, dass es keine Frage ist, wann bei Kubernetes-Deployments ein Fehler auftritt - vielmehr, wie viele es sind. Herkömmliche Architekturen sind nicht in gleichem Maße skalierbar, bieten dafür aber eine in sich geschlossene Umgebung, die leichter abzusichern und zu managen ist. Das resultiert in geringeren Kosten, aber auch weniger Möglichkeiten. Manchmal muss man eben (sinnvolle) Kompromisse machen.
Darum TCO-Analyse!
Eine ordentliche TCO-Analyse ist etwas, das mit Blick auf Kubernetes und Container in vielen Fällen nicht stattfindet. Die Unternehmen, die sich für die Technologie entscheiden, haben in vielen Fällen keinen Überblick über die Kompromisse, die sie dafür eingehen müssen. Wenn auf Nachfragen zu den Benefits traditioneller Entwicklungsansätze nur leere Blicke und Schweigen folgen, ist das ein Anzeichen dafür, dass die TCO-Analyse ausfallen musste.
Die Komplexität und die Kosten die entstehen, wenn eine Kubernetes-Umgebung gemanagt werden muss, machen klar, dass traditionelle Entwicklungs- und Deployment-Methoden immer noch eine Daseinsberechtigung haben. Gerade Unternehmen mit begrenzten IT-Ressourcen müssen tatsächlich auf die Gesamtbetriebskosten achten. Und das Geld, das für Kubernetes-basierte Systeme ausgegeben wird, wird an anderer Stelle möglicherweise viel dringender benötigt. Ich für meinen Teil kenne keine einzige IT-Organisation, die über unbegrenztes Budget verfügt und nach Lust und Laune mit sämtlichen neuen Technologien experimentieren kann. (fm)
Dieser Beitrag basiert auf einem Artikel unserer US-Schwesterpublikation Infoworld.