SaaS Applikation: pro Kunde eine Datenbank / Schema oder eine DB für alle Kunden?

[KonradN]

Das einfachste wäre definitiv erstmal bpsw. alles in einer DB zu haben (wie es heute ist).

Ich habe allerdings Angst, dass das dann nicht mehr skalierbar ist bzw. ich gleich am Anfang einen entscheidenen Architekturfehler begangen habe, der mich später enorme Arbeit kostet.

Es ist ja nicht so, dass es das nicht schon viele Jahre geben würde ... Ich verstehe da wirklich nicht das Problem.

Wie viele Daten glaubst Du, wirst du bekommen? Vermutlich wirst Du mit kleinen monatlichen Kosten alle Daten im Speicher halten können ... (Sorry, aber so ein Root Server hat doch direkt mehrere GB Speicher ... Die musst Du erst einmal füllen ... und selbst wenn nicht: Du hast da dann schnelle SSDs für die Daten ... )

Und ein Architekturproblem ist unabhängig von der gewählten Architektur immer ein Problem....

Aber die Chance, dass Du massive Fehler machst, wird um so größer, je größer die Komplexität ist und je weniger Du weisst. Also einen Datenbankserver wirst Du aufsetzen können - hast Du ja auch auf Deinem Mac erfolgreich geschafft.
Das ganze Docker hat Dich doch offensichtlich schon an Deine Grenzen gebracht, dann kommt die komplexe AWS Cloud ... Und noch so Dinge, dass Fehler dann schnell tausende Euro kosten können oder so ....

Sorry, aber mach alles in einen Datenbankserver, mach eine oder mehrere Anwendungen und lass die auf einem Root-Server laufen. Und dann schaust Du, wie Du so Dinge wie Backups hin bekommst. Evtl. ein Filesystem wie GlusterFS, damit die Daten auch auf einem zweiten Root-Server immer parallel sind. Dann kannst Du schnell umschalten (so DNS Records nicht lange gecached werden ... aber da kannst Du ja im DNS etwas setzen wie 5 Minuten oder so ...)
==> Fertig aufgesetzt, Du hast kontrollierte Kosten (ein oder zwei Root Server a < 50€ und du kannst da dann lange mit arbeiten. Skalieren musst Du noch nichts - wenn es zu langsam wird, dann kannst Du größere Rootserver kaufen mit besseren CPUs, mehr Hauptspeicher und so und es schnell umziehen ...

Das was Du da machst ist super, wenn Du es lernen willst. Das ist dann aber nur Training. Aber Du willst daraus ein Business Konzept machen? Das halte ich für etwas sehr übertrieben ...

 

[internet]

Bau die Anwendung so, dass es ihr egal ist, ob eine DB oder mehrere. Und wenn du dann umstellen willst, landen alle neue Kunden in eigenen DBs und alle alten bleiben in ihrer gemeinsamen DB. Deiner Anwendung sollte es vollkommen egal sein, ob die Kundendaten in Schema A oder Schema B liegen.

wie lässt sich das denn z.B. gestalten mit den Subdomains bzw. welche Anwendung welcher User verwendet?
Also bspw. heute habe ich die Anwendung mit einer Webanwendung und einer Datenbank (mandantenfähig).
Später habe ich dann vllt. eine Dockerinstanz pro Kunde.
Bräuchte ich nicht heute schon eine Subdomain pro Kunde?
Heute zeigt das eben alles auf die Anwendung mit einer Datenbank, später dann auf die jeweilige Dockerinstanz?

Wie lässt sich das generell denn einstellen? Was brauche ich dazu? Wie kann man das automatisiert erstellen?
Bei mir lokal müsste das ja dann so aussehen: customer1.localhost:8080, customer2.localhost:8080 usw.

Muss ich sonst etwas über den User in einer Tabelle bereits speichern?
Mandant1 nutzt Server1... usw. vllt?

 

[KonradN]

wie lässt sich das denn z.B. gestalten mit den Subdomains bzw. welche Anwendung welcher User verwendet?

Eine Möglichkeit ist ein vorgeschalteter Webserver (Apache, nginx, ….)

Da kannst du dann per Proxy Konfiguration Requests weiter geben.

Und nebenbei handelst du auch Dinge ab wie SSL so dass du das nicht mehr brauchst in allen Docker Containern.

 

[internet]

Eine Möglichkeit ist ein vorgeschalteter Webserver (Apache, nginx, ….)

Da kannst du dann per Proxy Konfiguration Requests weiter geben.

Und nebenbei handelst du auch Dinge ab wie SSL so dass du das nicht mehr brauchst in allen Docker Containern.

Und diese Subdomain wird dann beim registrieren des Users erstellt?
Ist Traefik hier auch eine Alternative?

 

[KonradN]

Und diese Subdomain wird dann beim registrieren des Users erstellt?

Du musst das natürlich dann alles konfigurieren. Die genauen Abläufe musst Du kennen / wissen, denn Du machst ja das Design.

Ist Traefik hier auch eine Alternative?

Kenne ich nicht, auf den ersten Blick sieht es so aus, als ob diese Funktionalität da auch mit enthalten ist.

 

[internet]

Du musst das natürlich dann alles konfigurieren. Die genauen Abläufe musst Du kennen / wissen, denn Du machst ja das Design.


Kenne ich nicht, auf den ersten Blick sieht es so aus, als ob diese Funktionalität da auch mit enthalten ist.

Der Ablauf ist eig simpel und nichts außergewöhnliches bei SaaS Apps:
1) User registriert sich
2) Subdomain wird erstellt user1.domain.com

