Multi-tenancy zonder jargon uitgelegd: een gids voor oprichters

Op enig moment tijdens het bouwen van een softwareproduct zal een ontwikkelaar het woord "multi-tenant" laten vallen, naar uw gezicht kijken en aannemen dat u het begreep. U knikte waarschijnlijk. De meeste oprichters doen dat. Maar dit is een van die vroege beslissingen die in stilte het plafond bepalen voor hoe snel u kunt groeien, hoe goedkoop u kunt draaien en hoe erg het mis kan gaan als een klant ooit data ziet die niet van hem is. Het is tien minuten van uw aandacht waard, want het is erg duur om er later op terug te komen.

Ik heb tegenover heel wat niet-technische oprichters gezeten — mensen met een scherp idee voor een SaaS-product en geen bijzondere interesse in databases. Het goede nieuws is dat u niet hoeft te leren programmeren om deze beslissing goed te nemen. U hebt een helder mentaal model en een korte lijst met vragen nodig. Dat is wat deze gids is. Geen modewoorden, geen architectuurdiagrammen die u nooit meer bekijkt, alleen datgene wat uw ontwikkelaar wenste dat u begreep vóór de eerste regel code.

Als u één idee meeneemt, laat het dan dit zijn: multi-tenancy is geen functie die u later toevoegt. Het is een fundering. U kunt een huis opnieuw schilderen, maar u kunt niet zomaar veranderen waar het op staat zodra de muren overeind staan.

Wat "multi-tenant" werkelijk betekent

Stel u een appartementengebouw voor. Elke bewoner heeft zijn eigen woning — eigen sleutel, eigen meubels, eigen voordeur. Maar ze delen allemaal dezelfde structuur: de fundering, de leidingen, het dak, de lift. De verhuurder onderhoudt één gebouw, geen vijftig losse huizen, en dat is wat de huur betaalbaar maakt. Multi-tenant-software werkt precies zo. Eén applicatie bedient veel klanten — "tenants" — en elk van hen ervaart het als zijn eigen privéruimte, ook al draaien ze allemaal op hetzelfde gedeelde systeem eronder.

De tegenovergestelde aanpak is single-tenant: elke klant krijgt zijn eigen aparte kopie van de software, alsof u voor elke klant een gloednieuw vrijstaand huis bouwt. Privéer, beter aanpasbaar — en dramatisch duurder om te bouwen, te draaien en bij te werken, want nu onderhoudt u vijftig huizen in plaats van één gebouw.

Vrijwel elk product dat u dagelijks gebruikt, is multi-tenant. Uw e-mail, uw boekhoudtool, uw boekingssysteem, het CRM waarin uw verkoopteam leeft. U en duizend andere bedrijven delen dezelfde onderliggende software, en geen van u ziet de ander ooit. Die onzichtbaarheid — die zuivere scheiding — is de hele kunst van multi-tenancy.

Waarom deze beslissing uw hele bedrijf raakt

Het is verleidelijk om dit weg te zetten als "technisch detail dat mijn ontwikkelaar regelt." Maar het model dat u kiest, werkt rechtstreeks door in de delen van het bedrijf waar u wél om geeft: uw maandelijkse hostingrekening, hoe snel u een nieuwe functie aan iedereen kunt uitrollen, wat u een nerveuze enterprise-koper kunt beloven, en hoeveel schade één bug kan aanrichten.

Wanneer u een bug verhelpt of een functie uitbrengt in een goed gebouwd multi-tenant-product, krijgt elke klant het tegelijk, via één enkele update. In een single-tenant-wereld zou u die wijziging uitrollen naar vijftig losse installaties, die inmiddels elk net iets anders zouden kunnen zijn. Het ene is een dinsdagmiddag. Het andere is een project. Vermenigvuldig dat over jaren van updates en u ziet waarom de SaaS-industrie draait op multi-tenancy.

De keerzijde is dat het delen van infrastructuur de inzet op scheiding verhoogt. In een appartementengebouw kan een leidingstoring meer dan één woning treffen. In multi-tenant-software bezorgt een fout in hoe u tenants gescheiden houdt niet alleen één klant ongemak — het kan ieders data tegelijk blootstellen. Dit is geen reden om multi-tenancy te vermijden. Het is de reden om het goed te bouwen, met iemand die het eerder heeft gedaan.

De drie manieren om tenants gescheiden te houden

