Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder ein alternativer Browser verwenden.
SaaS Applikation: pro Kunde eine Datenbank / Schema oder eine DB für alle Kunden?
ich bin kein Experte, was Hosting & Infrastruktur anbelangt.
Ich plane eine Applikation (CRM / ERP) auszurollen, die von mehreren Kunden nutzbar ist - also eine klassische SaaS Anwendung.
Die Applikation soll natürlich skalierbar sein. Anfänglich werden es nur eine handvoll an Kunden sein, aber theorethisch vllt. auch mal mehrere tausend.
Aktuell habe ich eine Datenbank, die von mehreren Kunden genutzt wird, was auch so funktioniert - allerdings habe ich noch nicht die Erfahrung mit gleichzeitiger Nutzung von mehreren hundert oder gar tausend Usern.
Nun habe ich von einer anderen SaaS - Applikation mitbekommen, dass diese mehrere Kunden jeweils auf einer VM haben.
In Summe aber mehrere VM´s.
Ich kenne nun nicht die Details dieser Firma, aber ich meine gelesen zu haben, dass sie ca. 90 VM´s haben mit ca. 1000 Kunden.
Vermutlich dann eben auch pro VM eine Datenbank Instanz und pro Kunde ein Schema.
Kann hier jemand vielleicht direkt aus der Praxis berichten?
Grundsätzlich sind Datenbanken dafür ausgelegt viele Daten zu verwalten. Brauchen halt vor allem Ram, große Datenbanken brauchen entsprechend viel RAM.
Oft ist es so, dass zwar die Anwendungen in eigenen Containern/VMs laufen, die zugehörige Datenbank aber zentral läuft auf Hardware die entsprechend potent ist (Entweder echtes Blech oder eine entsprechend große VM).
Da kommt oft eh nicht drum, die DB getrennt von den Anwendungen laufen zu lassen, wenn man horizontal skalieren will, sprich im Falle von Lastspitzen einfach weitere Instanzen der Anwendung hochfahren will. Die müssen ja alle auf die gleiche DB zugreifen. Zudem braucht man bei der DB oftmals auch eine gewisse Verlässlichkeit, da kann ich nicht mal eben den DB Container neustarten. Das spricht dafür die Datenbanken auszulagern. Ob man dann am Ende wirklich eine zentrale haben will oder mehrere kleine ist auch eine Frage der Verfügbarkeit von Hardware - für eine große DB brauch ich halt was Leistungsfähiges, während ich für kleinere Instanzen auch mehrere kleinere Server nehmen kann
Grundsätzlich sind Datenbanken dafür ausgelegt viele Daten zu verwalten. Brauchen halt vor allem Ram, große Datenbanken brauchen entsprechend viel RAM.
Kann man so nicht sagen, aber um ein Gefühl zu bekommen: was bedeutet "viel RAM" ?
Dass die ".war" - Datei (Webapplikation), dann auf mehreren App - Servern liegt, ist erstmal klar und dann eben an eine DB connected ist.
Meine Sorge ist, dass die App in die Knie geht aufgrund von zu vielen DB - Abfragen.
Die offensichtliche Vor- und Nachteile den Mandant (Kunde) auf einer eigenen DB oder Schema auszulagern sind durchaus klar. Bei näherer Betrachtung habe ich aber einige Fragezeichen bei der Entwicklung dann.
Was das für die Datenbank - Entwicklung mit JPA / Hibernate dann aber anbelangt, ist mir komplett unklar.
Die Google - Suche ergibt zwar, dass das durchaus machbar ist (Stichwort: Multitenant).
Wie erhalte ich dann aber bei mehreren Datenbanken wiederum Informationen, die ich als App - Betreiber benötige (Anzahl Mandanten, wie oft wird sich angemeldet etc.). Hierzu müsste ich ja eine Abfrage über alle Datenbanken / Schemas machen können?
Aktuell habe ich eine Datenbank, die von mehreren Kunden genutzt wird, was auch so funktioniert - allerdings habe ich noch nicht die Erfahrung mit gleichzeitiger Nutzung von mehreren hundert oder gar tausend Usern.
Um die Frage mal direkter zu beantworten: Es kommt auf die Applikation an.
Grundsaetzlich haette ich mal gesagt, wenn du Kunden hast welche eine Applikation nur fuer sich bezahlen, also zum Beispiel du hast ein ERP, sagen wir mal eine Lagerverwaltung, und der Kunde nutzt diese nur fuer sich, dann eine eigene Datenbank pro Kunde, unbedingt. Wenn ich mehrere Kunden in einer Datenbank haette, welche in die gleichen Tabellen schreiben (wenn auch mit Mandanten-Feld), wuerde ich mir viel zu sehr in die Hose machen. Die Wahrscheinlichkeit dass etwas schiefgeht und entweder ein Kunde fremde Daten sieht, oder man die Daten mehrerer Kunden beeinflusst wenn man etwas in der Datenbank macht, ist einfach viel zu hoch. Das mindeste sollten eigene Datenbanken/Schemas (nicht eigene Server) sein, weil dann hat man die Kundendaten alle schoen sauber getrennt. Damit erhoeht sich natuerlich der Wartungsaufwand, weil anstelle eines Schemas, muss mann viele pflegen, aber die Trennung ist halt einfach etwas was ich machen wuerde weil alles andere zu gruselig ist.
Also du hast dann einen Server mit mehreren Datenbanken/Schemen:
Physischer Server
Datenbank
Schema - Kunde 1
Tabelle A
Tabelle B
Tabelle C
Schema - Kunde 2
Tabelle A
Tabelle B
Tabelle C
Schema - Kunde 3
Tabelle A
Tabelle B
Tabelle C
Alles ist schoen strukturiert und wenn du bei Kunde 2 etwas vermurkst hast du nicht eventuell alle Kundendaten vermurkst. Loeschen von Kundendaten ist auch einfacher, genauso wie das exportieren.
Ich glaube viele wuerden es auch mit Container aufbauen:
Physischer Server
Container - Kunde 1
Datenbank
Schema
Tabelle A
Tabelle B
Tabelle C
Container - Kunde 2
Datenbank
Schema
Tabelle A
Tabelle B
Tabelle C
Container - Kunde 3
Datenbank
Schema
Tabelle A
Tabelle B
Tabelle C
Hat zusaetzliche Vorteile was Isolation angeht, kann komplizierter sein. Da ich aber kein Freund von Containern bin (oder besser gesagt der "alles muss ein Container sein"-Philosophie, kann ich dazu nicht so viel sagen.
Wenn du es so aufbaust, also eine Datenbank/Schema je Kunden, kannst du theoretisch dem Kunden auch ganz einfach ein "Du bist wichtig"-Paket anbieten wo du dem dann seinen eigenen Server hinstellst fuer entsprechendes Geld.
Aktuell habe ich eine Datenbank, die von mehreren Kunden genutzt wird, was auch so funktioniert - allerdings habe ich noch nicht die Erfahrung mit gleichzeitiger Nutzung von mehreren hundert oder gar tausend Usern.
Ich denke, es ist deutlich geworden, dass es viele Möglichkeiten gibt. Aber die Fragestellung hatte ich so verstanden, dass gefragt war, was besser ist. Und da kann man pauschal nicht viel sagen. Die Anforderungen sind halt wichtig. Was für Zugriffe soll es geben? Kann ein Kunde Zugriff auf die Datenbank fordern? Dann wäre es evtl. sinnvoll, das zu trennen, da man so Daten anderer Kunden einfacher schützen kann.
Die Frage ist auch, was es für Last-Trächtige Operationen gibt. Wenn man mehrere Datenbank-Server Instanzen hat, dann kann man besser eine Lastkontrolle durchführen. Dann hat eine Datenbank-Instanz nur begrenzte Ressourcen. Wenn alles in einer Datenbank ist, dann sind die Ressourcen geteilt. Das kann aber auch gewünscht sein, denn so lange man da die Ressourcen nicht zu eng plant, dann haben alle Kunden bessere Performance.
Container und VMs haben den großen Vorteil, dass man viele Aufgaben an die Infrastruktur abgeben kann. Dann hat man deutlich weniger Probleme bezüglich Lastverteilung und so, weil dann VMs im laufenden Betrieb zwischen den Hosts verschoben werden. Wenn die Ressourcen eng werden, dann packt man weitere Server in den Hosting Verbund (oder in die private / hybrid Cloud).
Das sind aber nur die von außen sichtbaren Einflüsse. Es gibt auch viel internes, das wichtig ist: Was für Abfragen werden denn so gemacht? Wen da auf eine Tabelle z.B. viele Locks zukommen, dann macht es eine Auftrennung auf mehrere DB Instanzen evtl. einfacher.
Generell ist das aber eine Frage, die man experimentell ausprobieren kann. Einfach mal die Applikation aufsetzen und ein paar Lasttests fahren. Dann kann man vieles Monitoren oder Tracen.
Und generell gilt: Es wird vermutlich darauf hinaus laufen, dass man mit fast jeder Lösung gut voran kommt. So haben wir bei einem Kunden einzelne, dedizierte SQL Cluster. Und die wurden gefüllt. Wenn es dann eng wurde, dann wurde die Hardware aktualisiert oder es gab einen weiteren Cluster. (Und wir hatten da dann auch einen SQL Cluster komplett mit NVMe SSDs und RAM bis zum abwinken, weil da eine Anwendung als entsprechend kritisch von den Antwortzeiten gesehen wurde und die IO Last entsprechend hoch war.
Prinzipiell tendiere wirklich eher für jeden User ein Schema anzulegen. Aktuell habe ich es mandantenfähig aufgebaut.
Ich kann bei der App Dinge ausrollen, die nicht jeder User gleich haben sollte
User, die mehr Performance benötigen, kann ich auf eigene Instanzen auslagern.
Dahingegen sehe ich aber folgende Fragezeichen:
Was bedeutet das an Overload für mich? Habe ich Möglichkeiten einer Bulk Operation? zB möchte ich in sämtlichen Schemas eine Tabelle droppen, ein Feld ändern usw...?
Wie habe ich Zugriff auf Informationen, die ich als Admin benötige, die aber verteilt in den jeweiligen Tabellen der Schemas liegen? Dinge wie: Login per User, der User selbst...? Wie bekomme ich auf so etwas Zugriff?
Wie kann man das generell implementieren? (Ich nutze JPA und JAVAEE...)
Wie sieht so eine Infrastruktur denn dann aus? Ich habe den für mehrere Kunden jeweils:
Was bedeutet das an Overload für mich? Habe ich Möglichkeiten einer Bulk Operation? zB möchte ich in sämtlichen Schemas eine Tabelle droppen, ein Feld ändern usw...?
Das hast Du out of the box nicht. Aber es ist ja mit einem Script einfach, auf x Datenbanken eine Änderung durchzuführen.
Hier ist eh die Frage, wie Du die Datenbanken verwaltest. Nutzt Du dazu irgend ein Tooling? Dann würde es ggf. eh automatisiert gehen (bei den Code first Ansätzen z.B. aber man kann auch gezielt Tools einsetzen wie Liquibase oder Flyway.
Wie habe ich Zugriff auf Informationen, die ich als Admin benötige, die aber verteilt in den jeweiligen Tabellen der Schemas liegen? Dinge wie: Login per User, der User selbst...? Wie bekomme ich auf so etwas Zugriff?
Da ist die Frage, was Du genau brauchst / willst. Du kannst natürlich auch weiterhin eine zentrale Datenbank haben, in der Du gewisse Informationen sammelst. Da gibt es dann auch genug Tools, die sowas machen wenn man das nicht eigenständig bauen will. (Halt das typische: Daten aus diversen Quellen einsammeln und dann im Frontend zeigen)
Ansonsten bieten Datenbanksysteme auch Datenbankübergreifende Abfragen. Das kann ggf. auch eine Lösung sein, wenn es nur um eine einzelne Abfrage geht, die Du einmalig sehen willst.
Das kann so sein, aber muss nicht sein. Du kannst eine VM haben für die Datenbanken. Das hat aus meiner Sicht, dass Du da dann deutlich mehr Freiheiten hast, weil Du dann auf beiden Seiten beliebig skallieren kannst:
Datenbankcluster mit mehreren Servern auf denen die Datenbanken dann vorhanden sein können mit failover und so. Du kannst auch relativ einfach Last verteilen und im Betrieb dann Datenbanken von einem Server auf einen anderen verlagern.
Du kannst mit mehreren Applikationsservern auf eine Datenbank zugreifen
Zentrale Administration der Datenbanken. Das ist in meinen Augen einfacher als dann z.B. per SSH auf einzelne VMs zuzugreifen um da dann Updates auszuführen.
Das sind aber Dinge, die zu großem Teil pers. Präferenz sind. So habe ich halt einiges an Erfahrung mit SQL Clustern sammeln dürfen und das bewirkt automatisch eine entsprechende Präferenz.
Wie kann man sich das genau mit Docker vorstellen?
Das Ganze bedarf doch aber immer einer manuellen Installation?
Ich hätte gerne einfach folgendes: User meldet sich bei App ab -> erhält seine Datenbank / Installation.
Du kannst Dir das etwa so vorstellen, als ob Du für jeden Kunden (oder jede DB) einen eigenen Rechner hinstellst, wobei alle Rechner auf dem gleichen Linux-Kernel laufen.
Der Ablauf ist wie folgt: Du erstellt/besorgst Dir Images für die Anwendungen, die Du laufen lassen möchtest. Auf Basis von Images kannst Du Container starten. Ein Container ist somit eine Instanz des Images (sprich: der Anwendung) und vergleichbar mit einem eigenen Rechner. Du kannst Netzwerke definieren, Container zu einem Netzwerk hinzufügen oder rausnehmen usw. Außerdem liefert Docker gleich noch einen DNS mit, so dass Du die Container mit Namen im Netzwerk ansprechen kannst.
Da ein Anwendungssystem meist nicht nur aus einer Anwendung sondern wenigstens noch aus einer DB besteht, wirst Du in der Regel je Anwendungssystem mind. zwei Container starten: einmal den Container, der die Anwendung selbst enthält und einmal den Container, der sich um die DB kümmert. Mit docker-compose kann man solche Systeme definieren. Dann reicht ein einfacher Befehl, um alle benötigten Anwendungen des Anwendungssystems zu starten.
In der Regel hat man auch noch ein Repository für seine Images (https://docs.docker.com/registry/). Bei uns baut der CI/CD-Server das Docker Image, schiebt es in unsere Registry und sorgt dafür, dass unser internes Testsystem automatisch mit der neuen Version aktualisiert wird (dabei wird das Image aus der Registry gezogen).
Das sollte durchaus machbar sein. Hängt aber auch ein wenig damit zusammen, wie der Kunde seine Installation anspricht. Subdomain? Dann musst Du natürlich auch die Subdomain programmatisch anlegen können.
Das sollte durchaus machbar sein. Hängt aber auch ein wenig damit zusammen, wie der Kunde seine Installation anspricht. Subdomain? Dann musst Du natürlich auch die Subdomain programmatisch anlegen können.
Das sollte durchaus machbar sein. Hängt aber auch ein wenig damit zusammen, wie der Kunde seine Installation anspricht. Subdomain? Dann musst Du natürlich auch die Subdomain programmatisch anlegen können.
Also ich mache etwas ähnliches mit Docker (-Compose). Dabei nutze ich https://traefik.io/traefik/ als Proxy. Wenn ich dann einen Docker-Container erstelle, dann setze ich verschiedene Labels. Wie das aussieht ist unter dem Link erklärt. Diese Labels bringen Quasi eine Konfiguration für Traefik mit. Wird ein Container hochgefahren, dann wird er automatisch im Proxy angemeldet und ist von außen unter einer bestimmten URL erreichbar - wenn eingestellt (und andersrum). Auf die Art kann man auch skalieren. Traefik kann auch Load-Balancing. Natürlich muss dein Anwendung das auch können. Auf diese Art bekomme ich auch ein unterbrechungsfreies Deployment hin. Sowie das Starten und Stoppen von Containern die nicht so oft gebraucht werden (die starten sobald die öffentliche URL aufgerufen wird). Und auch Angebote für bestimmte Security Features für bestimmte Container, usw. Auch das kann Traefik, evtl. mit Plugins.
Das Schöne ist, man bekommt mit Docker auch eigene Netzwerke, damit sind die Anwendungen nicht nur in eigenen Containern, sondern zusammengehörige Container sind in eigenen Netzwerken.
Mit Microk8s/Kubernetes oder anderer Software in die Richtung, bekommt man das auch leicht über physische Server verteilt. Wobei in meinem Fall nur 2 vorhanden sind. Mit externen Hostern habe ich das noch nicht versucht. Das ist aber noch ein Vorhaben. Da ich das alles über 2 verschiedene Standorten verteilt haben möchte.
Du brauchst halt Docker. Ansonsten empfiehlt sich noch docker-compose Du kannst fertige Images von Docker-Hub verwenden - oder eben selbst welche bauen.
Mit
Code:
docker pull mysql:8
ziehst Du z. B. das Docker-Image für mysql in der Version 8 (aktuell wäre das 8.1.0, s. https://hub.docker.com/_/mysql). Unter dem Link findest Du auch eine Anleitung für das Image (Starten eines MySQL-Containers inkl. Vergabe des Root-Passworts usw.)
Brauche ich in dem Docker Container kein Betriebssystem, zB Linux? Ich habe auch etwas gelesen von "Docker WSL" zu installieren?
Wenn ich zB tatsächlich 1000 Kunden habe und ich habe 1000 Docker Installationen, wie kann ich das automatisiert durchführen, sodass meine .war - Datei auf allen Installationen aufgespielt wird?
Wie sieht das dann in der Architektur aus, sodass Kunde1 nur auf seinen Docker Container zugreift. Also Beispiel: kunde1.myapp.com.... Nun gelangt Kunde1 zu seiner Installation?
Wie geschieht es, dass sobald sich ein Kunde registriert, dass ein neuer Docker Container in ein paar Sekunden erstellt wird und der neue User dann direkt eingeloggt ist? (Eben wie eine klassische SaaS Software tickt...) ?
Im Container ist bereits ein Betriebssystem drin. Die WSL ist eine Alternative zu Docker Desktop
[*]Wenn ich zB tatsächlich 1000 Kunden habe und ich habe 1000 Docker Installationen, wie kann ich das automatisiert durchführen, sodass meine .war - Datei auf allen Installationen aufgespielt wird?
Wenn wir über 1000 reden, dann wäre evtl. sowas wie kubernetes mal zu überlegen. Ansonsten halt Skripten. Oder sowas wie https://www.portainer.io/ - es gibt zug Lösungen.
[*]Wie sieht das dann in der Architektur aus, sodass Kunde1 nur auf seinen Docker Container zugreift. Also Beispiel: kunde1.myapp.com.... Nun gelangt Kunde1 zu seiner Installation?
[*]Wie geschieht es, dass sobald sich ein Kunde registriert, dass ein neuer Docker Container in ein paar Sekunden erstellt wird und der neue User dann direkt eingeloggt ist? (Eben wie eine klassische SaaS Software tickt...) ?
Das habe ich noch nie verwendet, unter Linux brauchst du das nicht. Ich habe einen Docker-Container in welchem https://www.portainer.io/ läuft. Damit kannst du das gut verwalten.
Zunächst einmal ist ein Container nicht mit einer normalen VM vergleichbar. Es wird also kein virtueller Rechner gestartet, dem man dann ein komplettes Betriebssystem unterschieben muss.
Ein Container läuft also grundsätzlich unter dem Betriebssystem des Hosts. So gesehen würde kein Betriebssystem benötigt, allerdings besteht das Betriebssystem nicht nur aus dem Kern sondern auch aus einer Vielzahl von Bibliotheken und Tools. Denk mal z. B. an die Shell oder Bibliotheken wie libc, openssl usw. Ohne die wird es schwierig. All diese Sachen müssen im Container zur Verfügung gestellt werden. Daher enthält ein Image für einen Container praktisch immer ein Betriebssystem.
Das ist ja gerade der Witz von Containern: man spart Ressourcen und vor allem Startzeiten (die fallen praktisch so gut wie weg).
Bzgl. der Ressourcen: bei einer VM musst Du für jede Instanz erstmal Platz für das Betriebssystem reservieren, das im Betrieb dann natürlich auch noch CPU-Zeit frisst. Das ist bei Containern anders. Docker verwendet ein Dateisystem, das in "übereinanderliegenden Schichten" arbeitet. In jeder Schicht sind nur die Änderungen zur vorangegangenen Schicht gespeichert. Die Schichten im Image sind read-only und haben alle eine ID.
Nehmen wir mal an, das Ubuntu-Image hätte 1000 MB. Jetzt erstellst mit diesem Image 100 Container. Wie viel Platz wird alleine für die 100 Betriebssystem-Instanzen benötigt? Antwort: 1 GB, denn jeder Container basiert auf dem gleichen Image.
Sagen wir mal, Du baust auf Basis dieses Images ein Wildfly-Image. Nehmen wir an, der Wildfly benötigt 200 MB, dann bestünde Das Wildfly-Image aus dem Ubuntu-Layer (1000 MB) und dem Wildfly-Layer (200 MB).
Analog dazu baust Du dir noch ein Payara-Image: Ubuntu-Layer (1000 MB) und Payara-Layer (300 MB).
Lässt Du Dir jetzt die Images anzeigen, trifft Dich erstmal der Schlag: ein Ubuntu-Image 1000 MB, ein Payara-Image 1300 MB und ein Wildfly-Image 1200 MB.
Der Witz ist: jeder Layer existiert nur einmal. D. h. auf der Platte belegt das Ubuntu-Image 1000 MB, das Payara-Image 300 MB und das Wildfly-Image 200 MB (Zahlen nur ganz grob).
Wenn Du jetzt Dein Anwendungs-Image baust, dann kommt halt einfach noch die Größe Deiner Anwendung obendrauf. Bei vier Apps (sagen wir mal je Anwendung 20 MB) auf Widlfly hast Du am Ende vier Anwendungs-Images, die jeweils 1220 MB groß sind, tatsächlich aber nur 20 MB belegen plus einmalig 1200 MB für Ubuntu und Wildfly.
Wenn Du einen Container startest kommt ein read-write-Layer obendrauf. Alles, was Du im Container schreibst, änderst, löschst etc. wird dort abgelegt. Die Image-Layer bleiben davon unberührt. Das ist natürlich relativ lahm und man will Daten auch nicht im Container haben, daher mounted man in der Regel Volumes, so dass ganz normal das Dateisystem des Hosts verwendet wird. Macht auch das Backup einfacher.
Wie geschieht es, dass sobald sich ein Kunde registriert, dass ein neuer Docker Container in ein paar Sekunden erstellt wird und der neue User dann direkt eingeloggt ist? (Eben wie eine klassische SaaS Software tickt...) ?
In der Regel ist es doch so, dass sich ein Kunde registriert und dann erstmal einen Prozess durchläuft und am Ende kann er sich anmelden. Ansonsten ist er ja bereits angemeldet und dann ist das halt eine Frage des SSO.
Insofern sehe ich die Startzeit des Containers auch nicht wirklich kritisch. Bei uns dauert es etwa eine Minute, bis man sich am System anmelden kann (der App-Server braucht halt seine Zeit, wobei man das noch optimieren könnte). In der Zeit werden MySQL und Glassfish gestartet und die Anwendung wird deployed. Wenn Du richtig schnell starten musst, wäre Quarkus etwas. SpringBoot sollte auch schneller sein und ich weiß gar nicht, wie das jetzt mit Jakarta EE 10 aussieht. Jedenfalls ist die Zeit, die der Container selbst zum Start benötigt, vernachlässigbar. Ich habe z. T. Befehlszeilen-Tools mit Docker-Container im Einsatz. Da merkst Du eine kleine Verzögerung.
Du kannst ja mal
Java:
docker run --rm ubuntu ls
(statt ubuntu natürlich Dein Image verwenden) ausführen.
Ich bin mir leider immer noch sehr unsicher, wie ich fortfahren soll.
Hier nochmal ein paar Informationen dazu:
Aktuell läuft die Applikation auf einer MySQL Datenbank in einem Schema.
Als App Server wird ein Wildfly verwendet
Das System ist so aufgebaut, dass man sich als User (auch Mandant) anmeldet und dann eben sein Bereich hat (Rechnungen, Kunden usw.). Sprich die meisten Entities (bspw. Kunde) haben eine Referenz auf den User (Mandant), sodass man eben genau sieht welcher Kunde zu welchem Mandant gehört.
Nun gibt es auch einige Entities (Administrationstabellen), die nur für den Admin relevant sind, jedoch vom Mandant irgendwo genutzt werden, wie Währung, Länder, Währungskurse usw.
Es gibt auch z.B. Vorlagen von einem Admin erstellt, die dann quasi kopiert werden für den Mandant. Also der gleiche Datenbank Eintrag wird kopiert, aber als Fremdschlüssel noch den Mandant hinzugefügt.
Die Alternative wäre eben pro Mandant ein eigenes Schema anzulegen. Dann sehe ich aber das folgende Probleme:
Technische Umsetzung wie man bei der Anmeldung ein neues Schema erstellt.
Was passiert wenn es ein Update der App gibt und neue Spalten etc. hinzukommen? Wie erfolgt dies bei bpsw. 2000 Datenbank Schemas?
Vorteil wäre natürlich, dass das System für jeden Mandant erstmal gekapselt ist und durch einen Bug bspw. der Mandant auf einmal andere Kunden sieht usw.
In welchem Schema speichere ich bspw. den Mandant. Denn als Administrator will ich ja mal auch eine Analyse machen: - wieviel Mandanten habe ich - Wer hat sich wann angemeldet?
Innerhalb einem Schema ist das ja alles kein Problem.
Prinzipiell läuft das alles bisher innerhalb einem Schema.
Ich habe allerdings etwas Bedenken, ob ich früher oder später mal enorme Performance - Probleme bekommen könnte.
Aktuell ist die App noch nicht live und ich hätte noch die Chance architekturiel zu handeln.
Klar, ein großer Vorteil sehe ich dadurch, dass man bspw. KundeA hat schon Version 1232 ausrollen kann, wohingegegen KundeB noch auf Version 1231 ist.
Aber dem Gegenüber steht der massive Aufwand die verschiedenen Schema zu verwalten usw.
Wie läuft das denn bei den klassischen SaaS Anwendungen?
Ich denke, das ist am Ende eine Entscheidung, die Dir hier keiner abnehmen kann. Du machst Dir zu viele Gedanken: Du hast ein mandantenfähiges System, das kannst Du lassen, Du musst ja nicht mehrere Mandanten anlegen. Du könntest zuerst mit "alles in einem Schema" anfangen, und wenn Dir das zu doof/langsam wird, dann kannst Du die Daten ja rausziehen und zwei oder n Systeme hosten.
Für alles andere gibt es Lösungen: ich habe z. B. einen Halbautomatismus. Wenn ich die Subdomain kenne, rufe ich ein bash-Skript auf und danach laufen die Container für diese Subdomain. Das könnte ich nun programmatisch machen, weil der Hoster eine API zur DNS-Verwaltung anbietet. Und wenn ich wollte, könnte ich das an ein System hängen, über das der Kunde seine Registrierung vornimmt.
Das ist alles relativ flexibel und die Aufwände halten sich in Grenzen.
Hallo, bitte helfen Sie, wenn ich alles richtig verstehe. Wenn personenbezogene Daten in einem CMS gespeichert sind (z. B. eine CRM-Datenbank oder die Speicherung von Kontaktdaten von Personen), dann handelt es sich um AV.
Dank im Voraus
Hallo, bitte helfen Sie, wenn ich alles richtig verstehe. Wenn personenbezogene Daten in einem CMS gespeichert sind (z. B. eine CRM-Datenbank oder die Speicherung von Kontaktdaten von Personen), dann handelt es sich um AV.
Dank im Voraus
Erst einmal vorsichtshalber die Nachfrage: Das bezieht sich doch nicht auf das Thema des Threads, oder? Dann würde ich dieses Thema abtrennen und in einen anderen Bereich verschieben.
Wenn mit AV die Auftragsverarbeitung im Rahmen der DSGVO gemeint ist, dann ist das unabhängig von Tools. Es geht einfach nur um eine Trennung von Auftragverarbeiter und Verantwortlichen. Beispiel: Eine Firma lagert die Buchführung aus. Daher gibt das Unternehmen personenbezogene Informationen an ein anderes Unternehmen, damit dieses dann z.B. Lohnabrechnungen erstellt. Und da braucht es in der Regel einen Vertrag, der dies im Detail regelt: Welche (personenbezogene) Daten werden übergeben und was wird damit alles gemacht?
Es kommt letztendlich auch immer darauf an welche Daten gespeichert werden. Wenn es sich um den Namen, die Postanschrift, Telefon oder EMail handelt dann sind dies auftragsrelevante Daten, denn man möchte ja wissen wie seine Kunden heißen und wie diese kontaktiert werden können.
Wenn du aber zusätzlich im CRM noch private Daten zu dieser Person speicherst, dann kommst du in die DSGVO Problematik. Dies können z.B. das Geburtsdatum sein, oder Hobbys, Familienstand, Kinder etc. Unsere Außendienstverkäufer hatten solche Kentnisse früher im CRM gespeichert, um sich so auf Kundenbesuche vorzubereiten und Geburtstage nicht zu vergessen. Diese Daten mussten mit der DSGVO-Einführung alle gelöscht werden.
Wenn es sich um den Namen, die Postanschrift, Telefon oder EMail handelt dann sind dies auftragsrelevante Daten, denn man möchte ja wissen wie seine Kunden heißen und wie diese kontaktiert werden können.
Wenn du aber zusätzlich im CRM noch private Daten zu dieser Person speicherst, dann kommst du in die DSGVO Problematik.
Sobald Du personenbezogene Daten verarbeitest (Speichern ist ein Beispiel für das Verarbeiten), dann ist sofort die DSGVO für Dich wichtig!
Was Du hier beschreibst, ist einfach, dass nach Art 6 Abs 1 DSGVO https://dsgvo-gesetz.de/art-6-dsgvo/ eine Bedingung von den aufgeführten Bedingungen erfüllt sein muss, damit die Verarbeitung rechtmäßig ist.
Aber es spielen natürlich noch deutlich mehr Dinge mit ein - Art 5 Abs1 c) wäre z.B. die Datenminimierung....
Also bei dem Beispiel von Dir ist hier klar zu sagen:
Die Kontaktdaten dürften erforderlich sein, um den Auftrag der betroffenen Person ausführen zu können. Ggf. auch noch rechtliche Vorgaben, denn Rechnungen sollen ja gewisse Daten beinhalten.
Das Löschen der darüber hinaus gehenden Daten ist also notwendig, da dies keine Bedingung aus Art 6 Abs 1 erfüllt und außerdem sind die zu speichernden Daten auf ein notwendiges Minimum zu reduzieren.
Wichtig ist also, dass die DSGVO Problematik immer gilt, sobald Du personenbezogene Daten in irgend einer Weise verarbeitest!
Und da habe ich jetzt auch ganz am Rande gesehen - ich hatte mich in den Links vorher zum BDSG verirrt - Auftragsverarbeiter (und damit Auftragsverarbeitung) ist in der DSGVO in Art 28: https://dsgvo-gesetz.de/art-28-dsgvo/
Bitte die DSGVO Problematik in einem anderen Thread behandeln.
Ich habe mir aber dennoch nochmal Gedanken bzgl. der Architektur gemacht.
Prinzipiell besteht meine Applikation aus zwei Bereichen:
a) Admin relevante Entities
b) Kunden relevante Entities
Gerade die Kunden relevante Entities wären durchaus wirklich sinnvoll diese in einem seperaten Schema zu haben. Somit kann jeder Kunde nur auf seine Daten zugreifen und ich laufe nicht in die Gefahr dass es dochmal durch eine falsche Query etc. vorkommt, dass man auf Daten zugreifen kann, die nicht zu diesem Kunden gehören. Auch das Ausrollen von verschiedene Versionen (verschiedene .war Files etc.) unter den Kunden wären somit möglich. Oder auch das Löschen bpw. nach Kündigung wäre sehr einfach.
Nun habe ich aber auch Entities, die nicht direkt nur zu einem Kunden gehören bzw. der Kunde auch kein Zugriff hat - ich bezeichne sie als Admintabellen.
Hierzu zählen bspw. Tabellen, die alle User enthält, Währungen, Währungskurse oder auch vordefinierte Kategorien, die der Kunde laden könnte (bspw. Terminkategorien usw.).
Auch zum Beispiel die Log - Tabelle: Diese würde ich auch gerne möglichst global einsehen wollen als Admin.
Prinzipiell könnte ich mir vorstellen:
Ich packe die ganzen Admin - Tabellen in ein eigenes Projekt
Statt den direkten Zugriff innerhalb der App, läuft der Zugriff über eine REST API
Bei den Admin Tabellen könnte ich dann auch nochmal im Detail entscheiden:
a) Halte ich die Entity nicht doch teilweise im Schema vom jeweiligen Kunden vor (bpsw. Währungen, Branchen, Logs etc.). Wenn bspw. eine neue Währung hinzukommt, müsste ich eben ein INSERT in allen Schema durchführen.
b) Welche Entities sollten tatsächlich separiert werden und in einer anderen Applikation / Schema laufen (bpsw. User) ?
Gerade wenn ich aber die Log - Tabelle mir betrachte. Als Admin hätte ich gerne direkt eine Übersicht in welcher Applikation bzw. bei welchem Kunde ein Fehler aufkam. Wenn ich die Log Tabelle nur im jeweiligen Kundenschema speichere, habe ich keine direkte Übersicht. Ich sehe hier die folgenden Optionen:
a) Log - Tabelle wird im Kundenschema gespeichert. Zusätzlich wird über eine REST API ebenfalls ein Eintrag in meiner Admin - Tabelle (anderes Schema) erstellt (Daten sind dann aber redundant)
b) Log - Tabelle wird im Kundenschema gespeichert. Per API greife ich auf sämtliche Kundenschemas zu. Ich habe keine Redundanz, der Zugriff wird aber nicht performant sein.
Generell frage ich mich natürlich auch, wie das die "Großen" wie Zendesk, Hubspot etc. machen.
Haben sie eine große Datenbank oder trennen sie dies auch bspw. per Docker je Kunde auf?
Also Logs würde ich überhaupt nicht in der DB speichern. Ich würde die DB nicht mit solchem Krempel beschäftigten. Für Logging sind die Möglichkeiten in Java stabil und ausgefeilt. Es gibt Tools die Logs automatisch überwachen, auswerten und benachrichtigen können, auch ein zentraler Log-Server wäre denkbar. Dann hat man alles an einem Ort. Mittlerweile gibt es auch KI-Modelle die automatisiert nach Auffälligkeiten suchen, usw.
Das Problem der Admin-Tabellen verstehe ich noch nicht so richtig. Man kann doch für jede Tabelle festlegen welcher DB-Nutzer was darf. Der Owner/Admin darf alles, der Nutzer unter welchem die Webanwendungen laufen dürfen dann eben manche Tabellen überhaupt nicht sehen oder nur lesen und wiederum andere auch ändern. Der "Web-DB-Nutzer" darf niemals Tabellen löschen und solche Dinge. Das ist doch ziemlich simpel.
-> Ich habe als Appbetreiber meine Kunden, was meine "Mandanten" sind.
-> Innerhalb der App gibt es auch Tabellen, auf die der Mandant nicht zugreifen soll vom Frontend, weil die von mir als Appbetreiber vorgegeben sind. Also bspw. ganz allgemeine Dinge wie "Währungen", "Währungskurse".
Die Frage ist nun hier: speichere ich diese Infos dann dennoch in jeder Instanz (Docker Instanz) ab, oder nutze ich hier eine allgemeine Datenbank?
Also Logs würde ich überhaupt nicht in der DB speichern. Ich würde die DB nicht mit solchem Krempel beschäftigten. Für Logging sind die Möglichkeiten in Java stabil und ausgefeilt. Es gibt Tools die Logs automatisch überwachen, auswerten und benachrichtigen können, auch ein zentraler Log-Server wäre denkbar. Dann hat man alles an einem Ort. Mittlerweile gibt es auch KI-Modelle die automatisiert nach Auffälligkeiten suchen, usw.
Ich denke, ein weit verbreitetes Tool ist der ELK Stack (Elasticsearch, Logstash, Kibana). Einfach mal danach suchen.
Man kann sich auch Fluentd ansehen - das wäre ein Tool, das Logs einsammelt und in diverse Zielplattformen einfügen kann. Also z.B. auch Elasticsearch.
Das wären so die Dinge, die ich empfehlen würde um sich da erst einmal etwas schlau zu machen. Generell kann man sich aber auch bei Monitoring Tools wie Overview | Prometheus und co umsehen. Da ist der Ansatz zwar erst einmal ein anderer (Halt das Monitoring von Systemen), aber dort findet sich auch das Monitoring von Anwendungen und damit oft auch die Auswertung von Logs. Das ist aber eher interessant, wenn es ein bestehendes Monitoring gibt und man sich da dann eingliedern will (Um dann direkt in den Arbeitsabläufen des Kunden drin zu sein incl. Ticket Erstellung und so ...)
Das kann ich ganz konkret beantworten: Es kommt darauf an!
Von wie vielen Kundendatenbanken reden wir denn und wie groß werden diese?
Gibt es 2 Kunden, würde ich die Datenbanken gar nicht trennen, jeder Kunde eine Schema mit unterschiedlichen Nutzern und einem Admin. Man kann die Tabellen dann READ-ONLY granten oder Views erstellen und granten. Im Schema dann einfach ein Alias mit dem gewünschten Name der Tabelle und alles ist erledigt. Die Datenpflege erfolgt zentral im Schema, welches nur der Admin bearbeiten kann.
Gibt es eine höhere mehrstellige Kundenzahl würde ich vermutlich eine Redis-Instanz verwenden, dort die Daten reinpacken und aktualisieren. Die Redis-Instanz würde dann verwendet wie einen zentralen Cache.
Man muss sich immer überlegen, jede DB die läuft, jeder Server, jede Datei, jeder Handeingriff und alles andere auch verbraucht Ressourcen und diese kosten Geld. Wenn ich Daten habe, welche ich zentral halten und Pflegen kann dann würde ich das auch nutzen.
Deshalb verwende ich übrigens auch kein Java mehr für neue Projekte. RUST -oder Go-Binaries verbrauchen einfach viel weniger Ressourcen als Java-Server, auch als nativ übersetzte. Ich benutze auch kein serverseitiges Rendering mehr, Vadin, JSF etc. Alles was im Client, z.B. als JavaScript läuft, kostet mich kein Geld. Auch Mobilgeräte haben dafür genug Leistung.
Was ich noch nicht ganz verstanden habe:
Wenn ich nun 100 Kunden habe und somit 100 Docker Instanzen.
Brauche ich dann
100x Speicherplatz für diese Installation (also bspw. 100x WildFly 200 MB, 100x .war - File....). Dass der Speicherplatz unterschiedlich ist aufgrund der Datenmenge ist klar
Brauche ich pro Installation auch entsprechenden RAM? Meine JAVAEE Anwendung nutzt heute so 4 GB (je nachdem was ich hier einstelle: -server -Xms64m -Xmx4g). Muss ich dann pro Kunde auch mind. 4 GB RAM einplanen? Oder teilen sie sich die Ressourcen etc.? Weil wenn ich einen Server mit 64 GB habe, könnten ja maximal 16 Instanzen darauf laufen (= 16 Kunden)... ?
Was ich noch nicht ganz verstanden habe:
Wenn ich nun 100 Kunden habe und somit 100 Docker Instanzen.
Brauche ich dann
100x Speicherplatz für diese Installation (also bspw. 100x WildFly 200 MB, 100x .war - File....). Dass der Speicherplatz unterschiedlich ist aufgrund der Datenmenge ist klar
Nein, das Docker Image wird nur 1x abgelegt. Bzw. Docker Images sind in Layern aufgebaut, selbst wenn du 10 verschiedene Versionen der WAR Datei heißt, brauchst du nur Platz für 1x das Basis Image (weil das bei all deinen Docker Images gleich ist) und 10x Platz für den War Layer.
[*]Brauche ich pro Installation auch entsprechenden RAM? Meine JAVAEE Anwendung nutzt heute so 4 GB (je nachdem was ich hier einstelle: -server -Xms64m -Xmx4g). Muss ich dann pro Kunde auch mind. 4 GB RAM einplanen? Oder teilen sie sich die Ressourcen etc.? Weil wenn ich einen Server mit 64 GB habe, könnten ja maximal 16 Instanzen darauf laufen (= 16 Kunden)... ?
Kommt drauf an, wie du die Java Anwendung konfigurierst. Wenn du ihr sagst "Nutz 4 GB", dann nutzt sie 4 GB und du kannst bei 64 GB auch nur 16 Instanzen laufen lassen. Da musst du halt schauen, wie viel Ram du deinen Anwendungen minimal geben willst. Unser Dockerhost in der Firma, wo bei der Entwicklung für Reviews jeweils Docker Container gestartet werden hat um die 600 GB Ram und ist regelmäßig am Limit [/list]
Wenn du 100 oder 1000 Kunden hast verdienst du ja (hoffentlich) entsprechend, dass du die Ressourcen kaufen kannst.
Hier helfen die Cloud Anbieter. Du fängst mit der kleinsten Maschine an (oder 2-3 wegen HA) und hier können z.B. 10 Kunden laufen.
Wenn deine Applikation bei Heise auftaucht und 1000 Kunden anstehen, nimmst du mehr und größere Maschinen.
On premises muss man immer einen gewissen Overhead kaufen, der dann brach liegt und kann nicht so schnell erweitern.
Wenn du 100 oder 1000 Kunden hast verdienst du ja (hoffentlich) entsprechend, dass du die Ressourcen kaufen kannst.
Hier helfen die Cloud Anbieter. Du fängst mit der kleinsten Maschine an (oder 2-3 wegen HA) und hier können z.B. 10 Kunden laufen.
Wenn deine Applikation bei Heise auftaucht und 1000 Kunden anstehen, nimmst du mehr und größere Maschinen.
On premises muss man immer einen gewissen Overhead kaufen, der dann brach liegt und kann nicht so schnell erweitern.
naja dann frage ich mich, ob das überhaupt noch wirklich rentabel ist oder habe ich einen Denkfehler? Ich habe leider auch keine Erfahrung was ich generell so an Ressourcen benötigen würde....
Nehmen wir an, ich miete mir bei einem Hoster, bpsw. Netcup einen Rootserver, der 8 GB hat für 9,81 EUR monatlich...
Wenn ich pro Docker Instanz 8 GB habe, bräuchte ich ja pro Kunde einen Rootserver - das macht ja auch kein Sinn...
Meine Idee war jetzt eig. so 100 Docker Instanzen pro VM zu haben. Also 100 Kunden pro VM...
Wieso brauchst Du da 8 GB Speicher? Nur um einmal ganz direkt zu fragen.
So Speicherverbrauch kann man ja in der Regel relativ gut durchkalkulieren. Du kannst also schauen, was Du da wirklich brauchst.
Wenn eine Datenbank kaum Daten hat, dann braucht es keine zig GB. Und was braucht so ein Service wirklich? Wie viele parallele Zugriffe erwartest Du?
Und dann die Frage nach der Kalkulation: die 10€/Monat für Hardware ist nicht einmal viel. Du willst das alles doch auch monitoren, administrieren u.s.w. Was kalkulierst Du denn da ein? Da kommen doch direkt deutlich mehr Kosten auf einen zu.
Daher möchte ich nur unterstreichen, was @Dukel da schon etwas erwähnt hat:
Und evtl. hast Du das ganz aus dem Blick verloren: Die Verfügbarkeit ist wichtig. Ein Rootserver ist doch der absolute GAU, was das angeht. Du hast einen ROOT Server und der reisst die Hufe hoch und dann? Wenn es um produktive Daten geht und Du evtl. eine gewisse Verfügbarkeit garantierst, dann willst Du auch etwas vernünftiges bauen. Das geht auch mit root Servern - Kubernetes, GlusterFS, ... Das wäre so mein Ansatz. Aber das erfordert Expertise. Ich würde mir das nicht zutrauen für eine produktive Umgebung. Selbst zuhause damit spielen ist halt doch etwas anderes.
Der Cloud Ansatz wäre also da tatsächlich sinnvoll - aber auch das ist nicht zu unterschätzen: Du musst da wirklich verstehen, was da abgeht. Das sind halt doch hoch komplexe Themen und Azure ist für mich immer ein Horrortrip - man wird einfach enorm erschlagen mit dem, was es alles gibt. Klar - das meiste braucht man nicht, aber das, was man braucht, das muss man verstehen. Auch die Abrechnung muss man verstanden haben damit eben nicht die große Überraschung kommt und der Anbieter unerwartet einen sehr hohen Betrag haben will....
Und statt ein Docker Container mit der Software zu bauen: Du kannst Software auch direkt in die Cloud bringen. Sprich: Das drumherum interessiert Dich nicht mehr: https://spring.io/guides/gs/spring-boot-for-azure
Und Datenbanken können auch direkt in der Cloud sein - das bietet mongodb z.B. auch direkt an.
Und Identity Management? Dein Keycloak musst Du auch nicht selbst betreiben - Das hat auch jede Cloud mit drin als Service...
Das nur um Dir aufzuzeigen, dass es deutlich mehr Wege für ein Deployment gibt. Und Du solltest Dich da evtl. noch deutlich besser informieren um zu erkennen, was es da so alles für Möglichkeiten gibt um dann einen Weg zu finden, der für Dich gangbar ist.
Docker mit root Server für Produktion ist da halt eher etwas, dass ich ablehnen würde ...
Wenn ich heute Knall auf Fall eine "web scale" Anwendung ausrollen müsste, würde ich das auch nicht selbst machen wollen. Wir betreiben allerdings "Enterprise Anwendungen", mit entsprechender Vorlaufzeit, Vertragsverhandlungen etc. Für die bezahlt der Kunde auch entsprechendes Geld und Hochverfügbarkeit ist da auch kein wirkliches Thema. Sonst würde ich die Anwendungen selbst schon ganz anders aufbauen.
Bei uns ist das Hosten der Anwendung einfach ein zusätzlicher Service, der dem Kunden abnimmt, was er sonst bei sich im Haus machen würde (wir haben auch Kunden, die das Hosting bei uns nicht buchen).
Für jeden Kunden gibt es somit eine fixe Anzahl an Docker-Containern auf einem Root-Server. Das Preismodell ist so gestaltet, dass es völlig egal wäre, ob jetzt 50 € im Monat pro Kunden für das Hosting draufgehen würden. So lange der Betrieb auf einem Server in Ordnung ist, werden die Ressourcen natürlich für mehrere Kunden genutzt.
Unsere Anwendungen starten mit 1,5 GB max. Heap, die reichen für die meisten. Wenn wir merken, dass der Kunde mehr braucht, wird entsprechend erhöht. Auf unseren größten Instanzen wird durchaus Last mit vielen Sessions erzeugt - und selbst dort reichen bislang 4 GB max. Heap. Bis wir bei 8 GB ankommen, ist also noch "etwas" hin - und sollte es so weit kommen, wird vermutlich vorher die Netzanbindung des Servers ein Problem.
Automatisierung der Infrastruktur ist bei uns also kein Teil der Anwendung, sondern eher mein persönliches Anliegen, um Arbeitsabläufe zu optimieren. Brauchen wir eine neue Instanz, lege ich die Subdomain an und rufe ein Skript auf, das mir die docker-compose-Files erzeugt und das Backup einrichtet. Dann starte ich die Anwendung mit docker-compose. Das geht relativ schnell, vor allem aber werden Fehler weitestgehend ausgeschlossen. Daneben habe ich einen Service, mit dem ich gezielt Instanzen aktualisieren kann. Was ich irgendwann noch angehen möchte ist die automatische Einrichtung der Subdomain. Das spart dann auch nochmal ein paar Minuten.
Wie gesagt: für web scale Anwendungen ist das nichts. Für unsere Zwecke reicht es aber allemal.
Bei uns in den internen Umgebungen bekommen Anwendungen 1 bis 2 GB, das reicht vollkommen.
Wofür braucht ein Kunde eine Anwendung die 8 GB zwingend braucht? Dann muss er halt auch entsprechend bezahlen. Ich würde sowas auch nicht auf einem Root Server machen sondern direkt in einer Cloud-Instanz - da muss man wie geschrieben halt mal durchrechnen was da kostet.
Mal noch ein paar Dinge, die da dran hängen und warum der Blick auf "der Root Server kostet X" viel zu kurz gedacht ist.
Backups: Was ist wenn der Server crashed (Platte hinüber) und die Daten weg sind? Wo sind die Backups? Wie regelmäßig gibt es die Backups? (Hier entstehen Kosten)
Restore: Wie schnell kann nach einem Crash etwas wiederhergestellt werden? Welche Resourcen sind wie schnell verfügbar?
Skalierung: Nicht jeder Kunde wird vermutlich gleichviel Resourcen brauchen? Wie skaliert man das? Wie schnell kann man reagieren, wenn auf einmal neue Kunden kommen/Kunden mehr Resourcen brauchen
Monitoring: Wie bekomme ich mit, wo was klemmt? Ich will ja proaktiv mitbekommen, wenn ein Server unter Last zusammenbrechen droht und nicht erst, weil ein Kunde wütend anruft/Mail schreibt. Wo läuft das Monitoring? Wer schaut da wie drauf? Wie gibt es Benachrichtigungen?
Wartung/Upgrade: Wie gehe ich mit Upgrades um? Sowohl von der Anwendung, als auch von den darunterliegenden Maschinen? Verschiebe ich die ggf. auf einen anderen Server?
Logging - wie erfolgt Fehleranalyse? Zentrales Logging? Wo? Wer schaut da wie rein?
Verfügungbarkeit: Welche SLA will man anbieten? Wie stellt man die sicher?
Da ist es mit "ich miete einen Rootserver, installiere Docker und packe da X Container drauf" lange nicht getan, wenn man es professionell machen will.
Fluch & Segen sind die großen Cloud Anbieter (azure & aws) - die bieten für alles skalierbare Lösungen und man bezahlt "nur" was man nutzt. Was sich aber schnell aus vielen Einzelpositionen zusammensetzt. Die auch schnell teuer werden können. Da kommt dann das Problem des Controlling ins Spiel - wie behalte ich den Überblick.
Deswegen ist Software as a Service auch nicht billig. JIRA mit 50 Usern? 400 Dollar im Monat (Da ist ein Server für 9 Euro im Monat geradezu lächerlich)
naja dann frage ich mich, ob das überhaupt noch wirklich rentabel ist oder habe ich einen Denkfehler? Ich habe leider auch keine Erfahrung was ich generell so an Ressourcen benötigen würde....
Nehmen wir an, ich miete mir bei einem Hoster, bpsw. Netcup einen Rootserver, der 8 GB hat für 9,81 EUR monatlich...
Wenn ich pro Docker Instanz 8 GB habe, bräuchte ich ja pro Kunde einen Rootserver - das macht ja auch kein Sinn...
Meine Idee war jetzt eig. so 100 Docker Instanzen pro VM zu haben. Also 100 Kunden pro VM...
Wer mietet denn Rootserver für Docker-Container? Man geht zu Azure, AWS, ... oder zu einem regionalem Anbieter mit einer Kubernetes-Instanz und lässt das dort hosten.
Falls SaaS-Startups keine erforderlichen Ressourcen haben und nicht in der Lage sind, alle anfallenden Kosten zu übernehmen (erfahrungsgemäß sind SaaS-Projekte fast immer mit hohen Kosten verbunden), sind sie gezwungen, nach Investoren zu suchen und Fundraising-Kampagnen zu starten. Das ist ein komplexer Prozess, der viel Zeit und Anstrengungen erfordert. Sein Hauptziel besteht darin, alle für die Umsetzung des Projektes notwendigen Ressourcen zu beschaffen.
In diesem Beitrag wird erklärt, welche Schritte und Herausforderungen ein SaaS-Startup bei der Gründung beachten sollte.
www.startplatz.de
Die Seed-Phase gilt gemeinhin als die erste offizielle Phase der Eigenkapitalfinanzierung, in der Software- und SaaS-Unternehmen zwischen 100.000 und 2 Millionen US-Dollar aufbringen müssen.
Für ein erfolgreiches SaaS-Startup braucht es eine großartige Idee und die richtige Finanzierung. Hier ist unser Leitfaden zur Startup-Finanzierung.
blog.payproglobal.com
Ich kann diese Zahlen jetzt mangels Erfahrung nicht einordnen - aber wenn man wirklich SaaS (und nichts anderes ist das anbieten von Software Anwendung in Containerform) machen will, wird man auf jeden Fall ordentlich investieren müssen. Unternehmen, die SaaS nutzen, erhoffen sich dadurch Einspareffekte, weil sie:
Keine Hardware betreiben müssen
Keinen Support betreiben müssen
Sich um Backups nicht kümmern müssen
Aber das heißt, das die ganzen Dinge wer anders macht - den kostet es natürlich. Der SaaS Anbieter hat Synergieeffekte, weil er x-mal das gleiche macht. Aber trotzdem hat er die Kosten, die er natürlich den Kunden in Rechnung stellen muss.
Wer mietet denn Rootserver für Docker-Container? Man geht zu Azure, AWS, ... oder zu einem regionalem Anbieter mit einer Kubernetes-Instanz und lässt das dort hosten.
Ich bin bei AWS nicht wirklich tief drin, aber du musst immer schauen, was Du genau brauchst. Im Rahmen des Erzeugens der Instanz musst Du auswählen, wie viele vcpu und Hauptspeicher Du haben willst. Der genannte Preis ist halt der kleinste Container.
Und dann musst Du schauen:
Speicherplatz - Du brauchst ja irgendwo Platz für Daten und so. Da musst Du schauen, was du da brauchst und was es kosten wird.
Traffic - AWS berechnet ausgehenden Traffic meine ich. Da kann es also auch zu weiteren Kosten kommen.
Ich bin bei AWS nicht wirklich tief drin, aber du musst immer schauen, was Du genau brauchst. Im Rahmen des Erzeugens der Instanz musst Du auswählen, wie viele vcpu und Hauptspeicher Du haben willst. Der genannte Preis ist halt der kleinste Container.
Du musst dich da einfach durcharbeiten, wie jeder andere auch. Wenn dich hier jemand anleiten soll und du willst damit Geld verdienen, dann wäre das nicht nur unfair, sondern im Fehlerfall würde es auch noch mit Schuldzuweisungen und Beschimpfungen ablaufen. Wenn es einfach wäre, dann würde es jeder machen und es ließe sich damit auch kein Geld verdienen.
Auf der von mir gewerblich genutzten K8s-Umgebung werden CPU-Kosten in 1/1000 Schritten berechnet. Würde meine Anwendung einen ganzen Monat konstant 1 CPU nutzen, dann würde das einen mittleren 3-stelligen Betrag pro Monat kosten. Wobei eine CPU nicht so wörtlich zu nehmen ist. Man kann auch 20 CPU's gleichzeitig nutzen, wenn so viele Reserven da sind. Die Verteilung der Reserven erfolgt fair an alle aber man erhält mindestens was man bucht. Also 1 CPU kann sich auch aus der gleichzeitigen Nutzung mehrere CPU's zusammensetzen. Für Ram werden nur ein paar € berechnet, ich glaube 8 pro GB/Monat - wenn ich mich richtig entsinne. Wir verwenden 16GB+ RAM pro Instanz, da Cache billiger ist als CPU/Netz/DB/Zeit. Festplattenplatz ist auch billig, da wird aber auch nicht viel benötigt. Insgesamt wird aber noch für jeden Service-Request eine Gebühr erhoben. Also wenn man RAM oder so etwas dazu bucht.
Skalierung erfolgt nach Tageszeit, also an Werktagen zur Arbeitszeit laufen 3 Instanzen permanent, sonst nur eine. Bei Bedarf wird skaliert bis max. 10 Instanzen. Das kann man selbst einstellen - aber jede Änderung (aber nicht Skalierung) ist ein Service-Request. Wo die Instanzen laufen, das regelt die K8s-Umgebung automatisch. Es ist aber immer die gebuchte Anzahl erreichbar, selbst wenn gerade der Node gewechselt wird. Das muss man bei der Programmierung beachten, z.B.: Session-Handling.
Noch was zu deinen Mandanten-Anwendungen: eine unserer Anwendungen hat etwa 3650 Mandanten mit ca. 35000 möglichen Nutzern mit Login. Tagsüber gibt es immer(auch nachts oder Feiertage) mehr als 1000 gleichzeitig angemeldete Nutzer mit Spitzenzeiten. Die Anwendung läuft aber nur gegen eine Oracle-DB (Cluster). Es ist für mich ziemlich unverständlich, wozu man für jeden Kunden eine Anwendung + DB braucht. Wie sollen das Google oder Facebook machen? x Mrd. DB's + Server für Mrd. Nutzer? Natürlich gibt es weiter DB's und Anwendungen an welche Daten weitergeleitet werden oder von welchen Daten reinkommen. Da die Anwendung auch personenbezogene Daten verarbeitet, wird sie regelmäßig von einem unabhängigem Datenschutzbeauftragten kontrolliert. Anfangs musste da auch einiges verändert werden. Es war aber nie ein Diskussionspunkt, das für jeden Mandanten eine separate DB benötigt wird.
Schaue es dir mal an. Und nein, du zahlst da nicht pro Container. Du musst dir im Detail alles ansehen. Jeder der einzelnen Services, die du verwendest hat eigene Abrechnungsmodalitäten. Die musst du dir in Ruhe ansehen und durchschauen. Das ist höchst individuell. Einfach mal ausprobieren - zum ausprobieren kostet das relativ wenig, manche Dinge haben sogar ein Freikontingent.
Noch was zu deinen Mandanten-Anwendungen: eine unserer Anwendungen hat etwa 3650 Mandanten mit ca. 35000 möglichen Nutzern mit Login. Tagsüber gibt es immer(auch nachts oder Feiertage) mehr als 1000 gleichzeitig angemeldete Nutzer mit Spitzenzeiten. Die Anwendung läuft aber nur gegen eine Oracle-DB (Cluster). Es ist für mich ziemlich unverständlich, wozu man für jeden Kunden eine Anwendung + DB braucht. Wie sollen das Google oder Facebook machen? x Mrd. DB's + Server für Mrd. Nutzer? Natürlich gibt es weiter DB's und Anwendungen an welche Daten weitergeleitet werden oder von welchen Daten reinkommen. Da die Anwendung auch personenbezogene Daten verarbeitet, wird sie regelmäßig von einem unabhängigem Datenschutzbeauftragten kontrolliert. Anfangs musste da auch einiges verändert werden. Es war aber nie ein Diskussionspunkt, das für jeden Mandanten eine separate DB benötigt wird.
d.h. du würdest eher ein eigenes Schema pro Mandant haben, anstatt eine Datenbank pro Mandant?
Ich bin darauf gekommen, weil das eine andere SaaS Company macht, die >1000 Kunden haben:
Jede Installation hat seine eigene Datenbank seine eigene Dienste, eigenes Dateisystem etc.
Ich würde dir empfehlen, dir mal einige Zeit (vermutlich mehr als 1-2 Wochen) dich mal in AWS, Orchestrierung von Containern etc. einzulesen und auszuprobieren. Und insbesondere in diesem Stadium die Frage "Wie teuer ist das" erstmal komplett auszublenden. Du brauchst erst mal ein Verständnis was es an Möglichkeiten gibt. Und dann kannst du dir - wenn du einen Werkzeugkasten hast, überlegen wann du welche Werkzeuge nutzt und wie teuer die dann sind. Denn Skalierung über AWS alles automatisiert ist toll - aber eben auch teuer. Du hast bisher nur Ideen, aber noch keine Kunden. Sobald du einen Businessplan aufstellst, kannst du dir auch überlegen, wie viel willst du am Anfang investieren. Willst du direkt mit ein voll skalierbaren Lösung starten? Oder erstmal klassisch alles in eine DB mit einen Anwendung? Oder irgendwas dazwischen
Ich würde dir empfehlen, dir mal einige Zeit (vermutlich mehr als 1-2 Wochen) dich mal in AWS, Orchestrierung von Containern etc. einzulesen und auszuprobieren. Und insbesondere in diesem Stadium die Frage "Wie teuer ist das" erstmal komplett auszublenden. Du brauchst erst mal ein Verständnis was es an Möglichkeiten gibt. Und dann kannst du dir - wenn du einen Werkzeugkasten hast, überlegen wann du welche Werkzeuge nutzt und wie teuer die dann sind. Denn Skalierung über AWS alles automatisiert ist toll - aber eben auch teuer. Du hast bisher nur Ideen, aber noch keine Kunden. Sobald du einen Businessplan aufstellst, kannst du dir auch überlegen, wie viel willst du am Anfang investieren. Willst du direkt mit ein voll skalierbaren Lösung starten? Oder erstmal klassisch alles in eine DB mit einen Anwendung? Oder irgendwas dazwischen
gebe ich dir Recht...
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.
Prinzipiell ist die Applikation schon mandantenfähig aufgebaut und ich könnte das schon irgendwie später wieder in einzelne Schemas schreiben. Aber mir fehlt hier in der Praxis jegliche Erfahrung für solche SaaS - Anwendungen.
Schaue ich mir zB "weclapp" an: scheint mir es ebenfalls, dass die auch eine Dockerinstallation ausliefern inkl. Datenbank.
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.