Aber geht das auch automatisch bzw. per API Call? Ich möchte ja nicht warten, bis ich die Subdomain erstmal manuell angelegt habe.

 

[KonradN]

Du musst schauen, wie die Systeme, die Du nutzen willst, konfiguriert werden. Bei Apache und nginx sind dies Config-Files und natürlich kann man die auch automatisiert anlegen - sind ja einfache Textdateien.

DNS kannst Du bei den meisten Anbietern per API anlegen, aber Du kannst auch einen wildcard Eintrag anlegen - dann musst Du da nichts mehr machen.

Aber wie immer gilt hier: Schau es Dir im Detail an. Spiel damit herum. Lerne die Produkte, die Du nutzen willst, kennen. Wenn Du sie dann wirklich richtig nutzen willst (gewerblich) dann vertiefe Dein Wissen. Dir sollte klar sein, dass Du - sobald Du etwas gegen Geld anbietest - dafür Support machen können musst. Du bekommst dann auch Anfragen zu irgendwelchen Problemen oder Änderungen. Daher solltest Du Dinge sehr genau kennen. Ein "Ich habe es einmal irgendwie zusammen klicken können" ist aus meiner Sicht nicht im geringsten ausreichend.

Daher: Wenn Du da irgendwas hast, dann spiel in einer Testumgebung damit herum. Was funktioniert wie? Und wenn Du zeitnah in Produktion gehen willst, dann reduziere die Komplexität!

 

[internet]

Apache, nginx war ein guter Hinweis...
Habe mich mal etwas eingelesen...

Prinzipiell geht das doch auch?

1. Jeder Kunde erhält eine Subdomain, das läuft über Wildcard-Subdomains.
2. Die Subdomain wird später zur Laufzeit ausgewertet und auf das entsprechende Datenbankschema / Server umgeleitet
3. Es gibt eine zentrale Datenbanktabelle, die User, Subdomain, Serveradresse, Version speichert.
4. Beim Aufruf der URL bekommt das Skript den Namen der Subdomain übergeben und schaut dann in der zentralen Datenbank nach, ob es diesen Kunden gibt und wo der liegt

Ist das so machbar?

Ich meine bei Apache gibt es ein "Rewrite-Modul"?
Wird die Abfrage (4), dann bei jedem Request durchgeführt?

 

[Oneixee5]

