En djupare dykining i begreppet "multi-tenancy" och delning av våra insikter om hur vi uppfattar det.
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.
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.
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.
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
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.
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å:
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.
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!