Designherleitung
Vom gewünschten Betriebserlebnis zum gemeinsamen Startpfad.
Bartl begann nicht mit einem neuen Orchestrator. Am Anfang stand die Frage, wie sich eine zustandsbehaftete Anwendung verhalten müßte, damit Wiederherstellung kein selten geprobter Sonderfall bleibt.
Komplexität verschwindet nicht. Sie wird einmal in einen ausführbaren Vertrag gelegt, statt bei jedem Start erneut vom Menschen verlangt zu werden.
Das gewünschte Erlebnis
Think iPhone.
Eine Anwendung sollte sich so selbstverständlich wieder in Betrieb nehmen lassen wie ein Telefon. Der Nutzer beschreibt nicht die interne Operation. Das System erkennt die vorliegende Situation und führt den zulässigen Pfad aus.
Neues Gerät ohne vorhandenen Zustand
-> initialisieren
Ersatzgerät mit Sicherungsstand
-> wiederherstellen
Neueres System mit älterem Zustand
-> migrieren
Unvereinbarer Zustand
-> sicher anhalten
Ein mentales Bild, kein Architekturbeweis
Bartl bildet weder die interne Architektur eines iPhone nach noch übernimmt es dessen geschlossene Betriebsumgebung. Das Bild setzt die Erwartung an die Bedienbarkeit. Unterschiedliche Ausgangslagen sollen nicht unterschiedliche Runbooks verlangen. Die konkrete technische Antwort von Bartl entsteht erst aus den Beobachtungen darunter.
Die Reise
Das Muster verdichtete sich über mehrere Betriebsfragen.
Die Form änderte sich, der Kern blieb gleich. Installation, Änderung und Wiederherstellung sollten nicht als getrennte Welten behandelt werden.
-
2022
Die Ausgangsfrage
Wie würde ein Kaufmann IT heute entwerfen, wenn Einfachheit, verläßlicher Betrieb und Wiederherstellbarkeit vom Ergebnis her gedacht werden? Das iPhone lieferte das mentale Bild.
-
2023
Das Betriebsziel
Produktionsänderungen sollten reproduzierbar, prüfbar und unabhängig von der ausführenden Person werden. Weniger unterschiedliche Verfahren wurden zum Qualitätsmerkmal.
-
2025
Das wiederkehrende Muster
Im Betrieb kundenspezifischer, zustandsbehafteter Stacks zeigte sich dieselbe Entscheidung immer wieder. Vorhandener Zustand, Sicherungsstand und Versionen bestimmen den nächsten Schritt.
-
2026
Der offene Schnitt
Der Anwendungs-Startpfad wurde als technischer Baustein von Bartl beschrieben und mit einer ausführbaren WordPress-Referenz von seinem ursprünglichen Produktkontext gelöst.
Fünf Beobachtungen
Die Gestaltung beginnt bei Bedingungen, die sich nicht wegplanen lassen.
-
Wert entsteht in Produktion.
Builds, Artefakte und Pläne sind Mittel. Erst eine erreichbare und fachlich richtige Anwendung erbringt die beabsichtigte Leistung.
-
Veränderung ist unvermeidlich.
Software, Datenformate, Abhängigkeiten und Zielumgebungen bleiben nicht dauerhaft in derselben Version.
-
Fehler sind unvermeidlich.
Auch gute Prävention beseitigt weder Ausfälle noch unvollständige Änderungen oder beschädigte Eingaben vollständig.
-
Seltene manuelle Abläufe sind nicht verläßlich.
Ein Recovery-Runbook, das nur im Notfall gebraucht wird, driftet vom regelmäßig ausgeführten Produktionspfad weg.
-
Jedes zusätzliche Glied hat einen Preis.
Zwischen Absicht und Ergebnis wachsen mit jeder Übergabe kognitive Last, Fehlerfläche und schwer erkennbare Nebenwirkungen.
Design-Druck
Aus den Beobachtungen folgen vier Anforderungen.
- Fehler lassen sich nicht vollständig verhindern.
- Recovery muß Teil des Designs sein.
- Ein selten ausgeführter Recovery-Pfad driftet.
- Regelmäßige Änderungen sollen die Wiederherstellung mitprüfen, etwa durch eine Ersatzinstallation aus einer Sicherung.
- Manuelle Genauigkeit skaliert nicht.
- Der Pfad muß ausführbar, prüfbar und reproduzierbar sein.
- Zusätzliche Steuerungsebenen verlängern die Wirkungskette.
- Der Mechanismus muß nahe an Anwendung und Zustand bleiben.
Der Designauftrag
Zustandsänderung und Wiederherstellung mit möglichst wenigen unterschiedlichen Mechanismen ausführen. Normalstart und Recovery dürfen dabei keine getrennten Wahrheiten entwickeln.
Die Entdeckung
Wie die Anwendung startet.
Du installierst oder startest die Anwendung. Sie stellt selbst fest, was zu tun ist:
- Sind ihre Daten bereits vorhanden, verwendet sie diese.
- Andernfalls stellt sie die neueste Sicherung wieder her.
- Ist kein Backup-Speicher konfiguriert oder gibt es noch keine Sicherung, startet sie mit den Ausgangsdaten der Anwendung.
- Ist die Software neuer als die Daten, führt sie die notwendige Aktualisierung durch.
Du mußt diese internen Schritte weder auswählen noch von Hand ausführen.
Für regelmäßige Updates können wir die neuere Version als Ersatzinstallation aufbauen, statt die laufende Installation zu verändern. Der Ersatz stellt die Sicherung wieder her und aktualisiert die Daten mit demselben Verfahren. Jedes solche Update übt damit auch die Wiederherstellung.
Das ist eine Betriebsentscheidung, kein anderer Anwendungsmechanismus. Wir wählen die Version und den Ort, an dem sie laufen soll; die Anwendung bestimmt die Schritte.
Die Ersatzinstallation ändert das Ziel und erfordert die Umschaltung des Dienstes darauf, aber keine weitere Schnittstelle für Initialisierung oder Wiederherstellung.
until serving():
local = observe_local_state()
if local.exists:
engine version vs local.version:
equal: serving()
engine >: migrate(local)
engine <: abort("downgrade")
else:
backup = observe_backup()
if backup.valid: restore(backup)
else: init()Was direkt folgt
Der gemeinsame Pfad verändert die Form des Betriebs.
- weniger unterschiedliche Betriebsprozeduren und geringere kognitive Last
- Sicherungsstände, die vor ihrer Verwendung technisch geprüft werden
- Migrationen, deren Entscheidung und Ergebnis beobachtbar bleiben
Komposition
Der Startmechanismus und multiplied single tenancy lösen verschiedene Probleme.
Multiplied single tenancy bedeutet ein eigener Stack je Kunde, wiederholt nach demselben Bauplan. Die Isolation vervielfacht zunächst die Zahl der Betriebsobjekte. Der Startvertrag macht ihren Anwendungs- und Zustandslebenszyklus wiederholbar. Flottensteuerung kann die Wiederholung koordinieren; diese Topologie ist keine Voraussetzung für Bartl.
Single tenancy
Isolation
- ein Kunde und ein Zustandsraum je Stack
- getrennte Fehler- und Compliance-Grenzen
- zusätzliche Infrastruktur- und Betriebsobjekte
Bartl-Startmechanismus
Wiederholbarer Lebenszyklus
- derselbe Startvertrag je Stack
- ein Pfad für Initialisierung, Restore und Migration
- keine Mandantentrennung und keine Flottensteuerung
Fleet management
Konsistenz in der Vielzahl
- Versionen und Rollouts über die Stacks steuern
- Abweichungen und Ergebnisse sichtbar machen
- manuelle Einzelpflege vermeiden
Zusammen wird eine belastbare Betriebsform möglich.
Getrennte Stacks können einen kleineren Blast Radius, eigene Daten- und Compliance-Grenzen sowie kundenbezogene Releases und Migrationen erhalten. Der gemeinsame Startvertrag macht ihre Lebenszyklen wiederholbar. Flottensteuerung kann Versionen und Rollouts koordinieren; ihr Nutzen muß ihre Kosten und geteilten Steuerungsrisiken rechtfertigen.
Der gemeinsame Startpfad beseitigt weder die Ressourcen- noch die Betriebskosten zusätzlicher Stacks. Er reduziert die Zahl unterschiedlicher Verfahren. Wie deren Wiederholung koordiniert wird, hängt von Umfang und Betriebsanforderungen ab, nicht von einer universellen Fleet-Management-Pflicht.
Saubere Trennung
Die Herleitung erklärt das Warum. Der Anwendungsvertrag präzisiert einen Baustein.
Bartl umfaßt Anwendung, Infrastruktur und Verantwortung für den vollständigen Service. Der kanonische Rahmen steht in README.md und der dort verlinkten Philosophie. Diese Seite erklärt den Startmechanismus; die technische Spec erläutert dessen Anwendungsvertrag, statt ganz Bartl zu definieren. Zielbereitstellung, sichere Aktivierung und der vollständige Recovery-Prozeß brauchen zusätzliche ausführbare Verfahren und eigene Nachweise.
Kanonischen Rahmen und Verträge lesen (EN)