Das Problem mit den Subdomains kann ich noch nicht richtig einordnen. Eine Subdomain muss ich immer irgendwo registrieren. Eine Firma hat eine eigene (mehrere) Domain, die brauchen Proxy- und Firewalleinträge, das muss irgendwo verwaltet und registriert und auf mögliche Kollisionen mit anderen Projekten geprüft werden. Meistens dauert es bis zur Genehmigung etwas. Mein Projekt läuft evtl. schon unter einer Subdomain - dann brauche ich Sub-Subdomains?
Bei privaten Projekten habe muss ich Subdomains bei meinem Registrar verwalten. Ich muss auf der Webseite irgendwelche Einträge durchführen, eine Weiterleitung konfigurieren und evtl. etwas dafür bezahlen.
Beide Verfahren wären natürlich automatisierbar - wenn alle mitspielen, sind aber immer individuell für jeden Anbieter unterschiedlich. Also ich scheue mich immer so etwas umzusetzen. schon Krankheit oder Urlaub kann das Verfahren stören.
Ich denke es ist auch überhaupt nicht notwendig so etwas zu tun.
Der Kunde meldet sich irgendwo an einer Loginplattform an, Keycloak, ActiveDirectory, LDAP, Shibboleth, Authentik, ...
Der Login-Service setzt einen HTTP-Header-Token und der Proxy oder Loadbalancer leitet dann entsprechend weiter. Das ist doch alles keine Magie und sehr einfach umzusetzen. Sollte jemand die Header manipulieren, dann landet man einfach wieder beim Login.

Der andere Punkt: Man kann die Domain auch einfach umstellen, statt:
<kunde>.<domain>.com/<api>|welcome.html
kann ich auch einfach:
<domain>.com/<kunde>/<api>|welcome.html
verwenden. (| bedeuted ODER)
Dann braucht man überhaupt keine Subdomain. Einen Proxy um weiterzuleiten braucht man sowieso, schon um den ganzen Müll abzufischen, wie das Abklopfen auf Sicherheitslücken usw.

 

[mihe7]

Der Login-Service setzt einen HTTP-Header-Token und der Proxy oder Loadbalancer leitet dann entsprechend weiter.

Die Idee gefällt mir sehr gut

 

[internet]

Also, der Vorschlag anstatt für jeden Kunde eine Docker Instanz zu haben, gefällt mir der Ansatz gut, dass ich das System eben mandantenfähig baue und dann das habe:

• Mehrere Server (VPS), auf der jeweils die WebApp und eine Datenbank installiert ist
• Jeder Kunde erhält ein eigenes Schema.

Nun muss ich aber wissen gegen welche Datenbank Instanz und WebApp der entsprechende User laufen soll.

Mein Ansatz wäre nun:
Ich habe das so verstanden, dass es eig. gar keine richtige Subdomain gibt, die man als DNS setzt.
Mein Kunde erhält zwar eine Subdomain (bspw. kunde1.domain.com), die wird aber gar nicht wirklich registriert. Lediglich in einer Datenbank festgehalten.

D.h. wenn mein Kunde "seine Subdomain" aufruft (kunde1.domain.com), dann passiert folgendes:
1) "kunde1" wird aus der URL als Suchvariable herausgeparsed.
2) Nun suche ich in einer zentralen Datenbank (in der u.a. die Kunden sind) nach dieser Subdomain.

ID	subdomain	ServerIP	Version	CreatedAt
1	kunde1	192.111.111	1	2024-01-01

3) Nun weiß ich, dass die Instanz der App auf dem Server 192.111.111 läuft.
4) Der Nginx leitet nun die Anfragen alle gegen 192.111.111 weiter

So mein Verständnis...

 

[Oneixee5]

Nginx und Docker ist viel zu umständlich, das mache ich schon Jahre nicht mehr. Traffik + Docker ist eine Kombi die extra für Docker entwickelt wurde und super funktioniert.
Ich habe mal gegoogelt und erst mal keinen Anbieter gefunden, welcher eine Domain mit Wildcard-Subdomains anbietet. Das muss aber nichts heißen. Wie ich das aber kenne wird eine Wildcard-Subdomain immer auf die Domain umgeleitet. Ich weiß nicht, ob man dann auf dem Server überhaupt noch die Subdomain auslesen kann. Da kenne ich mich zu wenig aus.

 

[KonradN]

Ich habe das so verstanden, dass es eig. gar keine richtige Subdomain gibt, die man als DNS setzt.

D.h. wenn mein Kunde seine Subdomain aufruft (kunde1.domain.com), dann passiert folgendes:

Wenn es die Subdomain nicht gibt, dann passiert nur, dass der Kunde eine Fehlermeldung bekommt bzw. das der Browser dann eine Suche nach kunde1.domain.com startet.

