Huurmodellen voor een multi-tenant app

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.

Verschillende huurmodellen begrijpen vanuit een technisch oogpunt#

Single-tenant architectuur#

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.

Kenmerken#

• Isolatie: Elke klant of huurder opereert in een geïsoleerde omgeving met toegewijde middelen, databases en configuraties.
• Aanpassing: Single-tenant architecturen bieden vaak meer mogelijkheden voor aanpassing en flexibiliteit om aan specifieke klantbehoeften te voldoen.
• Veiligheid: Verbeterde veiligheid en gegevensprivacy, aangezien klantgegevens niet worden vermengd met die van andere huurders.
• Schaalbaarheid: Het opschalen van middelen en capaciteit kan eenvoudiger zijn, aangezien elke instantie van de huurder onafhankelijk kan worden aangepast.
• Onderhoud: Onafhankelijk onderhoud en updates, omdat veranderingen in de omgeving van één huurder geen invloed hebben op anderen.
• Kosten: Typisch hogere infrastructuur- en operationele kosten vanwege de noodzaak om aparte instanties voor elke huurder te onderhouden.

Voorbeelden#

• Toegewijde hosting: Traditionele webhostingproviders bieden single-tenant architecturen aan, waarbij elke klant zijn eigen middelen, databases of configuraties krijgt.
• On-premise software: Sommige bedrijfssoftwareapplicaties, zoals klantrelatiebeheer (CRM) of human resource managementsystemen (HRMS), bieden single-tenant implementatieopties voor organisaties met strenge dataveiligheid en aanpassingseisen.
• SaaS met premium tiers: In sommige Software als een Dienst (SaaS) aanbiedingen, bieden premium of bedrijfsniveaus single-tenant opties voor klanten die verbeterde beveiliging, compliance of aanpassing vereisen.

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.

Multi-tenant architectuur#

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

Kenmerken#

• Gedeelde middelen: Meerdere huurders delen dezelfde infrastructuur, inclusief servers, databases en netwerkbronnen, om middelen optimaal te benutten.
• Isolatie: Gegevens en configuraties van huurders zijn logischerwijs gescheiden, waardoor gegevensprivacy en beveiliging worden gegarandeerd.
• Schaalvoordelen: Multi-tenancy kan kosteneffectief zijn, omdat de overhead wordt verdeeld over meerdere gebruikers, waardoor operationele en infrastructuurkosten worden verlaagd.
• Schaalbaarheid: De architectuur kan horizontaal of verticaal schalen om groeiende aantallen huurders en gebruikers te accommoderen.
• Onderhoud: Updates en onderhoud zijn gestroomlijnd, omdat wijzigingen uniform van toepassing zijn op alle huurders, wat het beheer vereenvoudigt.
• Aanpassing: Hoewel enige aanpassing mogelijk is, is deze meestal meer beperkt in vergelijking met single-tenant architecturen om systeem brede consistentie te behouden.

Voorbeelden#

• Cloud-gebaseerde SaaS: De meeste Software als een Dienst (SaaS) applicaties, zoals Google Workspace en Salesforce, gebruiken multi-tenancy om meerdere organisaties of gebruikers op een gedeeld platform te bedienen.
• Gedeelde hosting: In webhosting hosten gedeelde hostingdiensten meerdere websites op dezelfde server, elk behorend tot een andere klant of organisatie.
• Openbare clouddiensten: Openbare cloudproviders, zoals AWS en Azure, gebruiken multi-tenancy om diverse klanten te bedienen met geïsoleerde gevirtualiseerde middelen binnen gedeelde datacenters.
• Bedrijfsbrede infrastructuuroplossingen: Zoals een gedeeld Kubernetes-cluster dat wordt gebruikt door meerdere bedrijfseenheden binnen een organisatie.

Multi-tenant apps opnieuw definiëren in de echte wereld#

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.

Belangrijke overwegingen om je huurmodel strategie te bepalen#

Hier komt de vraag, hoe stel ik de huurstrategie voor mijn product voor? Hier zijn enkele belangrijke vragen om over na te denken:

• Wat zijn je bedrijfsdoelen?
• Kan een single-tenant oplossing je toekomstige groeiplannen ondersteunen?
• Hoe groot is je operationele team, en hoeveel van je infrastructuurbeheer kan worden geautomatiseerd? Vind je wendbaarheid en kostenefficiëntie belangrijk?
• Zijn je klanten comfortabel met verschillende multi-tenancy opties?
• Hoe beïnvloedt elke optie compliance, zowel die van jou als die van je klanten?
• Wordt er van je verwacht dat je service level agreements (SLA's) nakomt of streeft naar specifieke service level doelstellingen (SLO's)?
• Heb je rekening gehouden met beveiliging, kosten, prestaties, betrouwbaarheid en responsiviteit voor de behoeften van individuele huurders als geheel?

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.

Volgende#

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!