Een diepgaande duik in het begrip "multi-tenancy" en het delen van onze inzichten over hoe wij het zien.
We horen vaak over het belang van het creëren van een multi-tenant applicatie, vooral in de context van het ontwikkelen van een Software als een Dienst (SaaS) applicatie.
Er is enige verwarring over het concept van een "multi-tenant app" en de verschillende modellen die worden gebruikt om er een te ontwikkelen. In dit artikel hebben we deze termen van dichterbij bekeken op een meer praktische manier.
Single-tenant architectuur is een software- of cloud computingmodel waarbij elke klant of huurder een aparte instantie van een applicatie of dienst heeft. Als we kijken naar de oorsprong van het B2B-businessmodel, begint het met elke instantie van de software die slechts één klant of organisatie bedient.
Single-tenant architectuur wordt vaak gebruikt in scenario's waar naleving van groot belang is of waar aangepaste beveiligingseisen nodig zijn. Bijvoorbeeld in sectoren zoals financiën, gezondheidszorg en overheid, die strikte regelgevingsvereisten hebben, geven vaak de voorkeur aan single-tenant oplossingen om naleving te waarborgen.
Echter, het is belangrijk om op te merken dat single-tenant architecturen meer middelen kunnen verbruiken en complexer te beheren zijn in vergelijking met multi-tenant architecturen, omdat elke instantie van de klant zijn eigen infrastructuur en onderhoud vereist. Daardoor zijn ze mogelijk meer geschikt voor applicaties met minder maar grotere klanten of waar aanpassing en isolatie van cruciaal belang zijn.
Software multi-tenancy is een software architectuur waarin een enkele instantie van software draait op een server en meerdere huurders bedient. Systemen die op deze manier zijn ontworpen, zijn "gedeeld" (in plaats van "toegewijd" of "geisoleerd"). Een huurder is een groep gebruikers die gemeenschappelijke toegang delen met specifieke privileges tot de software-instantie. Met een multi-tenant architectuur is een softwareapplicatie ontworpen om elke huurder te voorzien van een toegewijd aandeel in de instantie - inclusief zijn gegevens, configuratie, gebruikersbeheer, individuele functionaliteit van de huurder en non-functionele eigenschappen. -- Wikipedia
We hebben definities verstrekt vanuit een architectonisch perspectief, waardoor het eenvoudig is om onderscheid te maken tussen multi-tenant en single-tenant ontwerpen. Dit leunt echter meer naar de technische definitie. Als we deze definities gebruiken in onze echte ontwikkelomgeving bij het ontwerpen van huurmodellen, veronderstelt deze manier van denken dat een multi-tenant app een puur gedeelde multi-tenant infrastructuur moet hebben.
Echter, bedrijven en producten variëren veel en hebben veel geval-voor-geval vereisten, dus er is geen oplossing die voor iedereen hetzelfde is.
Stel je een scenario voor waarin een huurder middelen gebruikt van een gedeelde infrastructuur, maar door specifieke bedrijfsbehoeften vereist hij dat één of twee onderdelen van het systeem exclusief aan hem zijn toegewezen. Deze toegewezen onderdelen kunnen de database, instanties of een combinatie van andere componenten zijn, terwijl de algemene infrastructuur wordt gedeeld. Hier komt de gemengde-tenant architectuur om de hoek kijken.
Bij praktische SaaS productontwikkeling is het gebruikelijk om een scenario tegen te komen waarin een product voornamelijk is ontworpen met een algemeen multi-tenancy model. Echter, bepaalde aspecten van de architectuur of middelen kunnen naar een "single-tenancy" benadering neigen.
AWS gebruikte het volgende geval als voorbeeld om dit concept over te brengen: multi-tenancy is een breed begrip, en het is geval-voor-geval om de juiste strategie te combineren en te kiezen om te definiëren wat je wilt bereiken met de gedeelde middelen en gegevensisolatie.
Met andere woorden, soms noemen mensen dit model nog steeds "Multi-tenancy", dus in de bredere definitie van multi-tenancy, impliceert het niet dat elke component in een oplossing gedeeld is. Het impliceert eerder dat op zijn minst sommige componenten van een oplossing worden hergebruikt over meerdere huurders.
Als je deze term breed begrijpt, kun je beter empathie hebben met de behoeften van je klant en waar ze vandaan komen.
In plaats van je te fixeren op een enkel architecturaal model, weerspiegelt multi-tenancy de praktische toepassing van de architectuur van een SaaS-product in de echte wereld. Wanneer we verwijzen naar een multi-tenant app, betekent het niet noodzakelijk dat de app voldoet aan één architectonisch model; het kan verschillende huurstrategieën gebruiken, wat aangeeft dat minstens enkele van zijn componenten worden gedeeld.
Hier komt de vraag, hoe stel ik de huurstrategie voor mijn product voor? Hier zijn enkele belangrijke vragen om over na te denken:
Vergeet niet dat er geen rigide indeling is in je product waar je moet kiezen voor ofwel een puur multi-tenant of uitsluitend single-tenant model. Je beslissing moet gebaseerd zijn op hoe je de architecturale componenten van je product verdeelt en de specifieke isolatieniveaus die je klanten of bedrijf nodig hebben. Je kunt dan verschillende benaderingen toepassen.
We hebben het gehad over de "nieuwe" definitie van een multi-tenant app, maar hoe zit het met huurdersisolatie, identiteiten, en hoe te bepalen of je identiteiten moeten worden geïsoleerd of niet? Wat betekent het voor identiteiten om "geïsoleerd" te zijn?
De verwarring ontstaat vaak bij het omgaan met situaties waarin een echte gebruiker twee verschillende identiteiten heeft. Is het gepast om deze situatie te labelen als - "geïsoleerde identiteiten"?
We zullen deze vragen behandelen in onze aankomende serie artikelen. Blijf op de hoogte!