Results 1 to 10 of 10

Thread: Je applicatie multi-tenant geschikt maken

Hybrid View

  1. #1

    Je applicatie multi-tenant geschikt maken

    hi

    Hebben jullie al ervaringen met het multi-tenant geschikt maken van je applicatie
    en database omgeving. Waarbij je de applicatie en database als SAAS beschikbaar maakt.

    Of is het 1 applicatie met per klant een eigen database omgeving?

    Er zijn veel dingen waar je rekening mee moet houden maar bestaat er ergens
    een 'richtlijn/schema' waar je precies rekening mee moet houden

  2. #2
    Of is het 1 applicatie met per klant een eigen database omgeving?
    Dat is wel hoe ik het begrijp.

    Volgens mij is het een kwestie van bepalen welke gebruiker naar welke database moet, maar misschien zie ik het te simpel

  3. #3
    haha...dat zou wel het makkelijkste zijn. Dit zou dan ook betekenen dat wanneer je
    een database wijziging door moet voeren je dit voor iedere klant/per database moet doen.

  4. #4
    mov rax,marcov; push rax marcov's Avatar
    Join Date
    Apr 2004
    Location
    Ehv, Nl
    Posts
    10,357
    Elk nadeel is een voordeel. Je kan ook klanten selectief migreren (omdat het actieve accounts zijn die nieuwe features willen), en de rest waar het vuur wel een beetje uit is op het oude laten.

  5. #5
    haha...dat zou wel het makkelijkste zijn.
    Volgens mij heb ik het verkeerd begrepen Volgens Wiki staat alles inderdaad in één database. Er zal wel een goede reden voor zijn, maar ik vind het niet zo vanzelfsprekend. Bij de alles in één database oplossing zie ik de volgende nadelen:

    1) Je kunt een nieuwe versie niet in fases releasen.

    2) Het lijkt mij, met de (beperkte) kennis die ik heb, lastig schaalbaar. Bij meerdere databases/applicatie servers kun je makkelijk meerdere servers inzetten en loadbalancing toepassen. Bij alles in één database moet je volgens mij gewoon steeds groter naarmate het aantal gebruikers.

    3) Het lijkt me ook lastiger om het veilig te houden omdat je in iedere query de rechten moet meenemen.

    4) Het is waarschijnlijk veel complexer/duurder om te bouwen.


    Misschien dat ik me nog even goed moet inlezen in de materie (ik heb zelf een soort gelijk probleem), maar mijn conclusie was om in iedere geval een aparte database te gebruiken en misschien zelfs wel een aparte applicatie server (zodat ook memory cpu e.d. eerlijk verdeeld worden).

    Kwam de link tegen met een white paper van Oracle Multitenant Misschien dat je er wat inspiratie kunt uithalen.

  6. #6
    Ik zou er in ieder geval voor kiezen om de databases van de klanten gescheiden te houden. Daarmee verklein je het risico dat data van de ene klant naar de andere lekt, en je kan ze ook afzonderlijk hosten en eventueel schalen, zodat een klant die z'n applicatie zwaar gebruikt niet de performance van een andere klant onderuit haalt, en je per klant aan kan bieden of ze het sneller willen hebben tegen extra centen.

    Als je software zwaar afhankelijk is van de versie van de database (en het is de vraag of dat zo zou moeten zijn), dan betekent dat haast ook dat je een afzonderlijke software-omgeving moet hebben per klant. Volgens mij is dat uiteindelijk wel zo praktisch, want het stelt je in staat om specifieke maatwerk-aanpassingen te maken per klant, of in overleg met de klant het handigste tijdstip te kiezen voor zo'n update.

    Maar zelfs SAAS betekent niet dat alles op één database draait. Een simpele web hosting is ook al een vorm van SAAS, en als jij je klant een gehost pakket aanbiedt, dan kan je achter de schermen nog steeds per klant een omgeving hebben ingericht, aldanniet op gescheiden servers, die al dan niet virtual zijn, en waarvan je een deel van het werk zelfs weer kan uitbesteden aan Azure of AWS.
    1+1=b

  7. #7
    de meeste SAAS oplossingen zullen een gedeelde database hebben, mogelijk wel opgedeeld in shards.

    Zelf zou ik ook kiezen voor een database per klant, maar dat heeft meer te maken met het soort toepassingen, waarbij je zakelijke klant data niet gemixed wilt hebben.

    Een mix kan uiteraard ook. Ik heb een app gehad waarbij een deel van de info in een algemene database stond die benaderbaar was via een API. De klantspecifieke data stond in een eigen database en werd ontsloten via een eigen API op een app server.

    kbmMW heeft ook mogelijkheden om dat makkelijk te doen, je kunt een applicatie server laten connecten naar een eigen klanten database (via de connection pool). De server instance kan zo meerdere klanten tegelijk afhandelen, die allemaal hun eigen database benaderen.

  8. #8
    Ok..dank voor de input. Uitgangspunt wordt dan :
    - 1 applicatie voor alle klanten
    - per klant een aparte database omgeving ivm scheiding

    Binnen de applicatie is het mogelijk om gebruikers te definiëren en
    rechten toe te kennen tot schermen en wel of niet mogen muteren, verwijderen enz.
    Voor iedere klant gebeurd dat dan in zijn eigen database omgeving. Dat is opzich
    geen probleem.

    Maar omdat iedereen bij dezelfde url uitkomt moet men daar dus inloggen
    om te bepalen of het klant A is die naar database_A gaat en klant B naar database_B
    Vervolgens kom je in je eigen omgeving waar je dan jouw specifieke rechten hebt.

    Je wilt niet 2 keer inloggen, aan de voordeur bij de url en aan de achterdeur
    binnen je eigen omgeving.

    Wat zou hier in wijs zijn om op te zetten. Deze link zou een hulpmiddel kunne zijn
    voor een user database model :
    https://www.getdonedone.com/building...r-application/

    Greetz Peter

  9. #9
    Is het niet mogelijk om een subdomein per klant aan te maken?

  10. #10
    Wat ik in mijn applicatie (een w32 client) deed was inloggen op een centrale server die voor alle klanten gelijk is. Die deed na de credential check een check op de client versie en deed eventueel een push van een nieuwe client versie. Als de versie op orde was ontving de client een object met de info hoe en waarheen te verbinden. Inloggen op de specifieke database per klant ging dan automatisch. Authorisaties e.d. waren verder allemaal klantspecifiek geregeld in die database.

    Ik begreep dat jij UniGui wilde gaan gebruiken voor je web front end. Daar heb je een main module die voor elke sessie wordt aangemaakt. Daar kun je volgens mij zoiets wel organiseren, of je nu kbmMW als backend gaat gebruiken of een directe database connectie.

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •