Workspaces, Instanzen und Hosting
Archestack wird meist von einem Implementierungspartner ausgerollt: einem Unternehmen, das eine App auf Archestack baut und an seine Kunden ausliefert. Diese Seite folgt durchgehend einem Beispiel: einem Softwareunternehmen, das eine App für Prüflabore gebaut hat, also für die Unternehmen, die Lebensmittel, Wasser und Materialien für andere Firmen analysieren. Die App begleitet jede Probe von der Annahme bis zum Zertifikat, und das Softwareunternehmen führt sie bei einem Labor nach dem anderen ein. Jedes Labor ist ein Kunde und hat seinerseits eigene Geschäftskunden: die Lebensmittelproduzenten, Wasserversorger und Hersteller, die Proben einsenden.
Drei Begriffe ziehen sich durch den Rest dieser Seite:
- Kunde: ein Unternehmen, an das der Partner die App ausliefert. In diesem Beispiel jedes Labor.
- Workspace: die isolierte Umgebung, in der ein Kunde arbeitet, mit eigener App, eigenen Daten und eigenen Mitgliedern. Sein technischer Name ist Tenant.
- Instanz: eine laufende Kopie von Archestack. Auf ihr läuft ein Workspace oder viele.
Kurz gesagt: Ein Kunde arbeitet in einem Workspace, und ein Workspace läuft auf einer Instanz. Die folgenden Abschnitte behandeln, was ein Workspace ist und was ihn von anderen trennt, die zwei Wege, die Workspaces deiner Kunden zu hosten, wie ein Labor seine eigenen Kunden hereinlässt, wie Archestack selbst gehostet wird und wie eine neue Version deiner App jeden Kunden erreicht.
Was ein Workspace ist
Ein Workspace ist die isolierte Umgebung, in der ein Kunde arbeitet. Er enthält die ganze App, die Daten, mit denen diese App arbeitet, und die Menschen, die Zugang haben, und er ist von jedem anderen Workspace abgeschottet. Jedes Labor bekommt einen.
Tenant ist der technische Name für genau dasselbe. Die Oberfläche spricht von Workspace; die API und der Code sprechen von Tenant, dem Wort hinter Single-Tenant- und Multi-Tenant-Hosting. Workspace und Tenant sind keine zwei Ebenen, und keiner enthält den anderen: Ein Labor hat einen Workspace, und die API nennt diesen Workspace Tenant. Diese Seite spricht durchgehend von Workspace.
Archestack-Instanz Was in einem Workspace steckt
Ein Workspace enthält drei Dinge:
- Core, eine PostgreSQL-Datenbank, die die App selbst enthält: Business Entities, Pages, Business Events, Script Modules, Scheduled Events, PDF Templates, Packages, Releases, Test Suites, Data-API-Endpunkte und API-Schlüssel, MCP-Tokens, Branding, App Layouts, Übersetzungen, Einstellungen, Mail-Konten und den Postausgang sowie die Präferenzen und Benachrichtigungen seiner Benutzer. Passwörter und andere Geheimnisse, die hier liegen, sind verschlüsselt, und API-Schlüssel und MCP-Tokens werden nur als Hash gespeichert.
- Runtime, eine PostgreSQL-Datenbank, die die Geschäftsdaten enthält: die Tabellen und die Zeilen darin, in diesem Beispiel die Proben, Analysen, Ergebnisse, Analysenzertifikate und Rechnungen. Der Schema Designer zeigt ihre Struktur genau so, wie sie in der Datenbank vorliegt.
- Mitglieder: die Menschen, die Zugang haben, jeder mit einer Rolle in diesem Workspace. Einladungen werden pro Workspace verschickt.
Weil die App im Core liegt, haben zwei Labore, die dieselbe App nutzen, jeweils eine eigene
Kopie. Eine Änderung in einem Workspace bleibt dort, bis du sie an die anderen auslieferst, und
genau dafür gibt es Packages. Ein Workspace kann auch eine eigene Adresse
haben, etwa peeters.labapp.example.com. Beim Hosting durch Archestack kann er auch
unter einer eigenen Domain des Unternehmens laufen, etwa app.peeters.be: Ein
Administrator trägt sie auf der Seite Domains im Builder ein und weist sie mit einem
DNS-Eintrag nach, das Zertifikat folgt von selbst.
Was Workspaces voneinander trennt
Die API und die Hintergrundjobs bedienen jeden Workspace der Instanz, aber jede Anfrage und jeder geplante Job arbeitet für genau einen Workspace:
- Getrennte Datenbanken. Die Pages, Business Entities und Abfragen eines Workspaces kommen nicht an die Tabellen eines anderen Workspaces heran.
- Ein Token, ein Workspace. Jede Anfrage eines angemeldeten Benutzers trägt ein signiertes Token, das genau einen Workspace nennt, und nur die Datenbanken dieses Workspaces werden geöffnet.
- Kein Fallback. Ein Token, das einen Workspace nennt, der nicht existiert oder gesperrt ist, wird abgelehnt und nie zu einem anderen Workspace umgeleitet.
- Schlüssel, die ihren Workspace nennen. API-Schlüssel und MCP-Tokens tragen den Namen des Workspaces, zu dem sie gehören, und funktionieren nur dort.
- Jobs, die in ihrem Workspace bleiben. Geplante Jobs laufen in dem Workspace, dem sie gehören.
- Backups pro Workspace. Backups, Wiederherstellungen und Exporte umfassen Core und Runtime eines einzigen Workspaces, sodass sich die Daten eines Kunden wiederherstellen oder exportieren lassen, ohne die eines anderen anzurühren.
Ein Konto, eine Rolle pro Workspace
Konten gehören zur Instanz, Mitgliedschaften zum Workspace. Eine Person hat ein Konto auf einer Instanz, mit einer E-Mail-Adresse und einem Passwort, und kann Mitglied mehrerer Workspaces sein, in jedem mit einer anderen Rolle. Die Berater des Partners können im Workspace jedes Labors, das sie betreuen, Admin sein, während die Mitarbeiter eines Labors nur Mitglied ihres eigenen Workspaces sind.
Wer zu mehreren Workspaces gehört, wechselt über das Avatar-Menü zwischen ihnen. Der Wechsel stellt ein neues Token aus, das den anderen Workspace öffnet und nur diesen. Wer aus einem Workspace entfernt wird, behält seine anderen Mitgliedschaften.
Der Haupt-Workspace und neue Workspaces
Jede Instanz legt beim ersten Start einen Haupt-Workspace an. Ein Unternehmen, das eine einzige Umgebung braucht, arbeitet einfach darin. Ein Partner mit vielen Kunden behält den Haupt-Workspace für sein eigenes Team und legt pro Kunde einen Workspace an. Ein neuer Workspace ist in etwa einer Sekunde angelegt und startet leer.
Einen Workspace unterteilen
Zwei Funktionen unterteilen einen Workspace weiter. Keine von beiden schafft eine neue Umgebung: Beide arbeiten innerhalb des Workspaces, mit seinem eigenen Core und seiner eigenen Runtime.
- Business Units unterteilen ihn nach Team, damit jedes Team die Pages und Business Entities sieht, die es betreffen. Sie verbergen keine Datenzeilen und sind deshalb keine Trennung.
- Kundenorganisationen unterteilen ihn nach Kunden. Sie sind keine eigenen Workspaces. Sie liegen im Workspace des Labors, nicht daneben, und haben keine eigenen Datenbanken: Die Kunden des Labors nutzen die App des Labors, was sie eingeben, landet in der Runtime des Labors, und jeder Kunde sieht nur seine eigenen Zeilen. Mehr dazu weiter unten.
Zwei Wege, deine Kunden zu hosten
Jeder Workspace läuft auf einer Instanz: einer laufenden Kopie von Archestack, mit ihrer API, ihren Hintergrundjobs und einem PostgreSQL-Server, der die Datenbanken ihrer Workspaces enthält. Die Workspaces einer Instanz teilen sich die Instanz um sie herum, aber nicht ihre Datenbanken:
| Jeder Workspace für sich | Gemeinsam für die Workspaces einer Instanz | |
|---|---|---|
| Die App | Core: Pages, Business Entities, Script Modules, Einstellungen und alles Übrige | Die Plattformversion. Ein Upgrade erreicht jeden Workspace gleichzeitig. |
| Die Daten | Runtime: seine Tabellen und Zeilen | Der PostgreSQL-Server, der die Datenbanken enthält |
| Personen | Mitglieder, Rollen und Einladungen | Die Konten: eine E-Mail-Adresse und ein Passwort pro Person |
| Hintergrundarbeit | Seine geplanten Jobs, die im Workspace laufen | Die Hintergrundjobs und der Job-Scheduler |
| Module | Die Packages, die er installiert hat | Der Katalog des Module Store |
Die Workspaces einer Instanz teilen sich außerdem ihre Kapazität: Prozessor, Arbeitsspeicher und Datenbankverbindungen. Für jeden Kunden entscheidet der Partner, ob dessen Workspace eine eigene Instanz bekommt oder sich eine mit den Workspaces anderer Kunden teilt. In beiden Modellen hat jeder Kunde einen eigenen Workspace mit eigenem Core und eigener Runtime. Der Unterschied liegt darin, wie viele Workspaces sich eine Instanz teilen, und damit, was sie miteinander teilen.
Ein Workspace pro Instanz (Single-Tenant)
Archestack Archestack Archestack Jedes Labor bekommt eine eigene Instanz, mit eigener API und eigenen Hintergrundjobs, und einen Workspace mit eigenen Core- und Runtime-Datenbanken. Das passt zu großen Kunden, zu Kunden, die selbst bestimmen, wo ihre Daten liegen, und zu Kunden, die den Zeitpunkt ihrer Upgrades selbst wählen. Der Partner kann diese Instanzen selbst betreiben oder eine davon im eigenen Cloud-Konto oder Rechenzentrum des Labors installieren.
Vorteile
- Die stärkste Trennung, die es gibt. Nichts wird mit anderen Kunden geteilt, nicht einmal die Plattform.
- Eigene Kapazität. Ein stark ausgelastetes Labor bremst nie ein anderes aus, und seine Instanz wird allein für dieses Labor dimensioniert.
- Upgrades nach dem Zeitplan des Kunden. Jede Instanz wechselt auf eine neue Plattformversion, wenn es diesem Kunden passt.
- Die Daten liegen dort, wo der Kunde sie haben will: in einer bestimmten Region, einem Cloud-Konto oder auf eigenen Servern.
- Ein sauberes Ende. Übergib die Instanz oder schalte sie ab.
Nachteile
- Jede Instanz muss betrieben werden: Server, Zertifikate, Backups, Monitoring und Upgrades, einmal pro Kunde.
- Eine neue Version deiner App musst du in jede Instanz importieren, jeweils einzeln.
- Dein eigenes Team braucht ein Konto auf jeder Instanz, auf der es arbeitet.
- Selbst der kleinste Kunde braucht eine vollständige Instanz.
Mehrere Workspaces pro Instanz (Multi-Tenant)
Archestack
Eine Instanz bedient viele Labore. Jedes Labor ist trotzdem ein eigener Workspace, mit eigenen
Core- und Runtime-Datenbanken und, wenn du willst, einer eigenen Adresse wie
peeters.labapp.example.com. Die Administratoren der Instanz legen einen neuen
Workspace in etwa einer Sekunde an.
Vorteile
- Jeder Kunde hat trotzdem eigene Datenbanken, eigene Backups und eine eigene Version der App, angepasst an seine Arbeitsweise.
- Einen Kunden hinzuzufügen dauert etwa eine Sekunde, und ein wenig aktiver Kunde kostet fast nichts: Ein Workspace, den niemand nutzt, hält keine Datenbankverbindungen.
- Nur eine Instanz, die du betreiben, absichern und aktualisieren musst.
- Deine Berater nutzen ein einziges Konto und wechseln über das Avatar-Menü zwischen den Kunden.
Nachteile
- Alle Kunden wechseln im selben Moment auf eine neue Plattformversion.
- Kunden teilen sich die Kapazität der Instanz, dimensioniere sie also für alle zusammen. Bei einer Instanz, auf der mehr als ein paar Dutzend Workspaces gleichzeitig genutzt werden, muss außerdem das Verbindungslimit von PostgreSQL über seinen Standardwert von 100 angehoben werden.
- Eine neue Version deiner App wird trotzdem Workspace für Workspace installiert, aus dem Module Store der Instanz oder als ZIP.
Im direkten Vergleich
| Ein Workspace pro Instanz | Mehrere Workspaces pro Instanz | |
|---|---|---|
| Eigene Datenbanken | Ja, auf eigenem Server | Ja, auf einem geteilten Server |
| Kapazität | Pro Kunde | Geteilt |
| Plattformversion | Pro Kunde | Geteilt |
| Wo die Daten liegen können | Überall, auch in der eigenen Cloud des Kunden | Dort, wo der Partner die Instanz betreibt |
| Neue App-Version ausliefern | Ein ZIP, das in den Workspace jedes Kunden importiert wird | In den Workspace jedes Kunden installiert, aus dem Module Store der Instanz oder als ZIP |
| Neuen Kunden hinzufügen | Eine neue Instanz | Etwa eine Sekunde |
| Kosten pro Kunde | Höher | Niedrig |
Beide Modelle zu mischen ist üblich: Kleine Labore teilen sich eine Instanz, eine große Laborgruppe bekommt eine eigene, und dieselben Packages werden an beide ausgeliefert. Entwicklung, Test, Abnahme und Produktion sind jeweils ein eigener Workspace. Leg Entwicklung, Test und Abnahme auf eine Instanz und Produktion auf eine eigene, damit ein Plattform-Upgrade die Abnahme erreicht, bevor es in der Produktion ankommt.
Endkunden in der App eines Kunden
Ein Labor hat eigene Kunden: Lebensmittelproduzenten, Wasserversorger und Hersteller, die Proben einsenden. Sie wollen die Proben, die sie einsenden, erfassen und jede davon verfolgen, während das Labor daran arbeitet. Ein Lebensmittelproduzent darf nie die Proben eines anderen Produzenten sehen; das Labor sieht sie alle. Das Labor kann diese Kunden als Kundenorganisationen in die App holen, die der Partner für das Labor gebaut hat.
Der Partner baut die App und wählt das Hosting nach einem der beiden Modelle oben. Welches es ist, merken weder das Labor noch seine Kunden. Anschließend lädt das Labor seine Kunden ein oder lässt sie sich selbst registrieren.
Eine Kundenorganisation ist kein Workspace und hat keine eigenen Datenbanken. Sie liegt im Workspace des Labors: Die App gehört zu diesem Workspace, jeder Kunde hat eigene Mitglieder, und alles, was sie eingeben, landet in der Runtime-Datenbank des Labors, versehen mit der Kennung der Firma, die es erfasst hat. Jeder Kunde sieht nur seine eigenen Zeilen, das Labor sieht alle, und ein Kunde kann eigene Untereinheiten haben: etwa ein Lebensmittelkonzern mit einer Untereinheit für jedes seiner Werke und einer für jede Produktionslinie in einem Werk. Jede Einheit sieht ihre eigenen Zeilen und die der Einheiten unter ihr. Kunden nutzen die App so, wie das Labor sie veröffentlicht, ohne sie zu ändern, und der eigene Administrator jedes Kunden lädt Kollegen ein und entfernt sie.
Hosting-Infrastruktur
Archestack wird als ein Container-Image ausgeliefert, das sowohl die API als auch die Hintergrundjobs ausführt: Scheduled Events, ausgehende Mails, Läufe von Test Suites, Synchronisierungen mit anderen Systemen und die nächtlichen Backups. Es skaliert horizontal: Starte weitere Kopien desselben Images hinter einem Load Balancer, wenn die Zahl der Benutzer wächst. Die Kopien stimmen sich über PostgreSQL ab, sodass die geplante Arbeit zwischen ihnen aufgeteilt wird und jeder Job genau einmal läuft.
Archestack-Image Archestack-Image Mehr als eine Kopie zu betreiben stellt ein paar Anforderungen an die Infrastruktur drumherum:
- Keine Sticky Sessions, aber WebSockets müssen durchkommen. Jede Kopie kann jede Anfrage beantworten. Live-Aktualisierungen (Tabellen, die sich aktualisieren, wer sonst noch auf einer Seite ist, Benachrichtigungen) laufen nur über WebSockets. Ein Load Balancer oder Netzwerk, das sie blockiert, lässt die App funktionieren, aber ohne Live-Aktualisierungen.
- Gemeinsame Volumes für Backups und Dateien. Der Backup-Ordner und der
Ordner mit den Dateien aller Workspaces (Uploads, Logos, Dateien, die Skripte schreiben)
müssen auf einem Speicher liegen, den jede Kopie einbindet (in Kubernetes ein
ReadWriteMany-Volume), sonst sieht jede Kopie nur die Backups und Dateien, die sie selbst geschrieben hat. - Eine Startup Probe. Kopien, die gleichzeitig starten, bereiten die Datenbanken nacheinander vor, und bei vielen zu migrierenden Workspaces dauert das eine Weile. Gib den Containern eine Startup Probe statt einer kurzen Liveness Probe.
- Rate Limits gelten pro Kopie. Drei Kopien erlauben pro Aufrufer dreimal so viele Anfragen wie eine.
- Hinter PgBouncer im Transaktionsmodus muss
ConnectionStrings__Clusterdirekt auf PostgreSQL zeigen: Die Kopien sprechen über eine PostgreSQL-Verbindung miteinander, die offen bleiben muss.
Neben den Containern braucht eine Instanz PostgreSQL 16 und einen Proxy, der TLS übernimmt. Sie
läuft überall, wo Container laufen: auf einem einzelnen Server, in einem Cloud-Konto oder in
einem Kubernetes-Cluster. Der Partner kann sie hosten, Archestack kann sie hosten, oder sie kann
in der eigenen Infrastruktur des Kunden laufen. Für Kubernetes gibt es ein Helm-Chart, und eine
Instanz kann auch unter einem Pfad eines Hostnamens laufen, der einer anderen Anwendung gehört,
etwa apps.example.com/archestack/.
Eine neue Instanz hat keine Benutzer. Wer sie als Erster öffnet, legt den ersten Administrator an, richte sie also ein, bevor sie aus dem Internet erreichbar ist.
Kapazität und Dimensionierung enthält die gemessenen Zahlen: wie viele Personen und Workspaces eine Instanz bedient und welche Server sie dafür braucht. Hosting auf AKS installiert eine Instanz auf Azure Kubernetes Service und hält sie von selbst auf dem neuesten Release; Hosting mit Docker tut dasselbe auf einem Server.
Deine App zu jedem Kunden bringen
Wenn jeder Kunde seinen eigenen Workspace hat, muss jede neue Version der App dorthin gelangen. Das erledigt ein Package:
- Pack die Tabellen, Business Entities, Pages, Business Events, Script Modules, PDF Templates, Scheduled Events, Test Suites und App Layouts deiner App in ein Package und exportiere es als ZIP.
- Importiere es in den Workspace des Kunden. Der Import zeigt zuerst einen Plan und wendet dann die Tabellenänderungen auf die Runtime-Datenbank des Workspaces an.
- Führe dort die Test Suites des Packages aus. Tests laufen in einer separaten Sandbox-Datenbank und fassen die Daten des Kunden nie an.
- Veröffentliche ein Release. Das ist der Moment, in dem die neuen Pages die Benutzer des Kunden erreichen. Ein Workspace, der noch nie ein Release veröffentlicht hat, zeigt seine Pages, sobald der Import abgeschlossen ist.
Manches wird in jedem Workspace eingerichtet statt ausgeliefert: Endpunkte und Schlüssel der Data API, Übersetzungen, Benutzer, Rollen, Business Units, Branding, Mail-Konten und Verbindungen zu anderen Systemen. Alles, was als öffentlich markiert ist, kommt privat an, sodass die Installation eines Packages die Daten eines Kunden nie von sich aus ins Internet stellen kann.
Innerhalb einer Instanz ist ein Modul, das als öffentlich in den Module Store gestellt wurde, für jeden Workspace darauf sichtbar und installierbar, was Export und Import erspart. Einen privaten Eintrag sieht nur der Workspace, der ihn veröffentlicht hat. Zwischen Instanzen gelangen Packages als ZIP-Dateien.
Wenn die App in einem git-Repository liegt, beschreibt Deployment-Strategie, wie eine Pipeline sie testet und ohne Ausfallzeit in jede Umgebung deployt.
Stolperfallen
- Ein Plattform-Upgrade erreicht jeden Workspace der Instanz gleichzeitig. Ein Kunde, der auf einer Version bleiben muss, braucht eine eigene Instanz.
- Ein neuer Workspace startet leer. Installiere deine Packages darin und lade seine Leute ein; Mitgliedschaften werden nicht aus anderen Workspaces übernommen.
Wie es weitergeht
Packages beschreibt, wie du das Package baust und exportierst, das du an jeden Workspace auslieferst. Die Data-API-Anleitung zeigt, wie sich ein Dienst per API-Schlüssel mit einem Workspace verbindet, und Database Backups beschreibt die Backups pro Workspace.