Wanneer ontwikkelaars over multi-tenancy ruziën, gaat het meestal over hoe gescheiden de data van elke tenant moet zijn. Er zijn drie veelvoorkomende benaderingen, en ze liggen op een glijdende schaal van "maximaal delen, laagste kosten" tot "maximale scheiding, hoogste kosten." U hoeft er zelf geen te kiezen — maar u moet de afweging begrijpen die uw ontwikkelaar namens u maakt.

1. Gedeelde database, gedeelde tabellen

Iedereens data staat in dezelfde database, in dezelfde tabellen, met een verborgen label — een "tenant-ID" — dat aangeeft welke rijen bij wie horen. De software is verantwoordelijk om altijd op dat label te filteren, zodat klant A alleen ooit de rijen van klant A ziet. Dit is het goedkoopste en best schaalbare model, dat de meeste vroege SaaS-producten gebruiken. De adder onder het gras: de scheiding zit in de code, dus één gemiste filter is hoe data lekt. Het vraagt om zorgvuldig, gedisciplineerd werk.

2. Gedeelde database, aparte compartimenten

Eén database, maar elke tenant krijgt zijn eigen afgeschermde sectie erin (ontwikkelaars noemen dit "schema's"). Sterkere scheiding dan het eerste model, nog steeds redelijk efficiënt, en eenvoudiger om bijvoorbeeld de data van één klant netjes te exporteren of te verwijderen. De afweging: meer bewegende delen om te beheren naarmate u groeit naar honderden en duizenden tenants.

3. Een aparte database per tenant

Elke klant krijgt zijn eigen toegewijde database — het dichtst bij het geven van een privéhuis terwijl u toch de applicatie deelt. Dit is de sterkste isolatie en het makkelijkste verhaal om aan een veiligheidsbewuste enterprise-koper te vertellen. Het is ook het duurst om te draaien en te beheren, dus het wordt meestal gereserveerd voor klanten met hoge waarde, gereguleerde sectoren, of producten waar een dataverwisseling catastrofaal zou zijn.

Het deel dat u niet mag verprutsen: isolatie

Als er één plek is om uw zorgen aan te besteden, is het hier. Tenant-isolatie is de garantie dat klant A nooit, onder geen enkele omstandigheid, de data van klant B kan zien, bewerken of zelfs maar het bestaan ervan kan vermoeden. Het klinkt vanzelfsprekend. Het is ook de meest voorkomende bron van ernstige bugs in multi-tenant-producten, want het falen verloopt in stilte — alles ziet er prima uit tot de dag dat iemand een rapport opent en daarin de klanten van een vreemde ziet.

De reden dat dit gebeurt, is structureel. In het goedkoopste model moet elke afzonderlijke databasevraag eraan denken op tenant te filteren. Doe het tienduizend keer goed en één keer fout, en u hebt een lek. Daarom vertrouwen ervaren teams niet op het geheugen van ontwikkelaars — ze bouwen de isolatie in de fundering, zodat vergeten onmogelijk wordt in plaats van slechts onwaarschijnlijk. U hoeft niet te begrijpen hoe ze dat doen. U moet vragen óf ze het doen.

Er is ook een stillere neef van dit probleem: de "lawaaierige buur." Omdat tenants infrastructuur delen, kan één klant die iets zwaars doet — een gigantische import, een op hol geslagen rapport — het systeem voor iedereen vertragen, net zoals één woning waar alle kranen openstaan de waterdruk in het hele gebouw kan laten dalen. Goed multi-tenant-ontwerp houdt hier rekening mee met limieten en eerlijke verdeling. Het is de moeite waard ernaar te vragen, zeker als u een paar zeer grote klanten verwacht.

Wanneer single-tenant juist de juiste keuze is

Multi-tenancy is de standaard voor SaaS, maar het is geen geloof. Er zijn eerlijke redenen om een klant zijn eigen aparte kopie te geven, en een goede adviseur vertelt u wanneer u er een hebt bereikt in plaats van alles in het gedeelde model te dwingen.

• Een klant in een gereguleerde sector — zorg, financiën, overheid — wiens compliance-regels feitelijk eisen dat zijn data aantoonbaar gescheiden ergens staat.
• Eén grote klant die genoeg betaalt dat een toegewijde opzet de moeite waard is, en die diepe maatwerk wil die u niet wilt laten doorsijpelen in de ervaring van iedereen.
• Data die zo gevoelig is dat de kosten van een cross-tenant-lek het einde van het bedrijf zouden betekenen, waardoor maximale isolatie de extra uitgave waard is.
• Een on-premise-eis, waarbij de software binnen de eigen muren van de klant moet draaien in plaats van in uw cloud.

