Hyresmodeller för en multi-tenant-app

Vi hör ofta om vikten av att skapa en multi-tenant-applikation, särskilt i sammanhanget att utveckla en Software as a Service (SaaS) applikation.

Det finns viss förvirring kring konceptet med en "multi-tenant-app" och de olika modeller som används för att utveckla en. I den här artikeln tog vi en närmare titt på dessa termer på ett mer praktiskt sätt.

Förstå olika hyresmodeller ur ett tekniskt perspektiv#

Enhyresarkitektur#

Enhyresarkitektur är en modell för mjukvara eller molnberäkning där varje kund eller hyresgäst har en dedikerad instans av en applikation eller tjänst. Om vi tittar på ursprunget till B2B-affärsmodellen börjar det med att varje instans av mjukvaran endast betjäner en kund eller organisation.

Egenskaper#

• Isolering: Varje kund eller hyresgäst opererar i en isolerad miljö med dedikerade resurser, databaser och konfigurationer.
• Anpassning: Enhyresarkitekturer tillåter ofta större anpassning och flexibilitet för att möta specifika kundbehov.
• Säkerhet: Förbättrad säkerhet och dataintegritet, eftersom kunddata inte blandas med andra hyresgästers data.
• Skalbarhet: Att skala resurser och kapacitet kan vara enklare, eftersom varje hyresgästs instans kan justeras oberoende.
• Underhåll: Oberoende underhåll och uppdateringar, eftersom förändringar i en hyresgästs miljö inte påverkar andra.
• Kostnad: Typiskt högre infrastruktur- och driftkostnader på grund av behovet av att upprätthålla separata instanser för varje hyresgäst.

Exempel#

• Dedikerad hosting: Traditionella webbhosting-leverantörer erbjuder enhyresarkitekturer, där varje klient får sina egna resurser, databaser eller konfigurationer.
• On-premises mjukvara: Vissa företagsmjukvaror, såsom kundhanteringssystem (CRM) eller system för humankapitalhantering (HRMS), erbjuder enhyresdistribution alternativ för organisationer med strikta datasäkerhets- och anpassningsbehov.
• SaaS med premiumnivåer: I vissa Software as a Service (SaaS) erbjudanden, tillhandahåller premium- eller företagsnivåer enhyresalternativ för kunder som kräver förbättrad säkerhet, efterlevnad eller anpassning.

Enhyresarkitektur används vanligtvis i scenarier där efterlevnad är av största vikt eller kräver skräddarsydda säkerhetskrav. Till exempel, industrier som finans, sjukvård och regering, som har strikta regulatoriska krav, föredrar ofta enhyreslösningar för att säkerställa efterlevnad.

Det är dock viktigt att notera att enhyresarkitekturer kan vara mer resurskrävande och komplexa att hantera jämfört med multi-hyresarkitekturer, eftersom varje kunds instans kräver sin egen infrastruktur och underhåll. Som ett resultat kan de vara mer lämpliga för applikationer med färre men större kunder eller där anpassning och isolering är kritiska.

Multi-hyresarkitektur#

Mjukvarumulti-tenancy är en mjukvaruarkitektur där en enda instans av mjukvara körs på en server och betjänar flera hyresgäster. System designade på detta sätt är "delade" (snarare än "dedikerade" eller "isolerade"). En hyresgäst är en grupp användare som delar gemensam åtkomst med specifika privilegier till mjukvaruinstansen. Med en multi-hyresarkitektur är en mjukvaruapplikation designad för att ge varje hyresgäst en dedikerad andel av instansen - inklusive dess data, konfiguration, användarhantering, hyresgästs egen funktionalitet, och icke-funktionella egenskaper. -- Wikipedia

Egenskaper#

• Delade resurser: Flera hyresgäster delar samma infrastruktur, inklusive servrar, databaser, och nätverksresurser, för att optimera resursutnyttjandet.
• Isolering: Hyresgästers data och konfigurationer är logiskt åtskilda, för att säkerställa dataintegritet och säkerhet.
• Stordriftsfördelar: Multi-tenant-miljö kan vara kostnadseffektivt eftersom overhead fördelas mellan flera användare, vilket minskar drifts- och infrastrukturkostnader.
• Skalbarhet: Arkitekturen kan skalas horisontellt eller vertikalt för att rymma ett växande antal hyresgäster och användare.
• Underhåll: Uppdateringar och underhåll är förenklade, eftersom ändringar tillämpas enhetligt för alla hyresgäster, vilket förenklar hanteringen.
• Anpassning: Medan viss anpassning är möjlig, är den vanligtvis mer begränsad jämfört med enhyresarkitekturer för att bibehålla systemomfattande konsistens.

Exempel#

