Multi tenancy

Maak een Begin. Het is Gratis
of registreren met je e-mailadres
Multi tenancy Door Mind Map: Multi tenancy

1. Data scheiding

1.1. Hybride (eigen connectiestring)

1.1.1. Verwijzing naar aparte of gedeelde DB

1.1.2. Aparte DB hanteert ook TenantId-veld

1.2. Aparte DB

1.2.1. Kan eigen DB-server krijgen ivm schaalbaarheid, load, geen overlast van andere klanten

1.2.2. Makkelijk backup/restore per klant

1.2.3. Kans minimaal dat gegevens van verkeerde klant geraadpleegd worden (datalek)

1.2.4. DB-migratie kan per tenant

1.2.5. Datastore voor tenant-specifiek maatwerk

1.2.6. Eigen datacenter mogelijk (wetgeving, bv in EU)

1.3. TenantId veld

1.3.1. Eenvoudig database beheer (slechts 1 DB)

1.3.2. DB-migratie is big-bang

1.3.3. Queries over alles tenants heen mogelijk (niet voor tenants zelf!)

1.3.4. Foutgevoelig (where-clause vergeten = datalek!)

1.4. Logging

2. Tenant selectie

2.1. Via identiteit/inlog

2.1.1. Let op: inlogscherm is generiek

2.1.1.1. Geen huisstijl

2.1.1.2. (Geen custom IdP)

2.2. Via url (ns.twygger.io)

2.2.1. of url param (?tenantid=1)

3. Customization

3.1. REST-device endpoints

3.2. SMS-telefoonnr

3.2.1. Status/antwoord callbacks

3.3. Maatwerk

3.3.1. Read/write filters

3.3.2. Vantevoren bepalen waar wel/niet kan

3.3.3. Keuze: niet toestaan (NS blijft enige uitzondering)

3.4. UI (logo, kleuren)

3.5. Wel/niet MM

3.6. Categories

3.7. Feature-toggles

3.7.1. Uitschakelen niet afgenomen functionaliteit

3.7.2. Inschakelen van nieuwe (beta) functionaliteit

3.8. Welke config doet tenant zelf?

3.9. Localization? (UI, docs, etc)

4. Deployment

4.1. Gedeeld

4.1.1. n (latest)

4.1.2. n-1 (previous, upgrade asap)

4.1.3. n+1 (early adopters)

4.1.4. OTA

4.1.5. Self-service

4.1.5.1. Try-before-buy

4.1.5.2. Online docs

4.1.5.3. Ticket systeem

4.2. Private (managed)

4.2.1. Deployment-last hoog

4.2.2. Downtime minder erg (handig voor deployments, config, db-migratie, etc)

5. Integratie

5.1. Public Api

5.1.1. Api-key vs tenant-specifieke IdP

5.2. Aanroep api's van tenant

5.2.1. Signalering van wijzigingen (P-status/A-boek)

5.2.2. REST-devices

5.2.3. Let op bij beinvloeding van SLA door aanroep tenant-specifieke API;s

5.2.4. Authenticatie?

5.2.4.1. IP-restricties?

5.3. Maatwerk voor tenant

5.3.1. Vb: HPCOM-adapter

6. Authenticatie

6.1. Standaard/gedeelde IdP (Auth0)

6.1.1. TenantId wordt claim

6.2. Eigen IdP

6.2.1. ADFS

6.2.2. Azure AD

6.2.3. Tenant kan zelf users beheren

6.3. Autorisatie

6.3.1. Standaard rollen

6.3.2. Eigen rollen (mapping)

6.3.2.1. Ondersteunt berichtenportaal al

6.4. Twygger UI heeft nog geen authenticatie!

7. Beheer

7.1. SLA

7.1.1. Meten per tenant

7.2. Load management

7.2.1. Caps op load

7.3. Backup/restore strategie

7.4. Logging

8. Business models

8.1. Pay per use (msg, req, user)

8.2. Minimum fee/mo

8.3. Freemium

8.3.1. Could create lock-in

8.4. First x msgs free

9. Technical Challenges

9.1. LUA

9.2. Callback URLs

9.3. User login vs api login/key

9.4. Categories editable

9.5. SMS telnr