Betriebsvarianten Minasa-System
Minasa ist grundsätzlich eine Web-Plattform, die auf Standard-Komponenten basiert. Eine Installation bezeichnen wir im Folgenden als eine Instanz, und besteht im Wesentlichen aus folgenden Komponenten:
- Ein Applikationsserver, welcher die Frontend-Webseite sowie die API mit der Business-Logik bereitstellt
- das Cockpit, eine VueJS-Single-Page-Applikation
- eine MySQL-Datenbank, welche die Datenhaltung übernimmt
Somit ist des den Usern / den Betreibern grundsätzlich selber überlassen, wie die Applikation betrieben / genutzt wird. Es haben sich jedoch verschiedene Möglichkeiten der Nutzung abgezeichnet, welche z.B. ein gemeinsames Nutzen einer Plattform für mehrere Kunden möglich macht.
Dieses Kapitel beschreibt (nicht abschliessen) die Möglichkeiten, die Minasa-Plattform zu nutzen.
Eine Instanz, eine Domain/Frontend, ein Kunde
Geeignet für: einzelne Domain ohne Abhängigkeiten
Dies ist die ursprünglich vorgesehene Nutzungsvariante. Ein Kunde betreibt eine Instanz (eine Installation) von Minasa auf einer Hosting-Plattform. Frontend sowie Daten beziehen sich nur auf diesen Kunden (bsp: thurgaukultur.ch):
Die gesamte Applikation “bedient” einen Kunden, eine Domain (also z.B. thurgaukultur.ch). So beinhaltet die gesamte Instanz die Daten, den Code und die Templates für einen Kunden resp. für eine Domain.
Dies ist das “klassische” Setup für einen Einzel-Kunden ohne weitere Abhängigkeiten.
| Vorteile | Nachteile |
|---|---|
| keine Abhängigkeiten | Betrieb muss selber/alleine organisiert werden |
| eigene Datenhaltung | System-Auslastung ev. nicht optimal |
Eine Instanz, eine Domain/Frontend, Snippets für Drittbezüger
Geeignet für: einzelne Domain, mit Spezial-Seiten für z.B. Dritt-Bezüger
Dieses Szenario ist grundsätzlich genau dasselbe wie das oben gezeigte, mit dem Unterschied, dass einige URL-Routen innerhalb der Domain Spezial-Templates ausliefern.
So kann z.B. eine URL https://thurgaukultur.ch/agenda/robot-output eine speziell aufbereitete Webseite für das automatische Auslesen ausliefern.
An der grundlegenden Architektur und Datenhaltung ändert dies nichts.
Dieses Szenario ist dann interessant, wenn ein Kunde für Spezialaufgaben spezielle Versionen der Frontend-Webseite liefern will (z.B. für kleinere Dritt-Bezüger ohne eigenes System).
| Vorteile | Nachteile |
|---|---|
| eigene Datenhaltung | Betrieb muss selber/alleine organisiert werden |
| kleine Bezüger benötigen kein eigenes System | System-Auslastung ev. nicht optimal |
| Dritt-Bezüger sind auf dieses System angewiesen | |
| keine getrennte Datenhaltung für Dritte |
Eine Instanz, mehrere Domains/Frontends, gemeinsam genutzte Daten
Geeignet für: mehrere Domains mit Bezug resp. gemeinsamer Verwaltung
Dieses Szenario liefert mit einer Instanz verschiedene Frontends aus, getrennt nach Domain, wobei die Daten gemeinsam gehalten und verwaltet werden:
In diesem Szenario findet KEINE physische Trennung von Daten (Events, Adressen, User, Files etc.) statt. Es ist Aufgabe der jeweiligen Frontends, die entsprechenden Daten korrekt zu filtern / anzuzeigen.
Ebenso verwenden alle Benutzer dieser Instanz dasselbe Cockpit, und teilen sich somit auch die hinterlegten Werte wie Tags, Kategorien etc.
Dieses Szenario eignet sich für Kunden, welche sich eine Server-Instanz teilen wollen und mehr oder weniger dieselben Interessen / dieselben Prozesse/Abläufe haben, oder sich sogar die Verwaltung teilen. Es besteht Einblick in alle Daten der jeweils anderen Domain.
| Vorteile | Nachteile |
|---|---|
| Verwaltung kann geteilt werden | Betrieb muss mit allen Partien organisiert werden |
| bessere Auslastung der Hardware | Abhängig von mehreren Partien |
| Datenhaltung ist nicht getrennt |
Eine Instanz, mehrere Domains/Frontends, getrennte Daten
Geeignet für: mehrere Domains ohne Bezug
Dieses Szenario deckt mehrere getrennte Domains mit einer Instanz/Installation ab: Alle Domains werden zwar über dieselbe Installation abgehandelt, aber alle Daten sind komplett getrennt:
Dieses Szenario eignet sich dann, wenn auf derselben Instanz mehrere getrennt verwaltete Kunden betrieben werden sollen: Man kann sich so die Kosten für mehrere Instanzen sparen, oder eine grosszügig ausgelegte Hardware besser auslasten.
Die einzige Abhängigkeit besteht in der Software-Version: Alle Kunden verwenden dieselbe Software: So sind bei einem Software-Update von Azizi auch alle Domains betroffen, heisst, alle Domains müssen gleichzeitig aktualisiert werden.
| Vorteile | Nachteile |
|---|---|
| getrennte Datenhaltung | Betrieb muss mit allen Partien organisiert werden |
| bessere Auslastung der Hardware | Software-Maintenance betrifft alle |
| keine gemeinsame Datennutzung möglich |
Mehrere Instanzen, mehrere Domains/Frontends
Geeignet für: unabhängige, getrennte grössere Kunden/Domains ohne Bezug
Dieses Szenario ist im Grunde keine eigenes: In diesem Szenario wird Minasa mehrfach installiert und separat betrieben:
Dabei gibt es keine gemeinsam genutzten Komponenten, und jede Instanz wird für sich betrieben.
Dieses Szenario wird deshalb hier aufgeführt, weil dies auch in einem gemeinsam genutzten Hosting genutzt werden kann: Viele Hosting-Angebote erlauben das Nutzen einer Hardware, aber getrennten “Containern” für Applikationen. So kann eine gut dimensionierte Hardware für mehrere Kunden genutzt und so besser ausgelastet werden.
| Vorteile | Nachteile |
|---|---|
| getrennte Datenhaltung | Jeder Kunde muss Installation selber betreiben |
| getrennte Software-Installation | keine gemeinsame Datennutzung möglich |
| keine Abhängigkeiten |
beliebige Mischformen
Die oben gezeigten Szenarien decken noch nicht alle möglichen Einsatzformen ab, resp. es sind diverse Mischformen denkbar. Beispielsweise könnten sogar getrennt laufende Instanzen auf dieselbe Datenbank zugreifen.
Es ist schlussendlich genau abzuklären, welche Variante für eine Installation in Frage kommt resp. wie das Setup genau vorgenommen werden soll.