• Molnbaserad SaaS: De flesta Software as a Service (SaaS) applikationer, såsom Google Workspace och Salesforce, använder multi-hyresarkitektur för att betjäna flera organisationer eller användare på en delad plattform.
• Delad hosting: Inom webhosting, värdtjänster agerar som värd för flera webbplatser på samma server, var och en tillhör en annan kund eller organisation.
• Offentliga molntjänster: Offentliga molnleverantörer, såsom AWS och Azure, använder multi-hyresarkitektur för att betjäna olika klienter med isolerade virtualiserade resurser inom delade datacenter.
• Enterprise-infrastruktur-lösningar: Såsom en delad Kubernetes-kluster som används av flera affärsenheter inom en organisation.

Omdefiniera multi-tenant-appar i verkligheten#

Vi har gett definitioner ur ett arkitektoniskt perspektiv, vilket gör det lätt att särskilja mellan multi-tenant och enhyres-design. Detta lutar emellertid mer mot den tekniska definitionen. Om vi använder dessa definitioner i vår verkliga utvecklingsmiljö när vi designar hyresmodeller, antar detta synsätt att en multi-tenant-app måste ha en rent delad, multi-tenancy-infrastruktur.

Men affärsverksamhet och produkter varierar mycket och har många fall-specifika krav, så det finns ingen universallösning.

Föreställ dig ett scenario där en hyresgäst använder resurser från en delad infrastruktur, men på grund av specifika affärsbehov kräver de att en eller två delar av systemet är exklusivt dedikerade till dem. Dessa dedikerade delar kan vara databasen, instanser eller en kombination av andra komponenter, samtidigt som de delar den övergripande infrastrukturen. Det är här mixade hyresmodeller kommer in i bilden.

I praktiska SaaS-produktutvecklingar är det vanligt att möta ett scenario där en produkt främst är designad med en generisk multi-tenant-modell. Men vissa aspekter av arkitekturen eller resurserna kan tendera mot en "enhyres"-ansats.

AWS använde följande fall som ett exempel för att kommunicera detta koncept: multi-tenancy är ett brett koncept, och det är fall-för-fall att kombinera och välja rätt strategi för att definiera vad du vill åstadkomma med delade resurser och dataseparation.

Med andra ord, ibland kallar människor fortfarande denna modell "Multi-tenancy", så den bredare definitionen av multi-tenancy innebär inte att varje komponent i en lösning är delad. Snarare innebär det att åtminstone några komponenter av en lösning återanvänds mellan flera hyresgäster.

Att förstå denna term brett kan bättre hjälpa dig att förstå dina kunders behov och deras utgångspunkt.

Snarare än att fixera sig på en enda arkitektonisk modell, speglar multi-tenancy praktiken hos en SaaS-produkts arkitektur i verkligheten. När vi hänvisar till en multi-tenant-app, betyder det inte nödvändigtvis att appen adhererar till en arkitektonisk modell; den kan använda sig av olika hyresstrategier, vilket indikerar att åtminstone några av dess komponenter är delade.

Viktiga överväganden för att bestämma din hyresmodellstrategi#

Här kommer frågan, hur föreslår jag hyresstrategin för min produkt? Här är några viktiga frågor att tänka på:

• Vilka är dina affärsmål?
• Kan en enhyreslösning stödja dina framtida tillväxtplaner?
• Hur stor är din driftgrupp, och hur mycket av din infrastruktuurhantering kan automatiseras? Bryr du dig om smidighet och kostnadseffektivitet?
• Är dina kunder bekväma med olika multi-hyresalternativ?
• Hur påverkar varje alternativ efterlevnad, både din och din kunds?
• Förväntas du uppfylla servicenivåavtal (SLAs) eller sträva efter specifika servicenivåmål (SLOs)?
• Har du övervägt säkerhet, kostnad, prestanda, tillförlitlighet, och respons till individuella hyresgästbehov som helhet?

Kom ihåg att det inte finns en stel uppdelning i din produkt där du måste välja antingen en rent multi-tenant eller enbart enhyresmodell. Ditt beslut bör baseras på hur du delar upp dina produkts arkitektoniska komponenter och de specifika isoleringsnivåer som behövs av dina kunder eller affärer. Du kan sedan tillämpa olika tillvägagångssätt därefter.

Nästa steg#

Vi pratade om den "nya" definitionen av en multi-tenant-app, men hur är det med hyresgästisolering, identiteter, och hur man bestämmer om dina identiteter borde vara isolerade eller inte? Vad betyder det att identiteter är "isolerade"?

Förvirringen uppstår ofta när man hanterar situationer där en verklig användare har två olika identiteter. Är det lämpligt att märka denna situation som - "isolated identities"?

Vi kommer att behandla dessa frågor i vår kommande serie artiklar. Håll utkik!