Sobald ein Altsystem modernisiert werden soll, steht Kubernetes im Raum. Manchmal als Vorgabe von oben, manchmal als Wunsch aus dem Team, oft als Selbstverständlichkeit: Wir containerisieren das und legen es auf einen Cluster.
Die Frage, die dabei übersprungen wird, ist nicht ob Kubernetes gut ist. Es ist ein ausgereiftes Stück Technik, das seine Aufgabe löst. Die Frage ist, ob Sie diese Aufgabe haben.
Dieser Artikel benennt drei Bedingungen, unter denen sich die Plattform rechnet, und zeigt, was vorher billiger dasselbe leistet. Er ist nicht gegen Kubernetes geschrieben, sondern gegen die Reihenfolge, in der die Entscheidung meistens fällt.
Die Vorarbeit, ohne die keine dieser Plattformen etwas nützt, steht in Sessions, Uploads, Konfiguration.
Was vorher passieren muss, egal wohin
Bevor die Zielplattform überhaupt zur Debatte steht, gibt es eine Vorarbeit, die in jedem Fall anfällt, und sie ist der eigentliche Teil der Modernisierung.
Die Anwendung darf nichts auf ihrem Dateisystem ablegen, das sie später wiederfinden will. Sie muss ihre Konfiguration aus der Umgebung lesen und nicht aus einer Datei auf dem Server. Sie muss mehrfach laufen können, ohne dass Sitzungen verloren gehen. Sie muss beim Start sagen, ob sie arbeiten kann, und beim Beenden ihre laufenden Anfragen zu Ende bringen.
Diese Liste ist nicht Kubernetes-spezifisch. Sie gilt genauso für zwei virtuelle Maschinen hinter einem Lastverteiler, für einen verwalteten Containerdienst und für jede Plattform, die es in fünf Jahren gibt. Und sie ist der Teil, der Wochen kostet. Die Plattform darunter zu tauschen, kostet Tage.
Wer die Reihenfolge umdreht und zuerst den Cluster baut, hat in drei Monaten einen Cluster, auf dem eine Anwendung läuft, die genau eine Instanz verträgt. Das ist teurer als vorher und kann weniger.
Drei Bedingungen, unter denen es sich rechnet
Kubernetes löst Probleme, die erst ab einer bestimmten Größe entstehen. Drei davon sind es, die in der Praxis den Ausschlag geben, und sie haben gemeinsam, dass sie ohne Plattform mit Eigenbau beantwortet werden müssten.
Viele Dienste mit eigenen Rhythmen. Ab etwa zehn bis fünfzehn Diensten, die unabhängig voneinander ausgeliefert werden, wird das Verwalten der Weichen, Zertifikate und Zuordnungen selbst zur Arbeit. Genau dafür ist die Plattform gebaut.
Bedarf, der sich stündlich ändert. Nicht der Unterschied zwischen Tag und Nacht, den ein Zeitplan abdeckt, sondern Lastspitzen, die man nicht vorhersagen kann, und ein Verhältnis zwischen Ruhe und Spitze von zehn zu eins oder mehr.
Ein Betriebsteam, das sie betreibt. Die unangenehmste der drei. Ein Cluster ist selbst ein System mit Fassungen, Ablaufdaten, Netzwerkmodell und eigenen Ausfallarten. Wer ihn betreibt, betreibt ab sofort zwei Systeme statt einem.
Fehlt eine der drei, gibt es meistens etwas Einfacheres, das dasselbe leistet. Fehlt die dritte, ist die Plattform unabhängig von den anderen beiden die falsche Wahl, oder sie wird als verwalteter Dienst eingekauft.
Was der Cluster an Wissen verlangt
Die dritte Bedingung klingt weich und ist die harte. Wer sie prüfen will, geht die Liste durch, die ab dem Tag der Inbetriebnahme im Haus liegen muss.
Das Netzwerkmodell und die Frage, wie ein Aufruf von außen an einen Dienst kommt. Die Speicherklassen und was mit einem Datenträger passiert, wenn ein Knoten verschwindet. Die Rechtevergabe innerhalb des Clusters, die eine zweite Berechtigungswelt neben der des Cloud-Anbieters ist. Die Fassungen: Ein Cluster bekommt mehrmals im Jahr eine neue, und jede kann Schnittstellen entfernen, die eine Erweiterung noch benutzt. Und die Knoten selbst, ihre Betriebssysteme und ihre Ablaufdaten.
Nichts davon ist unlösbar, und für vieles gibt es verwaltete Angebote. Der Punkt ist ein anderer: Jede Zeile dieser Liste ist ab jetzt eine Zuständigkeit im Team, und sie kommt zu der Anwendung dazu, die vorher schon niemand vollständig kannte. Wer gleichzeitig ein Altsystem modernisiert und eine Plattform einführt, hat zwei Vorhaben mit je eigenem Risiko und ein Team, das beide nebenbei lernt.
Die brauchbare Reihenfolge ist deshalb, sie zu trennen: erst die Anwendung dorthin bringen, wo sie mehrfach laufen kann, dann in Ruhe entscheiden, worauf.
Was zwischen zwei Maschinen und einem Cluster liegt
Die Entscheidung wird meistens als Alternative zwischen zwei Enden geführt: alles bleibt wie es ist, oder Cluster. Dazwischen liegt mehr, als die Diskussion zulässt.
Container ohne Orchestrierung. Ein Abbild zu bauen ist wertvoll für sich: Es macht die Umgebung reproduzierbar, macht den Unterschied zwischen Test und Produktion sichtbar und ist die Vorarbeit für jede spätere Plattform. Zwei Maschinen, die dasselbe Abbild starten, sind ein tragfähiger Betriebszustand.
Ein verwalteter Containerdienst. Wer Container will, ohne einen Cluster zu betreiben, bekommt bei jedem großen Anbieter eine Zwischenstufe, die Abbild, Skalierung und Rollout übernimmt und deren Betriebsaufwand bei null liegt. Für einen einzelnen Monolithen ist das in den meisten Fällen die richtige Antwort.
Zwei Maschinen und ein Lastverteiler. Unterschätzt und für viele Systeme völlig ausreichend. Damit lassen sich Ausrollen ohne Ausfall, ein Rückweg in einer Minute und stufenweises Umschalten abbilden, und der Betriebsaufwand ist der, den das Team schon kennt.
Diese drei decken den Bedarf der allermeisten Anwendungen ab, die heute auf einem Server liegen. Der Sprung auf die Plattform lohnt erst, wenn die Zahl der Dienste ihn erzwingt.
Dass ein Ausrollen ohne Ausfall keine Orchestrierung braucht, steht in Blue/Green und Canary ohne Kubernetes.
Wenn die Entscheidung trotzdem gefallen ist
Manchmal ist die Frage nicht mehr offen. Der Konzern betreibt einen Cluster, die Plattform ist Vorgabe, und die Anwendung soll dorthin. Das ist ein legitimer Grund, und dann geht es nur noch um die Reihenfolge.
Die Reihenfolge ist dieselbe wie oben, nur mit bekanntem Ziel. Zuerst die Anwendung mehrfach lauffähig machen, dann das Abbild, dann die Bereitschaftsauskunft, dann der Umzug. Der Umzug ist der kürzeste Teil.
Zwei Dinge kosten dabei regelmäßig mehr Zeit als geplant, und beide haben nichts mit der Anwendung zu tun. Das eine sind die Stapelläufe und zeitgesteuerten Aufgaben, die im Altsystem in einer Cron-Datei stehen und auf der Plattform ein eigenes Objekt mit eigener Fehlerbehandlung brauchen. Das andere sind die Zugriffe nach außen: feste Quelladressen, Datenbankfreigaben, Zertifikate von Partnern. In einem Cluster ändert sich die Adresse, aus der ein Aufruf kommt, und die Freigabe beim Partner läuft über dessen Formular und nicht über Ihre Pipeline.
Die Frage, die vorher beantwortet wird
Damit die Entscheidung nicht in einer Geschmacksfrage endet, hilft eine einzige Frage, und sie ist unangenehm konkret.
Welches Problem, das wir heute haben, verschwindet damit, und woran würden wir es merken?
Gibt es darauf eine Antwort mit einer Zahl, ist die Entscheidung gefallen und begründet. Lautet die Antwort „wir wären moderner aufgestellt" oder „alle machen das", dann ist es keine Entscheidung, sondern eine Anschaffung, und sie kostet drei Monate, die an anderer Stelle fehlen.
Was in dieser Zeit stattdessen möglich wäre, ist selten aufregend und fast immer wirksamer: die Anwendung mehrfach lauffähig machen, ein Ausrollen ohne Ausfall, ein Rückweg, der ein Schalter ist. Wie ich Auslieferungswege baue, steht auf einer eigenen Seite.
Dieser Artikel setzt eine Reihe über Systeme fort, die es schon gibt. Der Rückblick über die ersten drei Monate ordnet ihre Artikel nach Anlass.