Wenn Du mit Subdomains arbeiten willst, dann musst Du diese auch eintragen. Wenn alle Subdomains zu dem gleichen Server gehen (also z.B.,e in LoadBalancer oder ähnliches oder evtl. auch einfach nur eine Weiterleitung, damit das dann zu domain.com/kunde1 wird oder oder oder), dann kannst Du eine Wildcard Eintragung machen: Wildcard DNS record - Wikipedia

Und das, was Du ansonsten weiter beschreibst, wäre so ein System, aber bitte beachte, dass alle Requests immer durch diesen einen nginx gehen. Das ist etwas, das mir nicht gefällt. Daher würde ich da nicht so arbeiten sondern ich würde da entweder ganz auf Subdomains verzichten:

Der andere Punkt: Man kann die Domain auch einfach umstellen, statt:
<kunde>.<domain>.com/<api>|welcome.html
kann ich auch einfach:
<domain>.com/<kunde>/<api>|welcome.html
verwenden. (| bedeuted ODER)

oder man macht es wirklich so, dass man Subdomains anlegt. Das geht eigentlich bei fast allen (größeren) Anbietern auch über eine API:
Developer API Portal | IONOS
STRATO ServerCloud Metadata API documentation

Oder falls Du eigene Server betreiben wolltest (statt cloud), dann hast Du natürlich alles direkt auf den Servern selbst ...

Wenn Du alles in der Cloud hast, dann willst Du vermutlich keinen Vertrag bei Ionos & Co der deutlich mehr beinhaltet - Anbieter mit reinen DNS Angeboten gibt es auch. Ich bin da bei Schlundtech - da hat man deutlich geringere Preise pro Domain pro Jahr.
XML-Gateway: Domains über eine XML-Schnittstelle registrieren (schlundtech.de)

Und natürlich: Wenn Du in die Cloud gehen solltest, dann sollte es dort auch entsprechende Angebote geben ... bei AWS gibt es z.B.:
Amazon Route 53 – DNS Service – AWS

Das ist also alles absolut kein Hexenwerk.

 

[KonradN]

Ich habe mal gegoogelt und erst mal keinen Anbieter gefunden, welcher eine Domain mit Wildcard-Subdomains anbietet.

Das ist eigentlich bei allen Anbietern, die ich kenne, möglich. Einfach als Host den * eintragen und schon hast Du den Wildcard Eintrag.

Wie ich das aber kenne wird eine Wildcard-Subdomain immer auf die Domain umgeleitet.

Du hast eine Zuweisung wie bei normalen Einträgen. Es kann also ein CNAME Eintrag sein aber auch ein AA oder AAA Eintrag. Somit kann es auch eine beliebige IP zugeordnet werden.

Ich weiß nicht, ob man dann auf dem Server überhaupt noch die Subdomain auslesen kann. Da kenne ich mich zu wenig aus.

Das geht alles. Der Server hat ja nichts mit der Namensauflösung zu tun. Dem Server ist es egal, ob die IP per hosts Datei, direktem DNS Eintrag oder einem Wildcard Eintrag gekommen ist. Aus Sicht des Servers ist es immer das Gleiche: Es kommt eine eingehende Verbindung und dann wird der http Request übergeben und ausgewertet.

Sprich es kommt etwas wie:

GET /pfad/zur/ressource HTTP/1.1
Host: subdomain.domain.com

 

[internet]

Und das, was Du ansonsten weiter beschreibst, wäre so ein System, aber bitte beachte, dass alle Requests immer durch diesen einen nginx gehen. Das ist etwas, das mir nicht gefällt. Daher würde ich da nicht so arbeiten sondern ich würde da entweder ganz auf Subdomains verzichten:

Ja, das habe ich mich auch gefragt - wenn ich bei jedem Request eine Abfrage mache auf welchem Server der Kunde landen soll, dann wäre das nicht wirklich von Vorteil bzgl. Performance...

Wie schnell ist denn so eine Subdomain verfügbar?
Prinzipiell ist mein Workflow eben so:

• User registriert sich
• Datenbank Schema wird eingerichtet
• Vordefinierte Tabellen befüllt
• Subdomain erstellt

