Multi-Tenancy – Samenwonen in één Applicatie

Multi-Tenancy, wat is het en waarom zou je het ook maar willen begrijpen?

Samen met jou zoeken naar een nieuwe weg, waarbij de klassieke ‘WordPress oplossingen’ aangevuld kunnen worden met nieuwe diensten, en mogelijk -als jij een creatieve denker bent- zoekend naar oplossingen hierin, die jij zou kunnen bieden aan andere ondernemers, wil ik in deze blogpost van vandaag dieper ingaan op een misschien wat lastig te begrijpen, maar wel een heel belangrijk concept in de ontwikkeling van SaaS applicaties.

Multi-Tenancy

Multi-Tenancy is een concept dat steeds populairder wordt in de wereld van webapplicaties en SaaS-platformen. Het stelt meerdere gebruikers(groepen) – oftewel “tenants” (‘huurders’, ‘bewoners’) – in staat om dezelfde software te gebruiken, zonder dat ze elkaars gegevens kunnen inzien of beïnvloeden.

Het is de basis voor SaaS applicaties. Dat zijn immers applicaties waar de klant -de tenant- software aangeboden krijgt, die geheel voor hem onderhouden wordt, en waarbij hij zijn eigen ‘plaatsje’ heeft in de software.

In mijn blogpost van vandaag wil ik een aantal zaken bespreken.

• Allereerst natuurlijk wat sowieso een ‘Multi-Tenant’ applicatie is. Want zonder de term te begrijpen praten we eigenlijk over niets.
• Ten tweede, waarom je mogelijk multi-tenancy oplossingen zou willen gebruiken… en je er overigens ook bewust van te maken welke multi-tenant oplossingen je al gebruikt.
• Ten derde -je bent ondernemer of niet- hoe jij een nieuwe, of aanvullende business kan ontwikkelen door multi-tenant oplossingen aan andere ondernemers of consumenten aan te bieden.
• En last, but not least, wil ik een aantal technische oplossingen de revue laten passeren.

Wat is Multi-Tenancy?

