Multi-tenant-architectuur: deel het platform, nooit de data
Dankzij multi-tenant-architectuur bedient hetzelfde platform meerdere klanten, de zogenaamde tenants, terwijl hun gegevens gescheiden blijven. Voor softwareleveranciers, franchisenetwerken of kantoren die software doorverkopen, drukt multi-tenant-architectuur de kosten en versnelt ze de opstart. Die voordelen vragen wel om doordacht ontwerp vanaf de eerste dag. Deze pagina zet de uitdagingen en de juiste vragen op een rij.
Wat multi-tenant-architectuur verandert
In de klassieke opzet krijgt elke klant zijn eigen installatie, met aparte updates en apart onderhoud. Met multi-tenant-architectuur delen alle klanten dezelfde code en infrastructuur. U rolt correcties dus meteen uit voor iedereen, en nieuwe functies bereiken alle klanten tegelijk. Ook beveiligingspatches bereiken zo alle omgevingen zonder vertraging. Klanten toevoegen betekent configuraties aanmaken, geen extra servers. Die schaalvoordelen spreken vooral SaaS-leveranciers en groeiende netwerken aan, die geregeld nieuwe partners toevoegen.
Dat delen mag echter nooit zichtbaar worden. Elke tenant verwacht zijn eigen logo, kleuren, startpagina en idealiter zijn eigen domein. Vergeet ook de e-mails en facturen niet: ook die dragen best de huisstijl van de tenant. Gebruikers zien alleen hun eigen gegevens, nooit die van andere klanten. Personalisatie en afscherming vormen zo de twee pijlers van geslaagde multi-tenant-architectuur. Ontbreekt daarvan iets, dan verliezen uw klanten snel hun vertrouwen. Denk daar al aan bij de eerste schetsen.
Beveiliging, AVG en vragen vooraf
Controleer technisch drie lagen: verplichte tenant-id's op alle gevoelige records, sessies die beperkt blijven tot de tenant van de gebruiker en logboeken van elke actie. Voorzie ook gegevensexport voor vertrekkende klanten, geteste back-ups en prestatiebewaking, zodat zeer actieve tenants de andere niet vertragen. Houd daarnaast per tenant bij hoeveel opslag en rekenkracht die gebruikt. Test die beveiliging ten slotte geregeld, bijvoorbeeld met demo-accounts per tenant. Leg ook vast hoe snel u een lek bij een enkele tenant kunt isoleren.
Juridisch geldt de AVG volledig. Doorgaans blijft elke klant verwerkingsverantwoordelijke voor zijn gegevens, terwijl de leverancier als verwerker optreedt. Leg die relatie vast in verwerkersovereenkomsten, want uw klanten vragen daarnaar bij hun eigen audits. Beschrijf daarin ook wie wat doet bij beveiligingsincidenten. Bepaal ten slotte hoever tenants het platform mogen aanpassen voor uw multi-tenant-architectuur moeilijk te updaten wordt, want elke uitzondering kost uiteindelijk geld.
Ons artikel over multi-tenant-architectuur en de hulp van specialisten
Ons artikel over eigen landingspagina's en branding per klant toont hoe u elke klant zijn eigen startpagina, header en huisstijl geeft. Het beschrijft de keuze tussen subpaden en eigen domeinen, de self-service-API voor branding en de drie isolatielagen van veilige multi-tenant-architectuur. Het stelt ook concrete toepassingen voor: boekhoudkantoren, consultantnetwerken en API-integratoren. U ziet er bovendien hoe tenants hun logo aanpassen zonder de leverancier te contacteren. Zo krijgt u snel een concreet beeld van de mogelijkheden.
Schakel specialisten in voor u de eerste regel code schrijft, want slecht afgeschermde data achteraf rechtzetten kost veel meer dan goed ontwerp. Espero-Soft ontwikkelt webplatformen met multi-tenant-architectuur voor softwareleveranciers, franchises en partnernetwerken in België. We vertrekken van uw bedrijfsnoden en kiezen daarna het gepaste isolatieniveau. Bestaande multi-tenant-architectuur kunnen we ook doorlichten voor u verder groeit. Zo weet u vooraf welke aanpassingen prioriteit verdienen. Ook de documentatie voor uw eigen team nemen we mee.