Wie du beschrieben hast, lassen sich Subdomain auch per API erstellen. Wie schnell geschieht das und wie schnell wäre diese dann für den Kunden bereit? Die Subdomain sollte eben direkt nach dem Registierungsprozess zur Verfügung stellen und eben komplett automatisch geschehen...
Muss ich die Subdomain beim Domain Provider erstellen oder läuft sowas auch über den Nginx?

 

[KonradN]

Alle neuen DNS Einträge sind direkt verfügbar. Der Ablauf ist halt:
Client fragt seinen DNS Server nach dem Namen.
Da der DNS Server den Namen noch nicht kennt, muss er weiter fragen. (Das ist dann entweder ein anderer, fester DNS Server oder es geht über die Root Nameserver, die dann den zuständigen DNS Server benennen)
Auf jeden Fall landet dann der Request bei einem für die Domain zuständigen Nameserver und der hat den Eintrag durch die API Calls bekommen.

Zeitlich problematisch sind nur Änderungen. So Informationen werden eine gewisse Zeit gespeichert. Diese Zeit kannst Du vorgeben und kann vieles sein von wenigen Sekunden bis hin zu Tagen. Wenn Du schnell umschalten können willst, dann sollte man sowas ggf. relativ niedrig halten... Das ist aber ein anderes Thema.

Muss ich die Subdomain beim Domain Provider erstellen oder läuft sowas auch über den Nginx?

Du musst den DNS Eintrag haben und natürlich die Konfiguration im nginx.

 

[internet]

Du musst den DNS Eintrag haben und natürlich die Konfiguration im nginx.

Das heißt ich muss:
1) die Subdomain bei meinem Domain Provider eintragen und
b) die Subdomain dann nochmal in Nginx eintragen?

 

[KonradN]

Das heißt ich muss:
1) die Subdomain bei meinem Domain Provider eintragen und
b) die Subdomain dann nochmal in Nginx eintragen?

Ganz genau. Spiel es doch einfach einmal manuell durch. Das sind ja alles Dinge, die man problemlos testen kann.

Dann kannst Du auch Traffik ausprobieren. @Oneixee5 hat in #62 sein Vorgehen geschildert und das klang doch recht gut. Evtl. sind die Dinge da anders / besser zu konfigurieren.

Ich würde Dir auf jeden Fall raten, da ein bisschen herum zu spielen. Einfach mal testweise etwas aufbauen.

 

[internet]

Ich habe mir das nun einfach mal bildlich aufgemalt. Insbesondere "Domain Anbieter" und dann die Verbindung zu meinem Netzwerk ist mir nicht so klar....

Zum Einen benötige ich ja erstmal eine Domain.
Beispielsweise: www.mycompany.de
-> Dies könnte ich ja bspw. bei Strato.de registrieren

Dann habe ich:

Mein Eigenes Netzwerk
hier läuft dann eben meine Applikation. Hier habe ich eine Trennung zwischen Admintools (Server1) und Server2 (die Applikation selbst). Das Ganze könnte man natürlich noch weitertreiben, u.a. den Datenbank Server nochmal auftrennen. Das Monitoringtool auf einem anderen Server (noch besser anderes Netzwerk) laufen lassen.
Hier soll der Zugriff dann über die Subdomains laufen: www.kunde1.mycompany.de
Oder auch www.monitoring.app.mycompany.de -> Wäre dann der Zugriff auf (Zabbix = Monitoringtool).
Zusätzlich wäre später auch geplant, dass jeder Kunde auch eine Backup Lösung erhält, die dann unter anderem über:
www.test.kunde1.mycompany.de aufrufbar wäre.

Wordpress
Das Ganze soll eine reine Unternehmensseite sein. Also die dann unter: www.mycompany.de läuft.



Ist mein Verständnis so richtig, dass ich:

a) Bei Strato die ganzen Subdomains anlege

b) Die Anfragen weiterleite an meinen Nginx Server. Hier muss ich dann nochmal die Subdomain eintragen und dann das interne Routing bereitstellen, sodass kunde1.mycompany.de auf Server2 (WebApp) landet und kunde2.mycompany.de auf Server3 (WebApp)

c) Die normale Seite (keine Subdomain - www.mycompany.de) leite ich an die IP Adresse von allinkl.de um, wo die Wordpress Seite aufgerufen wird.

