Deployment-Topologie
SupaCloud läuft in zwei Ausprägungen, und der Unterschied entscheidet, wohin Inhalte geseedet werden, welche Automatisierung legitim ist und was ein Feature voraussetzen darf.
Die zwei Ausprägungen
Abschnitt betitelt „Die zwei Ausprägungen“Hosted SaaS. Der Hersteller betreibt eine mandantenfähige Instanz für Kunden. Dort ist der offizielle Marketplace-Katalog zu Hause: die kuratierten Items werden dorthin geseedet, damit Käufer sie finden. Deren Inhalte liegen in einem eigenen Repository außerhalb dieses hier — denn dieses Repository ist für die Veröffentlichung bestimmt und muss ohne Hersteller-Inhalte bauen.
Self-hosted. Ein Betreiber führt SupaCloud auf eigener Infrastruktur — eine Organisation, eigene Datenbank, eigene Zugangsdaten. Die Staging-Instanz des Herstellers ist ebenfalls self-hosted: sie hat genau die Form, die ein Kunde ausrollt, und ist deshalb zugleich der Prüfstand für den Self-hosted-Weg. Sie ist außerdem die Werkbank des Herstellers — die Workspaces darauf sind Eigenbedarf, kein Produktinhalt.
Die Regel: der Produktpfad trägt allein
Abschnitt betitelt „Die Regel: der Produktpfad trägt allein“Eine frische Instanz muss jede Fähigkeit über SupaClouds eigene Oberflächen erreichen — Web-UI, API, Marketplace, CLI. Ohne Hersteller-Infrastruktur, ohne dessen Konfigurationsverwaltung, ohne dessen Secret-Speicher, ohne Konten, die nur innerhalb der Hersteller-Flotte existieren.
Das ist keine Vorliebe. Eine Instanz, die das Ansible des Herstellers braucht, um benutzbar zu werden, ist nicht self-hostbar; und eine Fähigkeit, deren einziger Weg durch dessen Secret-Speicher führt, kann an niemanden ausgeliefert werden.
Daraus folgen zwei Dinge, beide tragend:
Ops-Automatisierung darf die Produktpfade benutzen, nie ersetzen. Ein Deployment aus der Konfigurationsverwaltung heraus bereitzustellen ist willkommen — der Hersteller macht das für seine eigene Staging-Instanz genau so —, aber sie muss dieselbe Management-API, denselben Marketplace-Seed und dieselben Ressourcen-Endpunkte ansprechen, die ein Betreiber von Hand benutzen würde. Wenn die Automatisierung einen Weg braucht, den das Produkt nicht hat, ist das ein fehlendes Feature — kein Grund, direkt in die Datenbank zu schreiben.
Ein Konfigurationswert, den man nur von innen kennen kann, ist ein Produktdefekt in Verkleidung. Erwartet ein Feld einen Bibliothekspfad, einen Hostnamen oder eine Kontenkonvention, die ein Fremder nicht herausfinden kann, fehlt nicht die Dokumentation, sondern eine Auswahl. Die Lösung ist, das Produkt auflisten zu lassen, was es erreichen kann, statt den Wert irgendwo zu notieren.
Wo Inhalte liegen
Abschnitt betitelt „Wo Inhalte liegen“| Repository | Inhalt | Geseedet nach |
|---|---|---|
| dieses Repository | der inhaltsagnostische Mechanismus (Seeder, Connectors, Workflow-Engine) | — |
| Marketplace-Katalog | kuratierte offizielle Items (Connectors, Workflow-Vorlagen) | Hosted SaaS |
| Workspace-Inhalte | die eigenen Workflows, Apps und Regeln eines Betreibers | dessen eigene Instanz |
Der Seeder nimmt ein Katalogverzeichnis und veröffentlicht, was er darin findet; er kennt kein einzelnes Item. Diese Trennung ist es, die das Produkt ohne den Hersteller-Katalog ausliefern lässt und den Katalog ohne Release ändern lässt.
Was das im Review bedeutet
Abschnitt betitelt „Was das im Review bedeutet“Bei einer Änderung lautet die Frage nicht nur „funktioniert das hier”, sondern „wie erreicht ein Fremder das auf einer nackten Instanz?“ Führt die ehrliche Antwort über die Hersteller-Flotte, ist die Änderung nicht fertig — die Ops-Abkürzung darf existieren, aber sie darf nicht die einzige Tür sein.