Werkruimtes, instanties en hosting
Archestack wordt meestal uitgerold door een implementatiepartner: een bedrijf dat een app op Archestack bouwt en die aan zijn klanten levert. Deze pagina volgt van begin tot eind één voorbeeld: een softwarebedrijf dat een app heeft gebouwd voor testlaboratoria, de bedrijven die voeding, water en materialen analyseren voor andere bedrijven. De app volgt elk monster van ontvangst tot certificaat, en het softwarebedrijf rolt hem uit bij het ene laboratorium na het andere. Elk laboratorium is een klant en heeft zijn eigen zakelijke klanten: de voedingsproducenten, waterbedrijven en fabrikanten die monsters insturen.
De rest van deze pagina draait om drie woorden:
- Klant: een bedrijf waaraan de partner de app levert. In dit voorbeeld elk laboratorium.
- Werkruimte: de geïsoleerde omgeving waarin een klant werkt, met een eigen app, eigen data en eigen leden. De technische naam ervan is tenant.
- Instantie: één draaiende kopie van Archestack. Ze draait één of meerdere werkruimtes.
Kort gezegd: een klant werkt in een werkruimte, en een werkruimte draait op een instantie. De secties hieronder behandelen wat een werkruimte is en wat werkruimtes gescheiden houdt, de twee manieren om de werkruimtes van je klanten te hosten, hoe een laboratorium zijn eigen klanten binnenlaat, hoe Archestack zelf wordt gehost, en hoe een nieuwe versie van je app bij elke klant komt.
Wat een werkruimte is
Een werkruimte is de geïsoleerde omgeving waarin één klant werkt. Ze bevat de hele app, de data waarmee die app werkt en de mensen die toegang hebben, en ze is afgesloten van elke andere werkruimte. Elk laboratorium krijgt er een.
Tenant is de technische naam voor hetzelfde. Op de schermen heet het werkruimte; in de API en de code heet het tenant, het woord achter single-tenant- en multi-tenanthosting. Werkruimte en tenant zijn geen twee lagen, en geen van beide bevat de andere: één laboratorium heeft één werkruimte, en de API noemt die werkruimte een tenant. Deze pagina spreekt overal van werkruimte.
Archestack-instantie Wat er in een werkruimte zit
Een werkruimte bevat drie dingen:
- Core, een PostgreSQL-database die de app zelf bevat: business entities, pagina's, business events, script modules, scheduled events, PDF templates, packages, releases, test suites, Data API-endpoints en API-sleutels, MCP-tokens, branding, app-layouts, vertalingen, instellingen, mailaccounts en de outbox, en de voorkeuren en meldingen van de gebruikers. Wachtwoorden en andere geheimen die hier staan, zijn versleuteld, en van API-sleutels en MCP-tokens wordt alleen een hash bewaard.
- Runtime, een PostgreSQL-database die de bedrijfsdata bevat: de tabellen en de rijen erin, in dit voorbeeld de monsters, analyses, resultaten, analysecertificaten en facturen. De Schema Designer toont de structuur ervan precies zoals ze in de database staat.
- Leden: de mensen die toegang hebben, elk met een rol in deze werkruimte. Uitnodigingen worden per werkruimte verstuurd.
Omdat de app in Core staat, hebben twee laboratoria die dezelfde app draaien elk een eigen
kopie. Een wijziging in de ene werkruimte blijft daar tot je ze naar de andere werkruimtes
uitrolt, en daarvoor dienen packages. Een werkruimte kan ook een eigen adres hebben,
zoals peeters.labapp.example.com. Bij hosting door Archestack kan ze ook op een eigen
domein van het bedrijf draaien, zoals app.peeters.be: een beheerder voegt het toe op
de pagina Domains in de builder en bewijst het met één DNS-record, en het certificaat
volgt vanzelf.
Wat werkruimtes gescheiden houdt
De API en de achtergrondjobs bedienen alle werkruimtes op de instantie, maar elk verzoek en elke geplande job werkt voor precies één werkruimte:
- Aparte databases. De pagina's, business entities en queries van de ene werkruimte kunnen de tabellen van een andere werkruimte niet bereiken.
- Eén token, één werkruimte. Elk verzoek van een aangemelde gebruiker bevat een ondertekend token dat precies één werkruimte noemt, en alleen de databases van die werkruimte worden geopend.
- Geen terugval. Een token dat een werkruimte noemt die niet bestaat of is opgeschort, wordt geweigerd en nooit omgeleid naar een andere werkruimte.
- Sleutels die hun werkruimte noemen. API-sleutels en MCP-tokens dragen de naam van de werkruimte waar ze bij horen en werken alleen daar.
- Jobs die in hun werkruimte blijven. Geplande jobs draaien binnen de werkruimte waar ze bij horen.
- Back-ups per werkruimte. Back-ups, restores en exports omvatten de Core en Runtime van één werkruimte, zodat je de data van één klant kunt terugzetten of exporteren zonder die van een andere aan te raken.
Eén account, een rol per werkruimte
Accounts horen bij de instantie, lidmaatschappen bij de werkruimte. Iemand heeft één account op een instantie, met één e-mailadres en één wachtwoord, en kan lid zijn van meerdere werkruimtes, met in elk een andere rol. De consultants van de partner kunnen admin zijn in de werkruimte van elk laboratorium dat ze begeleiden, terwijl de medewerkers van een laboratorium alleen lid zijn van hun eigen werkruimte.
Wie bij meerdere werkruimtes hoort, wisselt ertussen via het avatarmenu. Bij het wisselen wordt een nieuw token uitgegeven, dat de andere werkruimte opent en alleen die. Als je iemand uit één werkruimte verwijdert, blijven de andere lidmaatschappen van die persoon ongemoeid.
De hoofdwerkruimte en nieuwe werkruimtes
Elke instantie maakt een hoofdwerkruimte aan wanneer ze voor het eerst start. Een bedrijf dat één omgeving nodig heeft, werkt gewoon daarin. Een partner met veel klanten houdt de hoofdwerkruimte voor het eigen team en maakt per klant een werkruimte aan. Een nieuwe werkruimte is in ongeveer een seconde aangemaakt en begint leeg.
Een werkruimte opdelen
Twee functies delen één werkruimte verder op. Geen van beide maakt een nieuwe omgeving: allebei werken ze binnen de werkruimte, op haar eigen Core en Runtime.
- Business units delen haar op per team, zodat elk team de pagina's en business entities ziet die het aangaan. Ze verbergen geen datarijen en vormen dus geen scheiding.
- Klantorganisaties delen haar op per eindklant. Het zijn geen eigen werkruimtes. Ze bestaan binnen de werkruimte van het laboratorium, niet ernaast, zonder eigen databases: de klanten van het laboratorium gebruiken de app van het laboratorium, wat ze invoeren komt terecht in de Runtime van het laboratorium, en elke eindklant ziet alleen zijn eigen rijen. Hieronder meer daarover.
Twee manieren om je klanten te hosten
Elke werkruimte draait op een instantie: één draaiende kopie van Archestack, met een API, achtergrondjobs en een PostgreSQL-server die de databases van haar werkruimtes bevat. De werkruimtes op één instantie delen de instantie eromheen, niet elkaars databases:
| Elke werkruimte heeft haar eigen | Gedeeld door de werkruimtes op één instantie | |
|---|---|---|
| De app | Core: pagina's, business entities, script modules, instellingen en de rest | De platformversie. Een upgrade bereikt elke werkruimte tegelijk. |
| De data | Runtime: haar tabellen en rijen | De PostgreSQL-server die de databases bevat |
| Mensen | Leden, rollen en uitnodigingen | De accounts: één e-mailadres en één wachtwoord per persoon |
| Achtergrondwerk | Haar geplande jobs, die binnen de werkruimte draaien | De achtergrondjobs en de jobplanner |
| Modules | De packages die ze heeft geïnstalleerd | De catalogus van de Module Store |
De werkruimtes op één instantie delen ook de capaciteit van die instantie: processor, geheugen en databaseverbindingen. Voor elke klant beslist de partner of de werkruimte van die klant een eigen instantie krijgt of er een deelt met de werkruimtes van andere klanten. In beide modellen heeft elke klant een eigen werkruimte met een eigen Core en Runtime. Het verschil zit in hoeveel werkruimtes een instantie delen, en dus in wat ze met elkaar delen.
Eén werkruimte per instantie (single-tenant)
Archestack Archestack Archestack Elk laboratorium krijgt een eigen instantie, met een eigen API en eigen achtergrondjobs, en een werkruimte met eigen Core- en Runtime-databases. Dit past bij grote klanten, klanten die bepalen waar hun data staat en klanten die zelf kiezen wanneer ze upgraden. De partner kan deze instanties zelf draaien, of er een installeren in het eigen cloudaccount of datacenter van het laboratorium.
Voordelen
- De sterkste scheiding die er is. Er wordt niets gedeeld met andere klanten, zelfs het platform niet.
- Eigen capaciteit. Een druk laboratorium vertraagt nooit een ander, en zijn instantie wordt alleen voor dat laboratorium gedimensioneerd.
- Upgrades volgens de planning van de klant. Elke instantie stapt over op een nieuwe platformversie wanneer het die klant uitkomt.
- De data staat waar de klant dat wil: in een bepaalde regio, in een cloudaccount of op eigen servers.
- Een nette afsluiting. Draag de instantie over, of zet haar uit.
Nadelen
- Elke instantie moet beheerd worden: servers, certificaten, back-ups, monitoring en upgrades, één keer per klant.
- Een nieuwe versie van je app moet je in elke instantie apart importeren.
- Je eigen medewerkers hebben een account nodig op elke instantie waarop ze werken.
- Zelfs de kleinste klant heeft een volledige instantie nodig.
Meerdere werkruimtes per instantie (multi-tenant)
Archestack
Eén instantie bedient veel laboratoria. Elk laboratorium is nog steeds een eigen werkruimte, met
eigen Core- en Runtime-databases en, als je wilt, een eigen adres zoals
peeters.labapp.example.com. De beheerders van de instantie maken een nieuwe
werkruimte aan in ongeveer een seconde.
Voordelen
- Elke klant heeft nog steeds eigen databases, eigen back-ups en een eigen versie van de app, aangepast aan de manier waarop die klant werkt.
- Een klant toevoegen duurt ongeveer een seconde, en een rustige klant kost bijna niets: een werkruimte die niemand gebruikt, houdt geen databaseverbindingen open.
- Eén instantie om te beheren, te beveiligen en te upgraden.
- Je consultants gebruiken één account en wisselen tussen klanten via het avatarmenu.
Nadelen
- Elke klant stapt op hetzelfde moment over op een nieuwe platformversie.
- Klanten delen de capaciteit van de instantie, dus dimensioneer haar voor alle klanten samen. Een instantie met meer dan enkele tientallen werkruimtes die tegelijk in gebruik zijn, heeft ook een hogere verbindingslimiet in PostgreSQL nodig dan de standaardwaarde van 100.
- Een nieuwe versie van je app installeer je nog steeds werkruimte per werkruimte, vanuit de Module Store van de instantie of vanuit een ZIP.
Naast elkaar
| Eén werkruimte per instantie | Meerdere werkruimtes per instantie | |
|---|---|---|
| Eigen databases | Ja, op een eigen server | Ja, op een gedeelde server |
| Capaciteit | Per klant | Gedeeld |
| Platformversie | Per klant | Gedeeld |
| Waar de data kan staan | Overal, ook in de eigen cloud van de klant | Waar de partner de instantie draait |
| Een nieuwe app-versie uitrollen | Een ZIP, geïmporteerd in de werkruimte van elke klant | Geïnstalleerd in de werkruimte van elke klant, vanuit de Module Store van de instantie of een ZIP |
| Een klant toevoegen | Een nieuwe instantie | Ongeveer een seconde |
| Kosten per klant | Hoger | Laag |
Combineren is normaal: kleine laboratoria delen een instantie, een grote laboratoriumgroep krijgt een eigen instantie, en dezelfde packages gaan naar allebei. Ontwikkeling, test, acceptatie en productie zijn elk een eigen werkruimte. Zet ontwikkeling, test en acceptatie op één instantie en productie op een eigen instantie, zodat een platformupgrade eerst acceptatie bereikt en pas daarna productie.
Eindklanten binnen de app van een klant
Een laboratorium heeft zelf klanten: voedingsproducenten, waterbedrijven en fabrikanten die monsters insturen. Zij willen de monsters die ze insturen registreren en elk monster volgen terwijl het laboratorium ermee bezig is. De ene voedingsproducent mag nooit de monsters van een andere producent zien; het laboratorium ziet ze allemaal. Het laboratorium kan deze klanten toegang geven tot de app die de partner ervoor heeft gebouwd, als klantorganisaties.
De partner bouwt de app en kiest de hosting, volgens een van de twee modellen hierboven. Het laboratorium merkt niet welk model het is, en zijn klanten evenmin. Daarna nodigt het laboratorium zijn klanten uit, of laat het ze zichzelf aanmelden.
Een klantorganisatie is geen werkruimte en heeft geen eigen databases. Ze bestaat binnen de werkruimte van het laboratorium: de app hoort bij die werkruimte, elke eindklant heeft eigen leden, en alles wat ze invoeren, komt terecht in de Runtime-database van het laboratorium, gemarkeerd met het bedrijf dat het heeft vastgelegd. Elke eindklant ziet alleen zijn eigen rijen, het laboratorium ziet ze allemaal, en een eindklant kan zelf ook subeenheden hebben: een voedingsgroep bijvoorbeeld, met een subeenheid voor elk van zijn fabrieken en een voor elke productielijn in een fabriek. Elke eenheid ziet zijn eigen rijen en die van de eenheden eronder. Eindklanten gebruiken de app zoals het laboratorium hem publiceert en wijzigen hem niet, en de eigen beheerder van elke eindklant nodigt collega's uit en verwijdert ze.
Hostinginfrastructuur
Archestack wordt geleverd als één container-image die zowel de API als de achtergrondjobs draait: scheduled events, uitgaande mail, runs van test suites, synchronisaties met andere systemen en de nachtelijke back-ups. Ze schaalt horizontaal: draai meer kopieën van dezelfde image achter een load balancer naarmate het aantal gebruikers groeit. De kopieën stemmen zich af via PostgreSQL, dus het geplande werk wordt over hen verdeeld en elke job draait één keer.
Archestack-image Archestack-image Meer dan één kopie draaien vraagt een paar dingen van de infrastructuur eromheen:
- Geen sticky sessions, maar WebSockets moeten erdoor. Elke kopie kan elk verzoek beantwoorden. Live updates (tabellen die verversen, wie er nog meer op een pagina zit, meldingen) lopen alleen over WebSockets, dus een load balancer of netwerk dat ze blokkeert laat de app werken, maar zonder live updates.
- Gedeelde volumes voor back-ups en bestanden. De back-upmap en de map met de
bestanden van elke werkruimte (uploads, logo's, bestanden die scripts schrijven) moeten op
opslag staan die elke kopie koppelt (in Kubernetes een
ReadWriteMany-volume), anders ziet elke kopie alleen de back-ups en bestanden die ze zelf schreef. - Een startup probe. Kopieën die tegelijk starten bereiden de databases om beurten voor, en met veel werkruimtes om te migreren duurt dat even. Geef de containers een startup probe in plaats van een korte liveness probe.
- Rate limits gelden per kopie. Drie kopieën staan per aanroeper drie keer zoveel verzoeken toe als één.
- Achter PgBouncer in transaction mode moet
ConnectionStrings__Clusterrechtstreeks naar PostgreSQL wijzen: de kopieën praten met elkaar over een PostgreSQL-verbinding die open moet blijven.
Naast de containers heeft een instantie PostgreSQL 16 nodig en een proxy die TLS afhandelt. Ze
draait overal waar containers draaien: op één server, in een cloudaccount of in een
Kubernetes-cluster. De partner kan haar hosten, Archestack kan haar hosten, of ze kan draaien in
de eigen infrastructuur van de klant. Voor Kubernetes is er een Helm-chart, en een instantie kan
ook onder een pad van een hostnaam staan die van een andere toepassing is, zoals
apps.example.com/archestack/.
Een nieuwe instantie heeft geen gebruikers. Wie ze als eerste opent, maakt de eerste beheerder aan, dus richt ze in voordat ze vanaf internet bereikbaar is.
Capaciteit en dimensionering geeft de gemeten cijfers: hoeveel mensen en werkruimtes een instantie bedient, en de servers die ze daarvoor nodig heeft. Hosten op AKS installeert een instantie op Azure Kubernetes Service en houdt haar vanzelf op de nieuwste release; Hosten met Docker doet hetzelfde op één server.
Je app bij elke klant uitrollen
Als elke klant een eigen werkruimte heeft, moet elke nieuwe versie van de app naar al die werkruimtes. Dat doe je met een package:
- Zet de tabellen, business entities, pagina's, business events, script modules, PDF templates, scheduled events, test suites en app-layouts van je app in een package, en exporteer die als ZIP.
- Importeer de package in de werkruimte van de klant. De import toont eerst een plan en voert daarna de tabelwijzigingen door in de Runtime-database van de werkruimte.
- Draai daar de test suites van de package. Tests draaien in een aparte sandboxdatabase en komen nooit aan de data van de klant.
- Publiceer een release. Op dat moment komen de nieuwe pagina's bij de gebruikers van de klant. Een werkruimte die nog nooit een release heeft gepubliceerd, toont haar pagina's zodra de import klaar is.
Sommige dingen stel je in elke werkruimte in, in plaats van ze mee te leveren: Data API-endpoints en -sleutels, vertalingen, gebruikers, rollen, business units, branding, mailaccounts en koppelingen met andere systemen. Alles wat als openbaar is gemarkeerd, komt privé binnen, dus een package installeren kan nooit uit zichzelf de data van een klant op internet zetten.
Op één instantie is een module die als openbaar in de Module Store is gepubliceerd, zichtbaar voor elke werkruimte op die instantie, en elke werkruimte kan hem installeren. Dat bespaart het exporteren en importeren. Een privé gepubliceerde module is alleen zichtbaar voor de werkruimte die hem heeft gepubliceerd. Tussen instanties reizen packages als ZIP-bestanden.
Wanneer de app in een git-repository staat, beschrijft Deploymentstrategie hoe een pipeline hem test en zonder downtime naar elke omgeving deployt.
Valkuilen
- Een platformupgrade bereikt elke werkruimte op de instantie tegelijk. Een klant die op een versie moet blijven, heeft een eigen instantie nodig.
- Een nieuwe werkruimte begint leeg. Installeer je packages erin en nodig de mensen uit; lidmaatschappen worden niet overgenomen uit andere werkruimtes.
Waar dit naartoe gaat
Packages behandelt het bouwen en exporteren van de package die je naar elke werkruimte stuurt. De Data API-handleiding laat zien hoe een service met een API-sleutel verbinding maakt met één werkruimte, en Database Backups behandelt de back-ups per werkruimte.