Dann stellt sich mir noch die Frage, wie das mit der Weiterleitung ist...
Wenn ich bspw. kunde1.mycompany.de weiterleite, sollen ja jegliche Anfragen (also die einzelnen Seiten) an kunde1.mycompany.de die URL kunde1.mycompany.de haben und nicht bpsw. die IP Adresse des Servers. Wie geschieht das denn?

 

[mihe7]

Ist mein Verständnis so richtig, dass ich:

Ja.

Dann stellt sich mir noch die Frage, wie das mit der Weiterleitung ist...

Du trägst im Nameserver (Strato) für kunde1.mycompany.de die IP-Adresse Deines Reverse-Proxies (bei Dir also die IP-Adresse von Server1) ein. Der Reverse-Proxy ist derart konfiguriert, dass Anfragen an den jeweiligen Server (oder Docker-Container) weitergeleitet werden.

Wenn ich bspw. kunde1.mycompany.de weiterleite, sollen ja jegliche Anfragen (also die einzelnen Seiten) an kunde1.mycompany.de die URL kunde1.mycompany.de haben und nicht bpsw. die IP Adresse des Servers. Wie geschieht das denn?

Im nginx wird der Host weitergegeben: proxy_set_header X-Forwarded-Host $host;. Der Wildfly muss entsprechend konfiguriert werden: https://docs.wildfly.org/19/wildscr...ener/index.html#attr-proxy-address-forwarding

 

[KonradN]

Sehe ich das richtig: Du bist jetzt weg von Docker / Cloud?

Dann macht es evtl. Sinn, sich etwas mehr mit dem Thema Cluster auseinander zu setzen. Sowohl wildfly als auch die meisten Datenbanken unterstützen das.

Wenn die Anwendung im Server selbst keinen State hält sondern alles an die Datenbank gibt, dann reicht es evtl. sogar aus, einfach mehrere Wildfly zu haben und auf allen sind alle Anwendungen deployed. Dann kann ein Load Balancer die Clients verteilen und so ...

Und bei Datenbanken kann es auch erst einmal reichen, einen Mirror von jeder Datenbank zu haben und bei der Verbindung auch den Failover Partner mit anzugeben.

Das aber einfach unabhängig von den letzten Fragen, weil es mir bei der Betrachtung so durch den Kopf gegangen ist.

 

[internet]

Sehe ich das richtig: Du bist jetzt weg von Docker / Cloud?

Ja, von Cloud bin ich erstmal weg. Da sind mir die Kosten nicht so transparent, im Gegensatz zu bspw. 3 VPS.
Docker ist generell weiterhin eine Alternative. Allerdings bin ich davon weg, dass ich pro Kunde eine Docker Instanz betreibe.

Der Ansatz gefällt mir besser:

• Pro Kunde ein Schema
• Auf einem Server einen App Server, auf dem sich dann bpsw. 100 Kunden anmelden
• Routing auf welchem App Server / Datenbank der Kunde landet, erfolgt dann über eine Datenbank / Subdomains.

• Für einzelne Kunden könnte ich dann immer noch eine ganze Docker Instanz hinstellen.
• Die Schemas sind schön getrennt, sodass ich relativ schnell den Kunden auch auf eine andere Datenbank umziehen könnte

Wenn die Anwendung im Server selbst keinen State hält sondern alles an die Datenbank gibt, dann reicht es evtl. sogar aus, einfach mehrere Wildfly zu haben und auf allen sind alle Anwendungen deployed. Dann kann ein Load Balancer die Clients verteilen und so ...

Was meinst du mit keinen State hält? Klar, es gibt natürlich auch @SessionBeans / @ApplicationsBeans... Nicht alles ist in der Datenbank persistiert...

 

[KonradN]

Was meinst du mit keinen State hält? Klar, es gibt natürlich auch @SessionBeans / @ApplicationsBeans... Nicht alles ist in der Datenbank persistiert...

Was ist, wenn es zwei Sessions gibt und die auf unterschiedlichen Servern bedient würden. Wäre das ein Problem?
(Wäre prinzipiell auch egal - man muss ja nicht mehrere Instanzen einer Anwendung auf. mehreren Servern aktiv nutzen)

