Auto-Scaling, Auto-Healing, Load Balancing: Was ein Cluster kann, steht auf jeder Anbieterseite. Was ein IT-Leiter wissen will, steht dort seltener. Was passiert, wenn es dienstags um zehn klemmt? Und rechnet sich dieser Apparat für eine einzelne Fachanwendung überhaupt?
Wo Ihre Anwendung läuft, entscheiden Sie
Was wir ausliefern, ist ein Paket und kein Zugang zu unserer Plattform. Darin liegen die Container-Abbilder aller Dienste und eine deklarative Beschreibung, wie sie zusammengehören: welche Instanzen, welche Bereitschaftsprüfungen, welche Speicher, welche Verbindungen nach außen. Wo es ausgeführt wird, ist eine getrennte Frage.
Möglich ist das, weil im Laufweg nichts steckt, was es nur bei einem Anbieter gibt: Container, Kubernetes, Helm, eine Standard-Datenbank, ein Nachrichtenbus, cert-manager für die Zertifikate. Kein verwalteter Cloud-Dienst, an dem ein Umzug scheitert.
Das ist die praktische Seite dessen, was auf Folien „kein Vendor-Lock-in“ heißt: Läuft eine Anwendung nur in der Laufzeitumgebung ihres Herstellers, ist der Wechsel eine Neuentwicklung; sind es gewöhnliche Container, ist er eine Umzugsplanung. Die Datenschutzseite behandelt Low-Code im eigenen Rechenzentrum, die Vertragsseite Vendor-Lock-in bei Low-Code.
Dasselbe Paket, verschiedene Betriebsorte
Wo das Paket ausgeführt wird, ist eine Entscheidung, und keine Eigenschaft der Anwendung.
Wir übernehmen Überwachung, Alarmierung, Sicherungen, Zertifikate und Sicherheitsupdates, der Normalfall ohne eigenes Container-Betriebsteam.
wir betreiben
Eigene Maschine, eigene Datenbank, eigene Zugangsdaten. Hier läuft kein Kubernetes, sondern ein schlanker Container-Stack. Für ein Dutzend Container rechnet sich ein Orchestrator nicht.
ein Kunde, eine Maschine
Sie erhalten Abbilder, Deployment-Beschreibung und Dokumentation und fahren die Anwendung selbst, die Betriebsverantwortung liegt bei Ihnen.
Ihr Cluster, Ihre Hoheit
Was Kubernetes an einem Dienstagvormittag tut
Zehn Uhr, Monatsabschluss, vierhundert Menschen arbeiten gleichzeitig. In diesem Moment verabschiedet sich einer der Dienste. Ohne Orchestrierung ist das ein Anruf beim Systemhaus und eine halbe Stunde Stillstand.
Mit Orchestrierung laufen von diesem Dienst ohnehin mehrere gleichwertige Instanzen, absichtlich auf verschiedene Maschinen verteilt. Jede beantwortet laufend zwei Fragen: „lebst du?“ und „bist du bereit?“. Die kranke Instanz antwortet auf die zweite nicht mehr, wird aus der Lastverteilung genommen, Ersatz startet. Niemand ruft an.
Dass diese beiden Fragen getrennt sind, ist der Unterschied zwischen ruhigem und unruhigem Betrieb. Die Lebendigkeitsfrage prüft bei uns nur, ob der Prozess selbst reagiert, bewusst ohne Datenbank und Nachbardienste. Sonst führt ein kurzer Schluckauf der Datenbank dazu, dass reihenweise gesunde Dienste abgeschossen werden, und aus zehn Sekunden Störung werden zehn Minuten Ausfall.
Mehr Nutzer heißt mehr Instanzen, nicht ein größerer Server
Wächst die Last, wird nicht die Maschine getauscht, sondern es kommen Instanzen hinzu, nach Auslastung oder nach Uhrzeit. Der zweite Weg wird unterschätzt: Beginnt die Schicht um sieben und endet um neunzehn Uhr, fährt die Anwendung morgens hoch und abends zurück.
Die Einschränkung: Nicht alles skaliert waagerecht. Dienste mit genau einem Schreiber, fortlaufende Nummernkreise etwa, sind davon ausgenommen.
Entwicklung, Test und Produktion bleiben getrennt
Getrennte Umgebungen sind kein Selbstzweck, sondern die Voraussetzung dafür, dass ein Update scheitern darf, wo es nicht wehtut. Wichtiger als ihre Zahl ist die Regel, was zwischen ihnen fließen darf, und dort liegt der häufigste Datenschutzfehler in Softwareprojekten: Produktionsdaten landen zu Testzwecken in einer Umgebung mit anderen Zugriffsrechten, anderer Protokollierung und oft auch externen Dienstleistern. In Test- und Entwicklungsumgebungen gehören deshalb keine Produktionsdaten. Was dort liegt, ist entweder erfunden oder vor der Übernahme bereinigt. Das ist ein eigener Schritt im Projekt, den jemand verantwortet, und keine Funktion, die von allein läuft.
Der Weg in die Produktion ist zudem kein Anfassen der Produktion. Der Soll-Zustand jeder Umgebung liegt als lesbarer Text im Repository, eine Änderung ist eine geprüfte Freigabe, und der Cluster holt sich diesen Zustand selbst. Rollback heißt: Freigabe zurücknehmen. Zugangsdaten liegen nie im Repository, sondern in SOLUTIONS.vault.
Überwachung und Sicherungen im laufenden Betrieb
„Betrieb“ ist das Wort, unter dem in Angeboten die Arbeit verschwindet, die nach Projektende beginnt. Kubernetes startet einen abgestürzten Dienst neu. Es merkt nicht, dass eine nächtliche Schnittstelle seit vier Tagen leere Dateien liefert. Dafür braucht es Überwachung, die etwas Fachliches misst, und Protokolle, die eine Frage beantworten. Wir setzen dafür auf den offenen Standardkasten: OpenTelemetry als gemeinsame Sprache für Messwerte, Protokolle und Aufrufspuren, Prometheus als Messwertspeicher, Loki für die Protokolle, Grafana als Oberfläche darüber. Wollen Sie selbst hineinsehen, bekommen Sie einen Zugang; das ist eine Einstellung und keine Sonderleistung. Jede Protokollzeile trägt die Kennung ihres Vorgangs; ein Fehlerbericht lässt sich damit über alle beteiligten Dienste rekonstruieren, bis hinunter zum Fehler, den der Browser des Sachbearbeiters gemeldet hat.
Bei den Sicherungen zählt vor allem die Trennung der Fehlerdomänen: ein täglicher Datenbankauszug in einen getrennten Speicher, zusätzlich Momentaufnahmen der Datenträger, zwei Verfahren mit unterschiedlichen Schwächen. Gelesen wird der Auszug vom Zweitknoten, damit der laufende Betrieb nicht leidet.
Fragen an jeden, der Ihre Anwendung betreiben soll
Auch an uns. Die Antworten unterscheiden Betriebsvertrag von Hosting-Paket.
Nicht: Wird gesichert. Eine Sicherung, die nie wiederhergestellt wurde, ist eine Vermutung. Lassen Sie sich das Verfahren zeigen.
Ein Dashboard, in das niemand schaut, ist keine Überwachung. Entscheidend ist die Schwelle, ab der ein Alarm bei einer Person ankommt.
Versionen müssen festgenagelt sein, sonst ist nicht reproduzierbar, was läuft. Sicherheitskorrekturen zügig, funktionale Aktualisierungen über den getesteten Weg.
Erneuerung automatisch, plus Alarm bei hängendem Vorgang. Abgelaufene Zertifikate sind der häufigste vermeidbare Ausfall.
Wann sich ein Cluster lohnt, und wann er zu viel ist
Kubernetes ist für eine einzelne kleine Fachanwendung überdimensioniert und teuer. Der Cluster selbst will betrieben werden: Steuerungsebene, Netzwerk, Zertifikate, Überwachung, dazu ein bis zwei Versionswechsel im Jahr. Der Aufwand fällt an, ob eine oder zwanzig Anwendungen darin laufen. Bei zwanzig Nutzern zahlen Sie ihn für Ausfallsicherheit, die Sie nie brauchen.
Wir fahren selbst beide Wege. Unsere eigenen rund zehn Anwendungen laufen im Cluster, bei dieser Zahl trägt er sich: Dort beschreiben Helm-Charts im Repository den Soll-Zustand, und Flux hält ihn nach. Geht es dagegen um eine getrennte Instanz mit einer oder zwei Anwendungen, fahren wir eine eigene Maschine hoch, mit den Containern darauf und ohne Cluster darum herum; die beschreibt Terraform. Gemeinsam ist beiden Wegen, dass eine Änderung über das Repository geht und nicht über eine Konsole. Dieselbe Betriebsdisziplin, unterschiedlich viel Apparat.
Für eine überschaubare Anwendung sind eine gepflegte virtuelle Maschine, ein schlanker Container-Stack, eine tägliche Sicherung mit geprüftem Rückweg und automatisch erneuerte Zertifikate günstiger und ruhiger. Uns kostet das nichts, Ihnen erspart es eine Investition, die sich nicht rechnet.
Sobald SOLUTIONS.user, SOLUTIONS.email, SOLUTIONS.transformer und SOLUTIONS.dashboard als eigene Dienste laufen, wird die Abstimmung von Hand zur Hauptarbeit.
Kostet eine Stunde Stillstand Umsatz, Lieferfähigkeit oder eine Frist, ist die Rechnung einfach. Kann die Abteilung notfalls später weiterarbeiten, ist sie ebenso einfach, nur andersherum.
Betreiben Sie bereits Kubernetes, ist eine weitere Anwendung darin der einfachere Weg, in Werkzeugen, die Ihr Team kennt.
Weiterlesen
Ja. Ausgeliefert werden Container-Abbilder und eine deklarative Beschreibung des Deployments, daraus entsteht die Anwendung in Ihrem Cluster genauso wie in unserem, ohne Umbau. Ein Knopfdruck ist es trotzdem nicht, sondern ein Projekt: Ihr Team schließt Überwachung, Sicherungen und Zertifikate an.
Im Cluster laufen von jedem Dienst mehrere gleichwertige Instanzen auf verschiedenen Maschinen. Antwortet eine nicht mehr auf ihre Bereitschaftsprüfung, nimmt die Lastverteilung sie aus dem Verkehr und Ersatz startet; für den Anwender ist das meist unsichtbar. Auf einer getrennten Einzelinstanz gibt es diese Reserve nicht: Dort wird der Dienst neu gestartet, und für die Dauer des Starts ist er weg. Welcher der beiden Fälle für Sie gilt, steht im Betriebsvertrag.
Im Regelfall nicht. Die neue Version startet neben der alten und bekommt erst Anfragen, wenn sie sich bereit meldet; danach wird die alte abgeräumt. Zwei Fälle brauchen eines: Datenbankänderungen ohne Rückwärtskompatibilität und Dienste, von denen nur eine Instanz laufen darf.
Gesichert wird auf zwei unabhängigen Ebenen: ein täglicher Datenbankauszug in einen getrennten Speicher und Momentaufnahmen der Datenträger. Für jede Datenbank existiert ein schriftliches Verfahren zur Wiederherstellung, nachvollziehbar auch außerhalb des Clusters, bewusst von Hand, weil eine Automatik hier mehr Risiko als Nutzen bringt. Ein Verfahren ist aber noch keine Zusage: Wann für Ihre Instanz zuletzt eine Sicherung zurückgespielt wurde, nennen wir Ihnen mit Datum.
In aller Regel nicht. Ein Cluster verursacht Betriebsaufwand, der anfällt, ob eine oder zwanzig Anwendungen darin laufen. Für eine kleine Fachanwendung sind eine gepflegte virtuelle Maschine, ein schlanker Container-Stack, tägliche Sicherung und automatische Zertifikate günstiger. Einen Teil unserer Kundeninstanzen betreiben wir auf diese Weise.
Nein. Sicherheitskorrekturen laufen zügig und ohne funktionale Änderung, der Sprung auf eine neue Hauptversion wird geplant. Und er ist zum großen Teil nicht Ihre Arbeit: Was sich maschinell nachziehen lässt, wird maschinell nachgezogen, der Umstieg bringt seine Migrationsschritte mit. Von Hand bleibt möglichst wenig zu richten.
Sprechen Sie mit uns.