Een tenant is een ‘bewoner’. Tenminste in het moderne Engels. Wat dat betreft is ‘tenant’ best een grappig woord, want oorspronkelijk stamt het woord af van het Latijnse woord ‘tenere’, wat ‘(be)houden’ betekent. ‘Tenet quod bene’ – Behoud het goede. Of wat minder positief: Auribus lupum tenere – De wolf bij de oren (vast)houden (jezelf in een lastig parket bevinden.

In de Middeleeuwen was een ‘tenant’ iemand die land verbouwde wat het eigendom van anderen was. En vandaag de dag is het -tenminste in het Engelse taalgebied- iemand die een huis bewoont, wat niet het zijne of hare is.

Wanneer we het in software over ‘tenancy’ hebben, dan hebben we het over gebruikers die gebruik kunnen maken van algemeen gedeelde software, die ze niet zelf in hun bezit hebben, maar waar ze wel gebruik van kunnen maken, alsof het van hen zou zijn.

Een voorbeeld wat je misschien aan zal spreken is een online maildienst als GMail of Outlook. Je hebt een volwaardig mailprogramma tot je beschikking alsof het helemaal het jouwe is. Jij weet waarschijnlijk heel goed, dat Google GMail niet speciaal voor jou heeft geïnstalleerd toen je een account aanmaakte. De software was er al, en jij deelt jouw software met miljoenen anderen. Maar omdat Google op de één of andere manier een oplossing heeft gevonden, dat anderen niet bij jouw data kunnen, is het net alsof jij jouw eigen GMail programma draait in de browser.

En misschien heb je ooit, voordat je met een zelf-gehoste WordPress website begon ook ooit eens een blog op een website gehad op WordPress.com. Ook dan lijkt het net alsof je jouw eigen WordPress website hebt, terwijl je eigenlijk de software deelt met een heleboel andere mensen.

En dat is precies het idee van Multi-Tenancy. Je krijgt de beschikking over ‘eigen’ software, zonder dat je hier veel kopzorgen aan hebt.

Enkele vormen van Multi-Tenancy toepassingen

Als ondernemer gebruik je -al dan niet bewust- waarschijnlijk al een aantal Multi-Tenancy toepassingen. Laat me je een aantal voorbeelden geven

• Online mail clients. Wanneer je een mail client gebruikt hoeft dat niet persé een Multi-Tenancy toepassing te zijn. Je kan bijvoorbeeld ‘Roundcube’ gebruiken, dat is een online mail-client die je moet verbinden met de services van je eigen mail service. Maar andere toepassingen, zoals bijvoorbeeld GMail, Outlook en de online mail van jouw hostingprovider zijn goede voorbeelden van multi tenancy applicaties.
• e-Mail marketing diensten. Met een enkele uitzondering zoals bijvoorbeeld MailPoet zijn vrijwel alle markering mailing diensten, zoals MailChimp, ActiveCampaign en de honderden andere vergelijkbare diensten ook ‘Multi-Tenant’ oplossingen.
• Multi-Vendor webshops. Multi-vendor shops als Bol.com en Amazon.nl zijn goede voorbeelden van Multi-Vendor shops. De winkels bieden niet alleen hun eigen producten aan, maar geven andere winkeliers (vendors) de kans hun producten via een centrale shop te verkopen, waarbij je een eigen ‘kraam’ op hun markt hebt. Er zijn ook verschillende plugins (zie ook mijn artikel over WooCommerce in het groot) waarmee je van WooCommerce een winkel maakt, waar verschillende handelaren hun goederen aan kunnen bieden.
• Online Leerplatformen. Een goed voorbeeld is Udemy als platform waar iemand eigen cursussen aan kan bieden, zonder een eigen website te hoeven hebben. Maar ook met een plugin als MasterStudy LMS kan jij een eigen ‘Multi-Tenant’ omgeving opzetten, waarop jij niet alleen je eigen cursussen aan kan bieden, maar anderen ook de gelegenheid kan geven zich op jouw cursussite te profileren… en te verdienen.

Functionele verschillen tussen verschillende Multi-Tenant toepassingen.

Behalve de voorbeelden hierboven zijn er nog tientallen voorbeelden te bedenken. Maar ik heb met opzet deze voorbeelden genoemd, omdat de eerste twee iets gemeenschappelijk hebben. De laatste twee ook.

Met betrekking tot de eerste twee, het zijn allebei toepassingen, waarbij je jouw eigen geïsoleerde omgeving hebt. Jij, als eigenaar van je Gmail account bent de enige die bij je mail kan -tenzij je natuurlijk je wachtwoord deelt. En wanneer je een account bij MailChimp of ActiveCampaign hebt, dan kan jij wel mensen toevoegen aan jouw account en hun rechten bepalen, maar niemand kan zonder toestemming bij jouw nieuwsbrieven en mailinglijsten kiezen.

Beide toepassingen zijn ‘geïsoleerd’, er is niets ‘buiten jouw account om.

Met een Multi-vendor webshop, of een leerplatform als Udemy of MasterStudy LMS zit het anders. Jij hebt je eigen ‘winkeltje’ of ‘klaslokaal’, waar je zelf 100% controle over hebt, maar het doel van de site ligt buiten jouw specifieke ‘hoekje’ op de site. Want het eigenlijke doel van jouw account is juist om op een groter platform jouw producten of cursussen aan te kunnen bieden.

In de eerste twee gevallen zal je waarschijnlijk nooit ontdekken wie de andere ‘tenants’ op het platform zijn. In de laatste twee gevallen wel.

Waarom zou je Multi-Tenancy apps willen gebruiken?

Als ondernemer moet je een balans weten te vinden over de zaken waar je 100% controle over wilt hebben, en die zaken die je -gedeeltelijk- graag aan anderen over wilt laten. Jouw website bijvoorbeeld is je meest belangrijke marketing middel in deze dagen. Je wilt absoluut niet beperkt zijn door de mogelijkheden die de site-builder applicatie van een willekeurige hosting provider je biedt. Jouw site is je visitekaartje en je wilt absoluut niet in een wurggreep gehouden worden, omdat je je site niet bij een andere partij kan hosten. Daarom zijn open source oplossingen als WordPress, Drupal of andere CMS-en ook zo populair.

Andere zaken wil je je niet al te veel mee belasten. Het goed opzetten van je eigen email marketing kost heel wat hoofdbrekens en vereist heel wat werk voor een functionaliteit die je ook in kan kopen. Voor je webmail eigenlijk hetzelfde verhaal.

Als zelfstandige ondernemer gebruik je waarschijnlijk bewust of onbewust al minimaal een tiental online diensten die op de één of andere manier een multi-tenant SaaS oplossing zijn.

Welke mogelijkheden zie je zelf om een SaaS / Multi-Tenant dienst aan te bieden?

Veel ondernemers en ontwikkelaars realiseren niet hoeveel kansen Multi-Tenancy biedt voor nieuwe zakelijke modellen. Heb je een idee voor een webapplicatie die meerdere klanten tegelijk kan bedienen? Dan zou je kunnen overwegen een SaaS dienst te (laten) ontwikkelen.

Wees hierbij wel realistisch. Probeer geen platgetreden paden te volgen. Wanneer we over multi-vendor e-commerce oplossingen praten, dan hebben we in Nederland al Bol.com en Amazon. Wanneer je ‘iets’ wilt met een multi-vendor oplossing, dan zal je met een eigen ‘multi-vendor’ oplossing niet echt de concurrentie met die partijen aankunnen.

Wat wel een kanshebbende situatie zou zijn, is wanneer je rond een bepaalde niche een multi-vendor oplossing neer zou zetten. Ken jij een markt, die slecht vertegenwoordigd is in het Nederlands taalgebied? Wat let je om een multi-vendor e-commerce platform op te zetten rond een bepaalde niche?

Hetzelfde geldt voor een cursus platform. Probeer de concurrentie niet met Udemy of andere grote platforms aan te gaan, maar biedt cursusontwikkelaars een niche platform aan, wat beter en makkelijker gevonden wordt, dan de paar cursussen in jouw niche die er beschikbaar zijn op die grote, algemene platforms.

Maar misschien heb je ook andere ideeën. Heb jij nooit gedacht ‘wat jammer, dat er nog geen app is op het internet die dit of dat doet? Wat let je om zelf zo’n platform te laten ontwikkelen. En met de moderne ontwikkelhulpmiddelen zouden de kosten van zo’n platform best enorm mee kunnen vallen. Je kan natuurlijk altijd een vrijblijvende offerte opvragen.

Maar wanneer je over dit soort zaken nadenkt, is het goed om eens verder te lezen. Want in het volgende deel van dit artikel ga ik verder in op een aantal belangrijke ontwerpbeslissingen die je moet nemen, wanneer je een Multi-Tenant dienst overweegt aan te bieden.

Starten met je eigen Multi-Tenancy oplossing

Hoe groot is je publiek / doelgroep

Wanneer je zelf met Multi-Tenancy zou willen beginnen, is -denk ik- de eerste belangrijke vraag die je jezelf moet stellen, hoe groot je jouw toekomstige publiek verwacht.

Om een voorbeeld te geven, ik heb recent de mogelijkheid besproken voor administratiekantoren en virtual assistants om Invoice Ninja te gebruiken voor de facturatie-, tijd en financiële administratie voor andere bedrijven. Omdat Invoice Ninja een administratie per bedrijf heeft, is in zekere zin Invoice Ninja ook een multi-tenancy applicatie. Maar wanneer je dit gebruikt voor je klanten, dan is het ook een aanvulling op je bestaande dienstverlening, en is het onwaarschijnlijk dat je meer tenants zal krijgen dan je eigen klanten.

Overweeg je een compleet nieuwe dienst aan te bieden, waar wel vraag naar is, maar wat nog niet aangeboden wordt, dan is de mogelijke groei moeilijk in te schatten. Wat in zo’n geval belangrijk is, dat je kiest voor een groeimodel, waar je klein begint, maar wat wel ‘door kan groeien’ naar een groot publiek.

Wie is je tenant?

Ofwel, wie is de klant, waarvoor je de applicatie maakt. Op welk niveau in het bedrijfsleven zit deze, of richt je je op de consument?

Bij een app voor het delen van (verjaardags) verlanglijstjes is je tenant overduidelijk het individu, wat graag verlanglijstjes deelt met familie, vrienden en compleet onbekenden die hem of haar graag iets cadeau doen. Bied je een compleet online ERP (Enterprise Resource Planning) aan, dan is jouw publiek over het algemeen een onderneming met 100 of meer medewerkers. Beide oplossingen vragen om een andere benadering, zowel op het gebied van app ontwikkeling als op het gebied van marketing.

En wat vooral ook belangrijk is: Ken jij jouw beoogde tenant en de beoeften daarvan?

Zijn er standaard oplossingen voor de dienstverlening die je aan wilt bieden?

Zijn er standaard oplossingen voor de dienstverlening die je aan wilt bieden? Als dat het geval is, dan kan je ervan uitgaan, dat het een lastig te betreden markt is. Zijn er al plugins (WordPress) of packages (Laravel onder andere) beschikbaar voor de oplossing, dan is de enige manier waarop je je kunt onderscheiden door voor een specifieke niche benadering te kiezen (zie hierboven ook wat ik schreef over e-commerce en online trainingen) of wel een heel andere en originele benadering van het probleem wat je app op moet lossen te hebben.

Wat is het ‘minimaal pakket van diensten’ wat je aan wilt bieden?

Zelfs met de moderne middelen is software ontwikkeling een kostbare zaak. Tenzij je er 100% zeker van bent, dat jouw idee het nieuwe ei van Columbus is, is het daarom goed je scope te beperken tot de kern van het probleem. Mocht je product aanslaan, dan kan je je dienstverlening uitbreiden en nieuwe ‘premium’ niveaus van dienstverlening aanbieden.

Zelfs wanneer je een gigantisch systeem in gedachten hebt, begin eerst met een subset van je wensen, om te kijken of daar markt voor is. Hoe complexer ehet systeem, hoe moeilijker het vaak te verkopen is.

De technische uitdaging

Voor de technische uitvoering van een multi-tenant systeem is er een drietal wegen die gevolgd kan worden. Wat belangrijk is om te realiseren, dat het te volgen pad sterk afhankelijk is van wat je precies functioneel wenst.

1. Eén database, de regels in de tabellen worden gescheiden door een specifiek ‘id’ veld.

Dit is in technisch opzicht de minst veilige methode van het scheiden van de tenants. Helaas is het ook de enige methode, wanneer er de noodzaak bestaat dat informatie van verschillende tenants gedeeld moet worden, zoals bijvoorbeeld in een multi-vendor e-commerce platform of een multi-instructor cursus platform als MasterStudy LMS. Je wilt immers als bezoeker makkelijk door het totaal aanbod van producten of cursussen kunnen zoeken.

De manier om de verschillende tenants van elkaar te scheiden is ongeveer als volgt.

Allereerst heb je een tabel met tenants. Die ‘tenants’ zullen over het algemeen geen ‘tenant’ worden genoemd, maar naar de primaire doelgroep voor de toepassing. Bij een e-commerce zou dat bijvoorbeeld ‘shop’ kunnen zijn. De tabel ‘shops’ zou er dan ongeveer als volgt uit zien (sterk vereenvoudigd)

Daarnaast hebben we een usertabel.

Wat je hier uit kunt lezen, is dat Jan Jansen de eigenaar van twee winkels is, ‘Mijn laptop winkel’ en ‘Mijn fietsbellen winkel’. Piet Pietersen is de trotse eigenaar van de bakkerij en Joris Driepinter is de eigenaar van ‘En nog een winkel’.

Over de andere mensen weten we nog weinig. Maar laten we eens naar de volgende tabel kijken, de ‘user_to_shop’ tabel:

Omdat meerdere users verschillende rollen in verschillende shops kunnen hebben, wordt het nu al een stuk ingewikkelder.

Je zal begrijpen, dat wanneer we hier aantal tabellen bij gooien, het steeds complexer gaat worden. En een foutje bij het opvragen van gegevens is snel gemaakt. Het is dus verstandig deze oplossing uitsluitend te gebruiken, wanneer het echt niet anders kan. En wat dat ‘echt niet anders’ is, dat heb ik iets eerder al besproken.

2. ‘Eén database, gescheiden tabellen’

Deze oplossing is al beter dan de eerdere oplossing. Een goed voorbeeld van een implementatie die voor deze aanpak heeft gekozen is WordPress Multi Site. Bij WordPress MultiSite heeft iedere tenant een eigen ‘set’ tabellen, die door verschillende prefixes uit elkaar worden gehouden.

De eerste persoon die een site aanmaakt (en dat is per definitie degene die het installeert) krijgt een tabellenset die begint met de standaard prefix (default ‘wp_’, maar dat kan je aanpassen), plus het volgnummer 1. Iedere volgende site die wordt aangemaakt krijgt een oplopend volgnummer.

Dus website 1 krijgt tabellenset met onder andere :

• wp_1_posts
• wp_1_options
• wp_1_users

En de tweede website krijgt

• wp_2_posts
• wp_2_options
• wp_2_users

en nummer drie, je raadt het al:

• wp_3_posts
• wp_3_options
• wp_3_users

Omdat de structuur wp_[nummer]_ als prefix wordt gezien, en WordPress prima in staat is afzonderlijke tabellen aan de hand van prefixes te ondersteunen, is dit al een stuk beter dan de eerste oplossing. Het enige nadeel wat deze oplossing heeft is dat er geen ‘laag’ is die informatie samen zou kunnen voegen.

Wanneer ik bijvoorbeeld een multi-vendor shop op deze manier zou willen implementeren, zou er over alle tabellen heen naar producten gezocht moeten worden. Dat is wel mogelijk, maar hoogst inefficiënt.

Een tweede groot nadeel is, dat het moeilijk schaalbaar is. Deze structuur werkt alleen als alle tabellen in dezelfde database zitten. Wordt je multi-vendor shop een groot succes, dan is dit moeilijk te schalen.

Iedere tenant een eigen database

De derde manier is door één software base te hebben, maar met meerdere databases. Naast die meerdere databases heb je ook nog een extra database nodig, waar wordt bijgehouden, welke tenant waar ‘woont’.

Door via een specifieke URL op de site te komen, ‘weet’ de applicatie op welke database je in moet loggen.

Die ‘verwijstabel’ zou er bijvoorbeeld als volgt uit kunnen zien:

In deze tabel staan dus de namen van de tenants (of een numerieke ID), de URL die ze gebruiken om in te loggen (wat een subdomein van de applicatie kan zijn, zoals bij tenant1 en tenant3, of een eigen domeinnaam (als bij tenant2), of een subdomein op een eigen domeinnaam (zoals bij tenant4.

Daarnaast heeft iedere tenant een ‘eigen’ database en worden de bestanden die gebruikt worden opgeslagen in aparte buckets van AWS-S3. Deze oplossing van alle drie de oplossingen de veiligste en de meest schaalbare. Er kleeft echter wel één nadeel aan, omdat je op shared hosting accounts meestal niet vanuit de programmatuur zelf databases aan mag maken, en iedere tenant een eigen database moet hebben, is deze oplossing eigenlijk alleen maar mogelijk op een VPS, in de cloud of een dedicated machine.

Samenvattend

Steeds meer van ons leven speelt zich online af, en als ondernemer kun je daar niet omheen. De vraag naar slimme softwareoplossingen groeit, maar niet elke ondernemer zit te wachten op het beheer ervan. Dit biedt kansen voor creatieve ondernemers die problemen kunnen vertalen naar innovatieve Multi-Tenant SaaS-oplossingen. Heb jij een idee voor een SaaS-platform en wil je sparren over de mogelijkheden? Neem dan gerust contact op met WordXPression – we denken graag met je mee!

Dit blogartikel beantwoord onder meer de volgende vragen

• Wat is multi-tenancy en waarom is het belangrijk voor SaaS-applicaties?
• Welke voordelen biedt het implementeren van een multi-tenant architectuur?
• Hoe verhoudt multi-tenancy zich tot bestaande WordPress-functionaliteiten zoals Multisite?
• Welke technische oplossingen en frameworks zijn geschikt voor het ontwikkelen van multi-tenant applicaties?
• Hoe kunnen ondernemers multi-tenant oplossingen inzetten om nieuwe diensten aan te bieden?