Der Punkt ist halt, dass Du sehr viel Ausfallsicherheit bekommen kannst, in dem Du alles auf zwei Systemen hast. Dann hast Du auf jedem System z.B. nginx + webfly mit allen anwendungen und alle Datenbanken.
Durch DNS gehen Kunden entweder auf den einen oder anderen Server. (Du brauchst ja nicht zwingend zentralen Einstiegspunkt). Datenbanken haben alle ein Mirror auf dem anderen Server.

Im Normalfall hast Du dann, dass wenn der DNS eines Kunden auf Server1 zeigt, dann ist die Datenbank auch auf Server1 aktiv (und auf Server 2 ist die Datenbank dann passiv). Fällt nun Server1 aus, dann musst Du nur:

• DNS Umschalten von Server1 auf Server2
• Datenbank auf Server2 aktiv schalten

fertig

Und die Last kann dann auch sehr gut verteilt werden. Du kannst halt schauen, was für Anfragen bei welchem Kunden eingehen um dann die Last zu verteilen. Sollte die Performance nicht ausreichen, dann kannst Du weitere Server hinzu nehmen.

Und Du brauchst da erst einmal nichts, was so ein Standard Root-Server so mit sich bringt. Wenn Du später mit Clustern arbeiten willst, dann musst Du genauer schauen, was Du wie brauchst. Ich kenne es nur von euserv. Die haben da entsprechende Möglichkeiten (Dann sind die Server noch untereinander vernetzt und Du hast nach außen auch noch zusätzliche IPs, die dann für Services verwendet werden und die halt zu einem der Nodes verweisen und so ... Komplexes Thema - aber wie gesagt: Das wirst Du lange nicht brauchen!

 

[Dukel]

Wenn deine Kernkompetenz bei der SW Entwicklung liegt würde ich versuchen das Thema Betrieb abzugeben. Mir einen Dienstleister suchen, der deine Applikation als SAAS Lösung hostet.

Schau dir z.B. https://aws.amazon.com/de/saas/ an.

 

[internet]

Wenn deine Kernkompetenz bei der SW Entwicklung liegt würde ich versuchen das Thema Betrieb abzugeben. Mir einen Dienstleister suchen, der deine Applikation als SAAS Lösung hostet.

Schau dir z.B. https://aws.amazon.com/de/saas/ an.

wie gesagt, Cloud (AWS) will ich (erstmal) meiden...

 

[KonradN]

wie gesagt, Cloud (AWS) will ich (erstmal) meiden...

Die Idee, dass Andere einem alles hosten ist aber dennoch ein valider Ansatz. Dann kannst Du Dich auf Deine Kernkompetenz Softwareentwicklung konzentrieren ...

So kannst Du generell schauen, ob Du Anbieter findest, die direkt ein Hosting anbieten, das Dir alles abnimmt also incl. dem WildFly (evtl. kannst Du auch auf Tomcat wechseln? Dann hast Du ggf. mehr Anbieter?)

Aber auch sonst gibt es Managed Server von einigen Anbietern. Dann ist der Server selbst verwaltet und Du hast deutlich weniger Probleme. Generell solltest Du so viel wie möglich Dritten überlassen, denn mir scheint, dass Dir viel Expertise in dem Bereich Betrieb von Servern fehlt.

So Dinge wie Email Server würde ich gar nicht selbst betreiben wollen - das dürfte sehr schnell nach hinten losgehen, denn jeder Config-Fehler rächt sich sofort durch ein Blacklisting. Und Du kannst sicher sein, dass Google und Co nicht interessiert, was Du bezüglich Deines Servers sagst ...

Und schon so Dinge wie das "Hardening" sind wichtig. Du willst sicher gehen, dass Dein Server nicht gehackt wird. Und wenn, dann willst Du, dass das sofort auffällt für Gegenmaßnahmen....

Managed Server können also eine gute Alternative sein - die Frage ist nur, ob Du da Anbieter findest, die auch ein WildFly oder Tomcat mit managen für Dich.

Cloud in etwas "einfacher" gibt es auch. Statt direkt auf AWS und Co zu setzen wäre eine Möglichkeit, hier auch Dienste eines Providers zu nutzen. Strato bietet auch an, dass Du Anwendungen hostest. Das wäre dann vermutlich wieder der docker Container....

Also Merke: Je mehr Administration Du an "Profis" abgeben kannst, desto besser. Wenn etwas schief geht, dann braucht man KnowHow um das Problem schnell zu lösen. Und die Fragen sind: "Hast Du das?" bzw. "Willst Du das?".

 

[LimDul]

Um einen Punkt von mir noch mal zu wiederholen. Baue die Anwendung softwaretechnisch so, dass ihr der Betrieb möglichst egal ist. Sprich, alles relevante nicht hart verdrahten sondern in entsprechende Konfigurationen auslagern. Mittlerweile kann man auch im Wildfly gezielt einzelne Konfiguration von außen hinterlegen und muss nicht immer eine komplette standalone.xml bereitstellen (https://www.wildfly.org/news/2022/04/26/YAML-configuration-extension/). Selber hab ich das Feature noch nicht genutzt, weil wir mittlerweile fast komplett auf Spring Boot sind.

Aber z.B. zum Thema getrennte Datenbanken vs. alles in einer Datenbank.

Baue die Anwendung mandatenfähig. Wenn klar ist, dass gewisse Daten auf jeden zentral kommen sollen, andere aber ggf. aus einer eigenen Datenbank, dann ist das Minimum an Architektur-Anforderung, dass der Zugriff auf die zentralen Daten durch eine technische Komponente (z.B. eine oder mehrere Beans) gekapselt sind. Evtl. kann man sogar soweit gehen grundsätzlich 2 Datasources vorzusehen. Dann ist es der Anwendung egal ob beide Datasources auf die gleiche oder unterschiedliche Datenbanken verweisen.

Gleiches gilt für URLs für den externen Zugriff - konfigurierbar. Keycloak Urls, Secrets etc. - konfigurierbar. URL unter der die Anwendung für den Benutzer erreichbar ist - konfigurierbar.
Dann am besten das ganze in ein paar Szenarien erproben (Ein Server, Docker Container, aws/azure). Nur um zu testen ob es geht.

Denn wenn ich richtig mitgelesen habe, bist noch nicht produktiv, hast also noch keine Kunden. Und es gibt aus meiner Sicht keine One Size fits it all Lösung. Eine superskalierbare Lösung (egal ob AWS, Azure, kubernetes bei Anbieter xy) hat eine Grundkomplexität die nicht ohne ist. Merkt man ja hier. Entweder man erarbeitet sich das Wissen (kostet Zeit) und macht vieles selber (kostet Zeit und ist ein Risiko, wenn man sich nicht gut auskennt) oder man beauftragt jemanden (kostet Geld). Sprich die Lösung hat einen Sockel, den man investieren muss, damit diese Lösung überhaupt funktioniert. Die rechnet sich um so mehr, je mehr Kunden man hat, weil man dann z.B. auch CPU Resorucen gut sharen kann die Grundkosten durch viel mehr Kunden geteilt werden.

Startet man mit einer ganz simplen Lösung, Datenbank & wildfly/root Server gemietet, muss man vielleicht pro Kunde deutlich mehr Aufwand investieren den einzurichten. Weil es eben nicht out of the box geht, sondern man Configs manuell anlegen muss etc. Man ist deutlich schlechter skalierungsfähig - aber hat dafür deutlich weniger Kosten. Mit mehr Kunden fällt der Overhead um so mehr ins Gewicht. Wenn deine Anwendung aber so gebaut ist, dass sie beide Betriebsmodi kann, kannst du sukzessive migrieren. z.B. neue Kunden in eine skalierungsfähige Cloud Lösung schieben und die alten erst mal auf dem Root Server belassen. Und dann diese mit geplanten Downtimes umziehen, sobald die Resourcen für so einen Umzug zur Verfügung stehen.

Am Ende muss du alles durchkalkulieren, wie viel kostet was und dir einen Businessplan überlegen, wie viel soll deine Anwendung kosten. Und da halt auch mal diverse Szenarien durchrechnen. Angefangen mit "Wie viel Kunden brauche ich um profitabel zu werden", "wie viel Wachstum kann ich wie verkraften". Was ist, wenn wenn ich extrem Erfolg habe - wie schnell kann ich reagieren. Was ist wenn, ich keinen Erfolg habe, wie viel Verlust wie lange kann ich mir leisten etc. Dafür ist es aber wichtig die verschiedenen Betriebsmodi mal zu kennen und auch in Ruhe mal durchrechnen zu können.