Let op het patroon: single-tenant is de uitzondering die u bewust kiest, meestal voor een specifieke klant met hoge waarde, niet de standaard waarop u het hele bedrijf bouwt. Als een ontwikkelaar vanaf dag één single-tenant voorstelt voor uw standaardproduct, vraag hem dan u uit te leggen waarom — meestal betekent het veel hogere draaikosten en tragere updates, en dat wilt u dat een keuze is, geen ongeluk.

De vragen die u moet stellen voordat iemand code schrijft

U hoeft de architectuur niet te ontwerpen. U moet ervoor zorgen dat degene die dat wel doet, over de juiste dingen heeft nagedacht. Hier is de korte lijst die ik een niet-technische oprichter zou willen meegeven aan dat eerste gesprek — print hem, stel hem, en let op hoe zelfverzekerd hij wordt beantwoord.

1. 1
   Hoe gaat u de data van tenants gescheiden houden?

   U luistert naar een structureel antwoord — het systeem dwingt het af — niet "we zullen voorzichtig zijn." Dit is de onderhandelbare niet.
2. 2
   Welk model gebruiken we, en waarom?

   Gedeelde tabellen, aparte compartimenten, of database-per-tenant. Er is geen fout antwoord, maar er moet een reden zijn die past bij uw klanten en budget.
3. 3
   Kunnen we een grote klant later toegewijde isolatie bieden?

   Zelfs als u volledig gedeeld begint, moet het ontwerp ruimte laten om één grote of gereguleerde klant sterkere scheiding te geven zonder herbouw.
4. 4
   Wat gebeurt er als één klant enorm wordt?

   Hoe voorkomt het systeem dat één zware tenant iedereen vertraagt? U wilt horen dat lawaaierige-buur-scenario's zijn overwogen.
5. 5
   Hoe exporteren of verwijderen we netjes de data van één klant?

   Klanten vertrekken, en de privacywet vereist dat u hun data op verzoek verwijdert. Dit moet een eenvoudige, goed begrepen handeling zijn, geen paniek.

U beoordeelt niet het technische detail van de antwoorden. U controleert of geen van deze vragen als een verrassing aankomt. Een team dat eerder multi-tenant-software heeft gebouwd, heeft op alle vijf scherpe, bijna verveelde antwoorden. Aarzeling bij de eerste of derde is het signaal om gas terug te nemen en door te vragen.

Een kort, levensecht voorbeeld

Een oprichter kwam bij ons met een werkend prototype voor een planningstool gericht op kleine klinieken. Het had al drie betalende klanten — en een stil probleem. Om snel op de markt te komen, had de eerste ontwikkelaar elke kliniek zijn eigen aparte kopie van de app gegeven. Drie klanten, drie installaties, drie net iets verschillende versies, omdat elk onderweg om een kleine aanpassing had gevraagd.

Bij drie werkte het prachtig. De nachtmerrie van de oprichter was de gedachte aan dertig. Elke bugfix betekende inloggen op drie plekken. Elke nieuwe functie betekende drie uitrollen en drie dingen om te testen. Een nieuwe kliniek kostte het grootste deel van een week om handmatig op te zetten. Het model dat hen naar de lancering bracht, was nu datgene wat hun groei beperkte — precies het funderingsprobleem waar dit hele artikel over gaat.

We hebben niet alles in een dramatische herschrijving eruit gesloopt. We bouwden de kern opnieuw op een gedeelde multi-tenant-fundering met isolatie afgedwongen op systeemniveau, behielden de maatwerkaanpassingen per kliniek als instelbare opties in plaats van aparte codebases, en migreerden de drie bestaande klinieken één voor één, parallel, zodat niemand een enge overstapdag had. Het onboarden van een nieuwe kliniek ging van een week handwerk naar een selfservice-aanmelding. Nieuwe functies bereiken nu elke klant via één enkele release.

De cijfers hier zijn illustratief, geen belofte — elk product is anders — maar de vorm is typisch: de herbouw kostte echt geld en een paar maanden, en betaalde zichzelf terug binnen de eerste handvol nieuwe klanten die ze ineens zonder een vinger uit te steken konden onboarden. De les die de oprichter meenam, was de goedkopere: als ze de vijf vragen aan het begin hadden gesteld, was er niets te herbouwen geweest.

Veelgestelde vragen