Definitie: Multi-tenant is een softwarearchitectuur waarin één installatie van een applicatie meerdere klanten bedient, die elk hun eigen afgeschermde gegevens en instellingen hebben. Elke klant, de tenant, werkt in dezelfde software, maar ziet alleen zijn eigen omgeving.
In het kort
- Bij multi-tenancy delen klanten de applicatie, de servers en vaak de database, terwijl hun gegevens logisch gescheiden blijven.
- Het tegenovergestelde is single-tenant: elke klant krijgt een eigen installatie, met meer controle maar hogere kosten en meer beheer.
- Bekende multi-tenant toepassingen zijn SaaS-pakketten zoals Salesforce, HubSpot en Slack.
- De belangrijkste ontwerpkeuze is hoe je de gegevens scheidt: in één gedeelde database, met een schema per klant of met een database per klant.
Wat is multi-tenant software?
Een tenant is letterlijk een huurder. Denk aan een appartementencomplex: alle bewoners delen het gebouw, de leidingen en de lift, maar ieder heeft een eigen voordeur en sleutel. Multi-tenant software werkt hetzelfde. Er draait één applicatie, en meerdere organisaties gebruiken die tegelijk, elk met hun eigen gebruikers, gegevens en instellingen.
Een tenant is meestal een klantorganisatie, niet een individuele gebruiker. Een boekhoudpakket met duizend aangesloten bedrijven heeft dus duizend tenants, met binnen elke tenant weer meerdere medewerkers. De software moet bij elke actie weten bij welke tenant iemand hoort en mag nooit gegevens van een andere tenant tonen.
Het idee is niet nieuw. Volgens TechTarget gaat het terug tot de tijd van mainframes, toen meerdere gebruikers één dure computer deelden. Met virtualisatie en de cloud kreeg het een nieuwe betekenis: vrijwel alle grote cloud- en SaaS-diensten draaien nu op een vorm van multi-tenancy.
Multi-tenant en SaaS: hoe hangen ze samen?
SaaS is een manier van aanbieden: je gebruikt software via de browser tegen een abonnement. Multi-tenancy is de techniek die dat betaalbaar maakt. IBM noemt Salesforce en HubSpot als voorbeelden van SaaS die op multi-tenancy is gebouwd. Slack is een ander herkenbaar voorbeeld: elk bedrijf krijgt een eigen werkruimte, terwijl alle werkruimtes op hetzelfde platform draaien.
Voor de aanbieder is het voordeel groot. Een update of beveiligingspatch voer je één keer door, voor alle klanten tegelijk.
Multi-tenant of single-tenant?
| Multi-tenant | Single-tenant | |
|---|---|---|
| Installatie | Eén gedeelde applicatie voor alle klanten | Eigen installatie per klant |
| Kosten per klant | Laag, omdat servers en beheer gedeeld worden | Hoger, omdat alles per klant draait |
| Updates | Eén keer voor iedereen | Per klant, soms op eigen tempo |
| Aanpassingen | Via instellingen binnen de grenzen van het product | Meer ruimte voor klantspecifieke aanpassingen |
| Isolatie | Logisch, afhankelijk van een goed ontwerp | Fysiek of volledig gescheiden |
| Geschikt voor | SaaS-producten, portalen met veel klanten | Klanten met strenge eisen aan beveiliging of regelgeving |
TechTarget noemt beveiliging en regelgeving als de meest voorkomende redenen om voor single-tenant te kiezen.
Hoe scheid je de gegevens van tenants?
De kern van multi-tenancy zit in de database. Er zijn drie gangbare modellen:
- Eén gedeelde database met een gedeeld schema. Alle klanten staan in dezelfde tabellen, en elke rij heeft een kolom die aangeeft bij welke tenant hij hoort. Dit is het goedkoopst en schaalt het makkelijkst, maar elke query moet die kolom meenemen. Een vergeten filter kan gegevens van een andere klant zichtbaar maken.
- Eén database met een schema per tenant. Elke klant krijgt eigen tabellen binnen dezelfde database. IBM noemt PostgreSQL met een schema per tenant als middenweg tussen isolatie en schaalbaarheid.
- Een aparte database per tenant. De applicatie is gedeeld, maar elke klant heeft een eigen database. Dat geeft de sterkste scheiding en maakt het makkelijker om de gegevens van één klant te exporteren, te herstellen of te verwijderen. Het beheer wordt wel zwaarder naarmate het aantal klanten groeit.
Waar let je op bij een multi-tenant applicatie?
- Isolatie in elke laag. Niet alleen de database, ook bestanden, zoekfuncties, caches, exports en achtergrondtaken moeten weten bij welke tenant iets hoort.
- Rollen en rechten binnen de tenant. Een beheerder bij klant A mag alles binnen A, maar niets bij klant B. Rechten werken dus op twee niveaus.
- Noisy neighbours. Volgens TechTarget kan één tenant die zwaar gebruikmaakt van de applicatie de prestaties voor anderen verlagen. Limieten per tenant, wachtrijen en goede monitoring helpen daartegen.
- Configuratie per klant. Eigen logo, eigen velden, eigen e-mailteksten of een eigen domein. Maak vooraf duidelijk wat instelbaar is, zodat je geen aparte versies per klant gaat onderhouden.
- Testen met meerdere tenants. Test structureel of een gebruiker van de ene klant nooit iets van een andere klant kan zien, ook niet via een directe link of een API.
Veelgemaakte fouten
- Multi-tenancy pas later toevoegen. Een applicatie die voor één klant is gebouwd, achteraf geschikt maken voor meerdere klanten, raakt bijna elke tabel en elk scherm. Het is eenvoudiger om het vanaf de eerste versie mee te nemen.
- Te vroeg te complex bouwen. Een database per tenant met eigen servers is zelden nodig voor de eerste tien klanten.
- Klantspecifieke code. Wie per klant uitzonderingen in de code bouwt, verliest het voordeel van één gedeelde applicatie.
Wat betekent dit voor jouw project?
Bij een nieuw idee onderzoek ik eerst of een bestaand pakket, een koppeling of maatwerk het beste past. Wil je zelf software aanbieden aan meerdere klanten, dan is multi-tenancy vaak een van de eerste architectuurkeuzes. Ik wil vooraf duidelijk hebben wat we met een eerste versie bedoelen: één organisatie die het gebruikt, of meerdere klanten die elk hun eigen omgeving krijgen. Dat verschil bepaalt hoe de database, de rechten en het beheer worden opgezet.
Daarbij stel ik dezelfde vraag als bij elk systeem: wie gaat het gebruiken en welke taak moet die persoon als eerste kunnen afronden? Bij een multi-tenant product komt daar een vraag bij: wat moet per klant anders kunnen, en wat is voor iedereen gelijk?
Vraag? Wil je een applicatie bouwen die meerdere klanten elk in hun eigen omgeving gebruiken? Stuur me voor wie het is, wat er nu gebeurt en wat de eerste versie moet oplossen. Dan bepalen we samen de logische eerste stap. Lees ook hoe ik een webapplicatie laat ontwikkelen.
Veelgestelde vragen over multi-tenant
Wat betekent multi-tenant?
Multi-tenant betekent dat één installatie van een applicatie meerdere klanten bedient, die elk hun eigen afgeschermde gegevens en instellingen hebben. Het woord tenant betekent huurder: klanten delen de software zoals bewoners een gebouw delen.
Wat is het verschil tussen multi-tenant en single-tenant?
Bij multi-tenant delen klanten één applicatie en vaak één database, met logisch gescheiden gegevens. Bij single-tenant krijgt elke klant een eigen installatie, wat meer controle en isolatie geeft, maar hogere kosten en meer beheer met zich meebrengt.
Is multi-tenancy in SaaS veilig?
Multi-tenancy kan veilig zijn als de scheiding tussen tenants in elke laag goed is ontworpen en getest, van database tot bestanden en API. Het grootste risico is een fout in de code waardoor gegevens van een andere klant zichtbaar worden.
Verwante termen
SaaS · Rollen en rechten · Database · Schaalbaarheid · Verwerkersovereenkomst · Software-architectuur
← Terug naar de kennisbank